Tag Archives: mdt2013u2

Setting the Wallpaper and Lockscreen in Windows 10

By | December 4, 2016

Finally! I found a failsafe way to set a desired image to both the default wallpaper and lockscreen in Windows 10. Place a Wallpaper.jpg into your MDT “scripts” folder, add Powershell support to your WinPE (you will need to also add .NET support).  Then use this command line after applying the image:

I basically… Read More »

Display the WIM filename during Image Apply step Dynamically

By | November 30, 2016

Since there is no MDT built-in variable assigned with just the wim name, i had to create a seperate step to create the variable “OSDImageName”, which i  then used in my standard image apply step. Here is what the Task Sequence looks like: Step Name Text: Expanding %OSDImageName% (%ImageSize%) to %OSDisk%\… And here is how… Read More »

Add MDT Selection Profiles for each Out-of-Box Driver Folder using a PowerShell Script

By | October 23, 2016

MDT Task Sequence’s Inject driver steps do not support specifying folders,  so Selection Profiles are the defacto method for bridging this gap.  Here is a script I created to ease the process of creating/importing multiple system drivers into MDT at once.  If ran more than once, it will not create duplicate selection profile entries.


The MDT 2013u2’s “Litetouch OEM Task Sequence” does not partition UEFI drives using GPT

By | August 26, 2016

After the Litetouch OEM TS runs and the content is staged, on next boot up, no UEFI supported drives are found. To fix this, you must correct the litetouch oem task sequence. Before: After: Copy the corrected “Format and Partition..” steps from your deployment TS. Thanks goes to: https://social.technet.microsoft.com/Forums/en-US/db958f0d-b64c-4557-be79-cace90613493/litetouch-oem-task-sequence-uefi-support?forum=win10itprosetup -BG

“FAILURE ( 5624 ): -2147467259 0x80004005: Run DISM..” error when applying WIM

By | July 16, 2016

Scenario: Deploying Windows 10 x64 with MDT2013U2 to CF-20A via LAN. Solution: This issue occurred, because an Update of the Media share was initiated at the same time of a deployment and the update was set to split the OS WIM to support UEFI.  Once Media update was complete, the deployment ran with no issue.