Re-ordering applications in MDT

Spent some time today updating tools that were out of date and needed a refresh.

One of the applications is my MDT Application Re-ordering tool.

Application Reordering

There are two different scenarios where you might want to rearrange applications in MDT.

1. Where application X needs to be installed *before* application Y. If so, use the dependencies option in the applications entry page in the Deployment Console. This is the only way to ensure applications are installed in any specific order.

2. However if you want the applications to *appear* in a specific order in the Deployment Wizard, then you can use the tool to perform this task. This also has a side effect any application selected in the MDT wizard will be installed in the order displayed in the wizard.

Behind the Scenes

After the user arranges the applications in the MDT2010Ordering tool, the tool will construct a powershell script to do the heavy lifting. The script essentially just moves the application out of the folder and back again in the correct order.

If you wanted to do all of this by hand, you could also just modify the control\ApplicationGroups.xml file to perform the actions. Be careful! :^)


Scripts to dump installed drivers and applications

I was looking at my old ZTIYellowBang.wsf script on my old Blog site and noticed that the script version posted is an older version. So it’s time to update the script! :^)


Back when I did a Deployment contract for Microsoft’s own IT department we developed a MDT Litetouch Deployment solution (Another team was working on the SCCM-OSD deployment). And I wanted to ensure that we were getting good driver/application coverage.

One of the first things I did in our test lab was to setup a SLShare so all of the bdd.logs generated by the test machines were sent to a centralized location for processing later. BUt how to make sure that the drivers installed were correct.

Updated Tool

I created ZTIYellowBang.wsf to track which devices on a machine had no drivers installed (or when drivers failed to load). The term “Yellow Bang” is in reference to the Yellow Exclamation point visible in the Windows Device Manager for any devices that are not working properly.

The updated tool I developed for MSIT doesn’t just display devices that are missing drivers, it also displays if the drivers installed are inbox Microsoft Drivers, 3rd party signed (WHQL), or not signed at all (Bad).

I added this to the standard Task Sequence near the end of the “State Restore” phase. It was also easy to write a script to find (Grep or findstr.exe) devices that did not find any drivers.


The other tool included here is a tool that displays all “installed” applications on the local computer. It searches the registry for all installed applications that appear in the “Add/Remove Programs” section of the Control Panel.

This tool can be helpful if you have drivers that also installed some associated applications that appear in the Control Panel.

Additionally, it will also go through the list of Applications and ManadatoryApplications selected for installation by MDT ZTIApplications.wsf. If the Application entry has a “UninstallKey” defined, the script will verify that the application was installed.


Simply copy the ZTIYellowBang.wsf and/or ZTIAppVerify.wsf script to the Deployment Share under the …scripts directory. Then add the script as a Step to your Task Sequence (just before the Capture section):

cscript.exe %ScriptRoot%\ZTIYellowBang.wsf


Keith Garner is a new Microsoft MVP!

Cool, looks like I’ve been nominated by Microsoft as a MVP:


Dear Keith Garner,

We are pleased to present you with the 2014 Microsoft® MVP Award! 
This award is given to exceptional technical community leaders 
who actively share their high quality, real world expertise with 
others. We appreciate your outstanding contributions in Windows 
Expert-IT Pro technical communities during the past year.

Still exploring the MVP program, but it looks like I get a 1 year subscription to MSDN download center (which strangely I have never had).

MDT 2012 uEFI on large Media

Starting go get some more questions on how to image uEFI machines. It’s one of the biggest architectural changes to the PC in recent memory, and requires some new skills for us IT Professionals.


One of the most perplexing problems I’ve come across is of Large files on USB Flash Drives. You see, Microsoft licensed the FAT file system for use in the uEFI firmware so the firmware itself can read files off Hard Disks and USB Flash Media, uEFI does not support booting directly from NTFS partitions which assumes some kind of Boot Sector. Most machines with large internal Hard Disks break down the local disk into several partitions, One partition used to contain the uEFI boot files, and another NTFS partition to contain the Windows Operating System.

However, the problem with Fat32 Partitions is that they do not support files that are larger than 4 GB in size. If you want to install a Windows OS using MDT offline media, and your core image is larger than 4GB you can’t place the file on a Fat32 USB Stick. Additionally, USB Flash drives can not be given multiple partitions, you can only have one Fat32 or one NTFS partition on a removable flash drive, this means we can’t do the same trick as a internal SATA Hard Disk where we give the drive several partitions.

Work Arounds

There are several tricks we can use in MDT to work around the issue:

  • Don’t use Offline USB Media, instead download the large WIM file from your Deployment Share over the network. Use either PXE boot, or boot from a USB Drive and connect over the network. In some instances, the Gigabit Ethernet connection to the server will be faster than the local USB 2.0 disk. Remember, you can boot from a small 256MB USB flash drive with the contents from c:\deploymentshare\boot\LitetouchPE_x86.iso extracted to a USB Flash Drive.
  • Use *two* flash drives! Create Two flash drives, One formatted with NTFS that contains the offline USB media with the large *.wim file, and a second drive formatted with FAT32, that contains the contents from contents of the c:\deploymentshare\boot\LitetouchPE_x86.iso. uEFI will be unable to read the NTFS drive, and boot off the Fat32 drive instead, however once in WinPE, MDT will search all the drives and continue as if it was a Offline Media Installation. (Normally I don’t recommend leaving two MDT USB Drives in a machine at once, can cause confusion).
  • You may not re-partition USB Flash drives marked as “removable”, but some USB drives marked as “Fixed” can be repartitioned to include both a Fat32 and NTFS partition(s). Windows To Go drives are designed to do this. Additionally, you might be able to repartition USB Hard Disk Drives.
  • Use DVD-DL (DVD Dual Layer) which has a capacity of 8.5GB, and can support files larger than 4GB. Native support for BIOS and uEFI machines.
  • Finally, you might want to split the super large install.wim file into multiple parts to make more manageable.

Splitting Wims

First of all, let me mention that splitting WIM files like what is mentioned below will cause some compatibility problems within MDT itself. Although *.SWM files are a supported format within the *.wim file standard, MDT was not designed to handle *.SWM files. So you can’t import and/or service these files within the MDT console, and the client scripts will also get confused if used.

I developed a prototype for WIM splitting a couple of years ago, and wanted to share the solution:

1. Create an Offline Media Share with the OS you want to support.
2. Split your large WIM file using the command:

imagex.exe /split install.wim install.swm 4095

3. Modify the …\Deploy\Control\OperatingSystems.xml file and change the “Install.WIM” entry to “INstall.SWM”
4. Modify the …\Deploy\Scripts\LTIApply.wsf script to:

If GetWDSServer "" then
ElseIf ucase(right(sImagePath,4)) = ".SWM" then
   sRWMPath = mid(sImagePath,1,len(sImagePath)-4) & "*.swm"
   oLogging.CreateEntry "Found SWM file, adding other SWM files for concatenation: " & sRWMPath, LogTypeInfo
End if

5. Copy to your USB Flash Drive and use as normally.


Also found this solution for Splitting WIM files that is similar, but slightly different.


Failed to save the current environment block


I have received some questions lately about a weird blocking MDT bug on some uEFI machines.

A quick scan of the bdd.log does not reveal any clue as to what the failure is, however when we check the SMSTS.log file we can see the following:

Set a global environment variable _SMSTSNextInstructionPointer=53     TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Set a TS execution environment variable _SMSTSNextInstructionPointer=53       TSManager         1/29/2013 6:41:40 AM                1532 (0x05FC)
Set a global environment variable _SMSTSInstructionStackString=46       TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Set a TS execution environment variable _SMSTSInstructionStackString=46         TSManager         1/29/2013 6:41:40 AM                1532 (0x05FC)
Save the current environment block       TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
pszPath[0] != L'', HRESULT=80070057 (c:\qfe\nts_sms_fre\sms\framework\core\ccmcore\path.cpp,58)                TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Filesystem::Path::Add(sEnvPath, EnvDataFileName, sEnvPath), HRESULT=80070057 (e:\nts_sms_fre\sms\framework\tscore\environmentlib.cpp,639)         TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Failed to save environment to  (80070057)           TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
TS::Environment::SharedEnvironment.saveEnvironment(szPath), HRESULT=80070057 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\executionenv.cxx,842)     TSManager         1/29/2013 6:41:40 AM         1532 (0x05FC)
Failed to save the current environment block. This is usually caused by a problem with the program. Please check the Microsoft Knowledge Base to determine if this is a known issue or contact Microsoft Support Services for further assistance.
The parameter is incorrect. (Error: 80070057; Source: Windows) TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
SaveEnvironment(), HRESULT=80070057 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\executionenv.cxx,420)     TSManager         1/29/2013 6:41:40 AM         1532 (0x05FC)
Failed to persist execution state. Error 0x(80070057)       TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Failed to save execution state and environment to local hard disk             TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Reboot to local harddisk               TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
FALSE, HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\engine.cxx,584)                TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
The task sequence execution engine can not reboot the machine because we failed to persist execution environment     TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
CheckForRebootRequest(&bRebootInitiated), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\engine.cxx,274)   TSManager         1/29/2013 6:41:40 AM                1532 (0x05FC)
Fatal error is returned in check for reboot request of the action (Restart computer). 
Unspecified error (Error: 80004005; Source: Windows)   TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
An error (0x80004005) is encountered in execution of the task sequence              TSManager         1/29/2013 6:41:40 AM                1532 (0x05FC)
Sending status message . . .        TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)
Executing in non SMS standalone mode. Ignoring send a task execution status message request               TSManager                1/29/2013 6:41:40 AM    1532 (0x05FC)
m_TSEngine.Execute(& m_eExecutionResult), HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmanager\tsmanager.cpp,763)       TSManager         1/29/2013 6:41:40 AM                1532 (0x05FC)
Task Sequence Engine failed! Code: 80004005    TSManager         1/29/2013 6:41:40 AM    1532 (0x05FC)

The important line here is when we see: “Failed to save the current environment block.” MDT uses the SMS Stand Alone Task Sequencer, and it must save it’s state, including environment variables and other instruction pointer steps to the hard disk before it can reboot so it can continue where it left off.

For whatever reason, the SMS Stand Alone Task Sequencer (SMSTS) can’t save to the local disk, perhaps it’s having trouble trying to enumerate through the uEFI GPT Partitioning structure.


Upon further review we can see that for most of these machines the problem is occurring during the WinPE Phase, and the WinPE version is 7600, meaning that it was created from the WAIK. Normally this would be OK, as MDT 2012 and the WAIK have been tested with uEFI, however there is this one note in the MDT 2012 Update 1 “Release Notes” that should be taken into account:
• 64-bit versions of Windows are unable to deploy to computers with Unified Extensible Firmware Interface (UEFI) 2.3.1, because the Windows AIK is being used to perform the deployment. The Windows ADK is required when deploying Windows to a computer with UEFI 2.3.1.

It appears that the ADK is required for deployment to uEFI machines, at least with uEFI 2.3.1, which is most modern Windows 8 class machines. So the resolution is to upgrade to ADK on your build machine to see if the problem goes away.

Hardware idea: USB to Ethernet and 1GB Flash Adapter

OK, So I’ve purchased tickets to the Consumer Electronics Show (CES) in Vegas this week ( January 2014 ), and I’ve given myself a project to do while down there. I would like to talk to some Independent Hardware Vendors about a new USB Device I would like to see made. Hopefully I can convince someone that a device like this has some technical merit.

The idea is pretty basic, I would like a USB to Ethernet Adapter with a 1GB flash drive built in. And I would like it to look like a basic USB to Ethernet Adapter like this:


I purchased a new Microsoft Surface Pro device at Microsoft’s TechEd 2013 event last May. I love the device, lately I’ve been using it as a test environment, re-loading Operating Systems on the device every couple of weeks or so.

In order to install a *new* operating system on the Microsoft Surface Pro you have two options:

1. Purchase the USB to Ethernet Adapter from Microsoft. Microsoft has included the drivers for this specific controller in the firmware for the Surface device and boot from your PXE/WDS Server. Note that not all USB to Ethernet Adapters will have driver support in the Surface uEFI so if you want to boot from PXE you will need this adapter.
2. Otherwise, you can put the MDT LitetouchPE_x64.iso WinPE boot files on a USB flash drive (about 300MB), or create Litetouch Offline Media disk (about 4GB).

The problem is that the Surface Pro machine only has one USB port, so if you want to boot from the USB stick *and* connect to the internet to download the latest OS and updates over the network, you will also need a USB hub. I’ve been trying some various hubs, and some are not identified by the Microsoft Surface uEFI Firmware. However I have had success with the Belkin F4U029. I have also been using the Cisco USB300M USB to Ethernet Adapter, which appears to have driver support built into WinPE, but does not have driver support in the Surface uEFI Firmware.

Here’s my Surface Pro OS Installation Tool:



But I’ve been thinking, and this combination (design), has some technical merits. The problem right now with small Tablets/Ultrabooks, is that they are cutting down on the number of external ports (really I’m OK with this), and the surface is a classic example. No built in Ethernet, and only one external USB port. Additionally, the USB to Ethernet adapter supported on one Tablet, may not be supported by another Ultrabook. Are IT departments expected to keep a large collection of USB Adapters around to support each device just to PXE boot?

But really, there’s nothing really special about PXE booting. It’s just going out to a server to get a WinPE image. WDS/SCCM/MDT will do the rest. If you put the boot image from SCCM or MDT on a flash drive as small as 512MB, you can emulate the PXE boot process to continue, that’s where the flash drive comes in.

For an average IT department, a single USB HUB+Ethernet+Flash device can provide full OS installation from SCCM/MDT without having to keep multiple USB-Ethernet Adapters, or werid dongles. And the device would be universal for all laptops and tablets. Easy!

My idea would be:
• The USB Hub must be recognizable by the Surface machine (Some hubs are, some are not, I don’t know why).
• I would not use USB 3.0. WinPE may not have full USB 3.0 controller support. USB 2.0 only
• It would be nice to have Gigabit Ethernet. Gigabit is faster than USB 2.0, and slower than USB 3.0.
• All devices should have in-box Windows 8.1 ADK WinPE driver support. (easier).
• The flash drive should be around 1GB (you could have around 3 boot images), although 8GB would also be nice (most images are 8GB and less).
• The flash drive should be reasonably fast.
• It would be *nice* if the USB Flash Drive could emulate a Fixed hard disk (do not include the Removable flag). That way IT departments can “hide” the main partition, yet it would still be available for booting. (Similar to the hacks done on Windows to Go media (WTG).

Some more advanced work (future) would be to:
• Create a runtime library that could discover the nearest PXE server from within WinPE.
• Then create a process to find out if there are any updated WinPE images on the server, auto update the USB flash drive, and reboot again.

We’ll see if I can convince anyone to make this device.
If you are an IHV, and are interested in making this device, let me know!


SysInternals AutoLogon and securely encrypting passwords.

Can you claim that your house is “secure” if you leave the key for the front door under the welcome mat? :^)

Got into a discussion the other day with someone regarding what “encrypted” means with respect to the Microsoft System Internals tool AutoLogon. The Autologon tool says:

Autologon enables you to easily configure Windows’ built-in autologon mechanism. Instead of waiting for a user to enter their name and password, Windows uses the credentials you enter with Autologon, which are encrypted in the Registry, to log on the specified user automatically.

Autologon is easy enough to use. Just run autologon.exe, fill in the dialog, and hit Enable. To turn off auto-logon, hit Disable. Also, if the shift key is held down before the system performs an autologon, the autologon will be disabled for that logon. You can also pass the username, domain and password as command-line arguments: autologon user domain password

My emphasis added.

Auto Logon

When you login to Windows, it requires you to enter a user name and a password. But what if we want to automate some installation across reboots or make the workstation into a Kiosk, when we want to *skip* the logon prompt? Well the OS *always* requires the username and password (credentials), so we can work around this by entering the credentials into the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

If Windows Sees that AutoAdminLogon is set to 1, and the rest of the registry entries are set, the OS will skip the Logon screen and go to the desktop. Now, This can be a problem in secure environments. First of all you don’t want just anyone to just bypass the first step in security and gain access to the desktop, so don’t use AutoAdminLogon for accounts that are important/sensitive. Secondly, the credentials, including the password are stored in registry as plain text, not a salted hash value as most passwords are stored. That means that anyone who has read privileges to the WinLogon Key DefaultPassword Value can read the password as plain text.

This is what the MDT Litetouch scripts use to perform an AutoLogon to the local administrator account. And I never use secure passwords for the administrator account. Instead I give some weak password, and once the OS installation is finished, I secure the machine by giving the Administrator Account a more secure password using the command:

net.exe user administrator *

LSA Secrets

Windows added a feature where the Logon process can read the DefaultPassword from LSA Secrets. LSA Secrets are a protected area of storage used to store internal private data. Data is stored in the registry under HKLM\SECURITY\Policy\Secrets, and this registry key has restricted ACL’s so it is not visible in regedit.exe using a normal user accounts. However, the DefaultPassword key can be decoded by any administrator using a simple Win32 API call.

What’s the point of having a registry key encrypted if any administrator can decrypt the value?!?! Well if you enabled AutoAdminLogon for a non-administrative user, the user can’t read the password under normal circumstances, secondly, you won’t be able to read the registry values over the network. You must have local administrative execution privileges. (and if you have local administrative privileges, you already have full access to the box :^(.

I wrote a exe to decrypt the AutoAdminLogon DefaultPassword stored in LSA Secrets. It’s only 2k in size, and can be downloaded from here:

SysInternals AutoLogon tool

The SysInternals AutoLogon tool uses the LSA Secrets to store the DefaultPassword in the registry. Yes it is technically encrypted, *however* just because it’s encrypted, does not mean that it’s safe to put your secure passwords there. Any administrator can decrypt and read the value.