Fix for Windows 1511 ADK bug

First off, yes, I have a new job working for 1e! I’m super excited, and I should have posted something about it, but I’ve been super busy. My first day on the job was at a customer site in Dallas, and I’ve been on the go ever since, working on this and that (stay tuned :^).

As many of you may have known, there has been a pretty big bug in the Windows 10 Version 1511 ADK, it’s caused all kinds of interop problems with Configuration Manager. Well Microsoft released a fix today! KB3143760. Yea!

Well I opened up KB3143760, and yikes! The instructions are a bit dry. Mount this, patch that, watch out for the data streams!

I needed to patch my local Windows 1511 ADK installation because I’m working on a SCCM+MDT Refresh scenario, and I don’t want to uninstall the 1511 ADK. Perfect timing, if only there was a way to automate this..


Here is a link to a PowerShell script I wrote to auto-magically patch your WinPE files!!158500&authkey=!AHWArN5C7FyRPIY&ithint=file%2cps1

This script will:

  • Download the patch (no need to go through the E-Mail process)
  • Take care of all the stream issues (really I don’t use IE/Edge, so no security streams)
  • Auto extract the patch contents
  • Mount the wim file
  • Patch the appropriate dat files
  • Fix the permissions
  • Dismounts the WIM
  • Cleans up all left over files

So, for example, if you wanted to patch all of the WinPE Wim files in the ADK directory (before importing them into SCCM), you can run the following command:

get-childitem 'C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\*.wim' -recurse | .\Repair-1511ADK.ps1 -verbose

Lately, when programming in PowerShell, I have taken the “write-host considered harmful” rule to heart, so by default, there is *NO* std console output. Instead, I redirect most information output to “verbose”, so if you want to see what is happening in the background, use the -verbose switch.


Hopefully, moving forwards, this will be the *last* time I place a new script up on OneDrive, really I should be moving towards something more… modern… like GitHub.


MDT package now on ready for Windows 10!

Been a while since I posted, I’ve been busy with Surface, Windows 10, and other Kits. But my chocolatey package just got approved, so I thought I would share.

I’ve been following the progress of PowerShell’s OneGet, and for a while now, and thought it was time to stick my toes in and create a package for public use. MDT seemed like a great start.

As you may already know OneGet is a new feature of PowerShell, included in Windows 10 and available through WMF 5.0 that allows for the installation of packages over the internet. Chocolatey is one of the back-end providers, with a great collection of apps ready for installation.

With the recent release of MDT 2013 Update 2, it seemed like a great opportunity to practice my packaging skills. Eventually I created a PowerShell script to auto generate the chocolatey package (not shown here), it would download the MSI files, and extract out the MSI Product Code and Checksum values. You can see the code generated on the Chocolatey MDT page.

Now to install MDT on Windows 10 (or Windows Server 2016), we can run the commands:

set-executionpolicy RemoteSigned; 
Install-Package -Name MDT -ProviderName Chocolatey `
-ForceBootstrap -Force -Verbose

How it works

First step we need to do on clean machine is to set the execution policy:

set-executionpolicy RemoteSigned

Chocolatey has some PowerShell scripts that run in the background, so we need to allow PowerShell to run these commands with the Set-ExecutionPolicy command. Most Powershell users run this command anyways, so it’s not that uncommon.

Then we install the package using the PowerShell 5.0 “Install-Package” cmdlet built into Windows 10:

Install-Package -Name MDT -ProviderName Chocolatey

We must specify the “-ProviderName Chocolatey” parameter the fist time we call Install-Package so the chocolatey Provider is installed, MDT is only known to Chocolatey at this time.

Install-Package will prompt us to confirm installation of the chocolatey provider, we can skip this with the -ForceBootStrap parameter. Additionally, Install-Package will also ask for confirmation before installing MDT, and we can sip the confirmation with the -Force Paramater.

I like to see what is going on the background, so I add the -verbose parameter, and my screen fills with yellow:


We can see Install-Package downloading MicrosoftDeploymentToolkit2013_x64.msi from the Microsoft web servers.


The Windows 10 ADK package has also been uploaded to Chocolatey, but hasn’t been officially approved yet, so when you try to run the “windows-ADK” package it will install the older Windows 8.1 version. We can force the Windows 10 ADK to install with a version parameter. Additionally, the default version of the “Windows-ADK” package does not install USMT, so to install everything we will need the “windows-adk-all” package (which is a lot of stuff, sorry).

install-package -ProviderName Chocolatey -Name Windows-ADK-All `
-force -Verbose -MinimumVersion 10.1.10586.0

More information:


MDT UberBug11 – Security vs Usability

(Haven’t posted in a while, been busy with my day job(s), travel, scripting, sleep :^).

Some of you have recently noticed that MDT 2013 Update 1 has changed the way it sets the permissions on the network shares when it creates them for the first time.

When you create a new deployment share in MDT, it will ask you what the network share should be, and the wizard will automatically create the necessary bindings for the share and your local path, including setting up the permissions. Super!


The old permissions used to be “Everyone” has full access, it’s now set to “CREATOR OWNER”. I was somewhat confused by this change, and seemed a bit arbitrary to me. I suspect that someone filed a bug against MDT thinking that locking down the deployment share in the most restrictive way possible would somehow be better, because you know… Security! Think of the security breaches at Home Depot, and Target. PKI. Oh the humanity.

Well, MDT deployment shares don’t really store sensitive information, if you *DO* store any sensitive information on a MDT deployment share, then you are doing it wrong.

But anyways, someone made the decision to lock down the share, although “CREATOR OWNER”, this is kind of confusing to me, only one user? Why not use local “Administrators” group, local administrators already have full access to the files. “CREATOR OWNER” might only give access to one of several local “Administrators”.

Additionally, “Everyone” isn’t really that bad, access files over the network, you are still limited to the “File” level permissions on each file, which are better IMHO, I can create a Logging directory with Create/Write permissions, and set everything else to “Everyone” Read, with “Administrators” “Full R/W”


Anyways, this new permissions change for MDT 2013 Update 1 hasn’t caused much of a problem, as most users can easily work around the issue by adding extra approved users to the share afterwards.


Got a question today about a missing DeployRoot varaiable in BootStrap.ini.

MDT uses BootStrap.ini in WinPE to remember where to find the DeploymentShare to do the heavy lifting.

Normally, when creating a new DeploymentShare, MDT will automatically update the DeployRoot variable in BootStrap.ini, however several users were observing that this was no longer getting updated.

I used my trusty ILSpy to disassemble “C:\Program Files\Microsoft Deployment Toolkit\Bin\Microsoft.BDD.PSSnapIn.dll” and look at the “Provider class”, what I observed is this code segment:

IniManager iniManager = new IniManager(deploymentPointSettings["UNCPath"] + "\\Control\\Bootstrap.ini");
iniManager.Write("Default", "DeployRoot", deploymentPointSettings["UNCPath"]);

You can see here that MDT is attempting to open the Bootstrap.ini file and write the Path to the DeployRoot Value.

Note that MDT is trying to load the Bootstrap.ini file using the same “UNCPath”? I suspected that MDT was failing to open the file due to the restrictive “Creator Owner” permissions, Sure enough, I tried opening the file over the network and it failed. Found!

Work Around

After creating a new deployment share in MDT, be sure to go back and fix some of the defaults:

  • Change the permissions, Something more permissive like local “Adminsitrators”
  • Change the \\server\deploymentshare$\control\bootstrap.ini to include
  • <More to follow I as do more testing>

MDT Bug: 451130 (known issue)


Deployment Gotcha – Get Windows 10 App doesn’t work with MDT

Did you know that you can download *.iso images of Windows 10 using the Get Windows 10 app?

It’s a tool that will allow you to download *.iso images for deployment.

The only problem is that it doesn’t actually download *.iso images, instead, it downloads *.esd images, which are highly compressed *.wim files, that are encrypted/encoded. The tool then decrypts/decodes the *.esd file into *.wim files, and constructs a *.iso image for use.

Additionally, the *.wim file is still a highly compressed *.esd file, so legacy tools that leverage the WIMGAPI library like imagex.exe don’t understand it.  Dism works fine.

C:\>"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\imagex.exe" /info g:\getwin10\Windows\sources\install.wim
ImageX Tool for Windows
 Copyright (C) Microsoft Corp. All rights reserved.
 Version: 10.0.10011.16384

Error opening file [g:\getwin10\Windows\sources\install.wim].

An attempt was made to load a program with an incorrect format.
C:\>dism /get-wiminfo /wimfile:g:\getwin10\Windows\sources\install.wim

Deployment Image Servicing and Management tool
 Version: 6.3.9600.17031

Details for image : g:\getwin10\Windows\sources\install.wim
 Index : 1
 Name : Windows 10 Pro
 Description : Windows 10 Pro
 Size : 9,343,966,034 bytes

The operation completed successfully.

That means that you can’t import the images into MDT, because MDT uses the WIMGAPI libarary, and powershell commands might not work either.

I tried to export the *.wim file to another *.wim file, but DISM.exe doesn’t like doing that either.

As a work around you might be able to export the *.wim file to a *.vhd container, and re-capture back to *.wim file with normal compression.

Johan has been documenting esd to wim techniques on his blog.

Otherwise, I hope the DISM team fixes this for TH2 :^) <hint> <hint>



MDT UberBug10 – Win10 OS Capture using SCCM is not supported

Got an interesting question yesterday about the Symantec Management Agent (SMA). Someone asked about running sysprep.exe under the system context, and someone else mentioned that execution of the sysprep.exe is *not* supported in the system context for Windows 10. I suspect this has to do with all the new fancy Metro/Modern/Universal apps that have plenty of junk that needs to be cleaned up by sysprep.

What is the System Context? Well normally when you run a program in Windows, you are running it under your user context. However If you go to the Task Manager, “Details” tab, you can see that there are dozens of background processes running, some with the user name “SYSTEM” these are specially designed *.exe programs that run in the background and perform numerous tasks.

task manager

The problem

There is no problem for MDT LiteTouch build and capture task sequences, however if you were to use SCCM to build and capture, now you may have a supportability problem, because SCCM runs tasks sequences in the system context. Whoops!

I have filed a bug on connect asking for a Supportability statement from Microsoft.

In the mean time, please continue to use MDT LiteTouch for building your Windows 10 images.  :^)


MDT UberBug09 – BitLocker broken on uEFI machines for Win10

Got a IM today from a Consultant who was having trouble creating an end to end deployment of Windows 10 for some Surface Pro 3 devices.   Hey, I love Surface Pro 3 devices ( I have 3 in my office :^), so I thought I would help out.

The error message was when he tried to enable BitLocker, but that turned out to be a red-herring.

The Error

He had enabled BitLocker Pre-Provisioning and was trying to enable the protectors at the end, but kept getting errors like


This PC Doesn’t support entering a BitLocker recovery password during startup. Ask your administrator to configure Windows Recovery Environment so that you can use BitLocker.

What does WinRE have to do with bitlocker? OK, we ran REAgentC.exe /Info to see what the status of Recovery was, and turns out that it was *NOT* installed.

OK Let’s run the REAgentC.exe /enable command to turn it on:


REAGENTC.EXE: Windows RE cannot be enabled on a volume with BitLocker Drive Encryption enabled.

BitLocker wont’ start because it’s missing WinRE, and WinRE won’t install because of BitLocker. Super!!

Well after digging some more, we found out from the panther logs that the REAgentC.exe command was attempting to copy the WinRE.wim file from the OS partition to the WinRE partition created by MDT’s ZTIDiskPart.wsf but failed because the size was too small.  Too small?

The Root Cause

I Went back and looked at some WinRE sizes from current and past OS’es:

  • Windows 7 SP1 x86 – 145,287,084
  • Windows 7 SP1 x64 – 169,213,970
  • Windows 8.1 Update x86 – 193,132,205
  • Windows 8.1 Update x64 – 236,122,267
  • Windows 10 x86 – 238,226,804
  • Windows 10 x64 – 302,808,595

Wow, the Windows 10 x64 WinRE image is *far* bigger than the other versions.

Well, sometimes MDT can use the LitetouchPE WIM file as a WinRE file, how does the Win 10 ADK look:

  • LiteTouchPE_x64.wim  – 305,928,022
  • LiteTouchPE_x86.wim – 246,698,134

Well, since the Surface Pro 3 will *only* use x64, we better account for at least 310MB on our Recovery Partition.

What does ZTIDiskPart.wsf allocate? Easy it’s hard coded (in Mega Bytes):


Our 302MB image is just *not* going to fit on a 300MB partition. Nope.


I opened this bug against the small partition size back in October of 2014:

Additionally, can you up the size of WINRE_DRIVE_SIZE
in ZTIDiskPArt.wsf to something like 400?

If you would like MDT to install WinRE.wim for Windows 10 scenarios, please log into connect and up-vote this connect bug.  :^)




P.S. Additionally, please do *NOT* ask me about ZTIWinRE.wsf, it’s a piece of junk and should be completely removed from MDT. I will not speak of it (unless you are on the MDT team, and I will be happy to explain why it is evil and wrong, and should be deleted ). :^p

MDT UberBug08 – Task Sequencer Crash

My 3rd bug related to the new Stand Alone Task Sequencer has to do with a Crash in the product. I’ve seen this pretty consistently when hydrating/building out my own SCCM 2012 Server.

At the end of the task sequence I will see the following:


SMSTS.Log shows:

<![LOG[Process completed with exit code 2147942402]LOG]!><time="23:36:24.402+420" date="07-12-2015" component="TSMBootstrap" context="" type="1" thread="3864" file="commandline.cpp:1123">
<![LOG[Exiting with return code 0x80070002]LOG]!><time="23:36:24.417+420" date="07-12-2015" component="TSMBootstrap" context="" type="1" thread="3864" file="tsmbootstrap.cpp:1238">
<![LOG[shSmsTsKeyForScope.Open (HKEY_LOCAL_MACHINE, sSmsTsKeyForScope.c_str(), KEY_READ), HRESULT=80070002 (e:\nts_sccm_release\sms\framework\tscore\environmentscope.cpp,311)]LOG]!><time="23:36:24.417+420" date="07-12-2015" component="TSMBootstrap" context="" type="0" thread="3864" file="environmentscope.cpp:311">
<![LOG[Failed to open key Software\Microsoft\SMS\47006C006F00620061006C005C007B00350031004100300031003600420036002D0046003000440045002D0034003700350032002D0042003900370043002D003500340045003600460033003800360041003900310032007D00\SMSTS]LOG]!><time="23:36:24.417+420" date="07-12-2015" component="TSMBootstrap" context="" type="3" thread="3864" file="environmentscope.cpp:311">
<![LOG[GetKeyFromRegistry (m_sScopeRegKey.c_str(), Key), HRESULT=80070002 (e:\nts_sccm_release\sms\framework\tscore\environmentscope.cpp,764)]LOG]!><time="23:36:24.417+420" date="07-12-2015" component="TSMBootstrap" context="" type="0" thread="3864" file="environmentscope.cpp:764">

It’s a bit troubling, as I mentioned earlier with my other bugs related to the Stand Alone Task Sequencer, the Task Sequencer in MDT should be “rock solid”, and is a mission critical component, the fact that it crashes due to missing or corrupt registry is a problem.

I have filed a bug against MDT 2013.

I have no work around, but thought I would share in case anyone else encounters the same error.