MDT 2010 and USTMT 4.0 Hard Link Migration

One of the most exciting features for deploying a Windows XP client to Windows 7,sits around the ability to create a hardlink during a REFRESH scenario with MDT 2010.

In order to leverage USMT 4.0 in MDT 2010, you must first install the latest Windows Automated Installation Kit for Windows 7.

For more information on the Windows Automated Installation Kit, go here:

Jeremy Chapman has an excellent video demonstrating how this works:

What I really like about hardlinks it doesn’t migrate the user’s data out to the Network, meaning faster deployment times. So, instead of moving files to a protected location on the hard disk, the files aren’t transferred at all, just the paths to them are updated. This is a very cool feature that Microsoft has to offer us to help us facilitate our migration efforts from Windows XP to Windows 7.

This means the install and settings transfer happens much faster, because the files aren’t transferred at all, just the paths to them are updated.  It’s really cool, and means you can have a fresh install of Win7, with all your XP files and settings, completed in short amount of time. Of course, you still need to install the OS. But still…very cool…

So, how do I get USMT hardlinks to work in MDT Lite Touch Installation Environment? When you install MDT 2010 and create your Deployment Share, MDT will create a folder called USMT and copy the necessary USMT files into that folder. If you refresh the machine (by starting Litetouch.vbs from the running OS), MDT 2010 by default uses hardlinks.

I suggest the following read on USMT with MDT 2010 by Tim Minter.

Additionally, MDT 2010 Documentation:

VMware E1000 Nic Drivers, WinPE, and Adding NIC Drivers with DISM

DISM.exe is a new command line tool included in the Windows Automated Installation Kit (Windows AIK) 2.0. You can use DISM to service Windows images, both WIM and VHD files. This is a useful tool that can be used to add/remove device drivers, OS Packages, hotfixes, etc.

I recently came across an occurrence where I needed to add VMWare NIC drivers to my WinPE image. The new Windows 7 WAIK no longer has the PEIMG tool, which was used with the WAIK’s predecessor to inject drivers into the boot image. We now use the DISM.

When PXE booting to my VM, I realized my WinPE did not have the correct NIC drivers installed.

DISM Tool Notes

  • Multiple drivers can be added on one command line if you specify a folder instead of an .inf file.  Use the /recurse option.
  • The command to inject drivers into WinPE w/ DISM are demonstrated below:
  • To install an unsigned driver, use the /ForceUnsigned to override the requirement that drivers installed on x64 based computers must have a digital signature.
  • Dism.exe /unmount-WIM /MountDir:C:\Mount /Commit  (Note – The /commit option is very important!)

Here is what the WinPE Image will look like after the NIC drivers are injected with DISM.

For those using the new VMWare NIC model e1000, WinPE 2.1 supports the new VMWare NIC model e1000. It is recommended to use this NIC Model with your virtual machine.

IEEE 802.1X authentication protocol support for WinPE

Microsoft has released hotfixes that now add 802.1x support to both WinPE 2.1 and WinPE 3.0. Here are the links to the hotfixes.

WinPE 2.1:

WinPE 3.0 (Windows 7 & Server 2008 R2):

Step by Step Instructions to Inject the update using DISM.

1) Once you have downloaded the update, extract the files to your deployment server. In this example, I created a folder on my E:\ called 802PE.

2) Mount the LiteTouchPE_x86.wim using DISM: DISM /Mount-WIM /WIMFile:E:\DeploymentShare$\Boot\LiteTouchPE_x86.WIM /index:1 /MountDir:E:\Mount

3) Inject the package: DISM /Image:E:\Mount /LogPath:AddPackage.log /Add-Package /PackagePath:E:\802PE\

4) Unmount and Commit your changes: DISM /Unmount-WIM /Commit /MountDir:E:\Mount
5) As an additional step you can validate the package was installed successfully: DISM /Image:E:\Mount /Get-Packages (Note: When you add the package in step 3 it should tell you, “The operation completed successfully” if the package injected with no errors.)

Configuring Default User Settings – Full Update for Windows 7 and Windows Server 2008 R2

I’ve received some emails in my inbox lately about configuring Windows 7 Default User Settings on the Core Image. Instead of re-inventing the wheel, check out this blog posted by Michael Murgolo from the DeploymentGuys.

Windows 7 Deployment Useful Tip # 2 – Enabling the Standard User to delete Desktop Shortcuts from C:\Users\Public\Desktop

For thought, it is a general rule, set expectations with rationalization. If your environment consists of users running as administrators on their machines, this is something you really want to try and get away from.  Maintaining a well managed PC in the corporate environment goes out the Windows if you don’t lock and secure your systems. Destabilization of the desktop causes additional work for everyone, not to mention productivity down time for everyone.

User Account Control works by protecting access to administrative rights, and this involves elevation of privilege. One small challenge I came across recently was giving Standard Users the ability to delete desktop icons that are created during the installation of applications. Specifically, desktop icons stored in C:\Users\Public\Desktop. This happens because desktop icons were installed/created by a trusted install account (e.g. Administrator). Since the user is not the owner of the file, they cannot take ownership of the file. When a user attempts to delete a desktop shortcut, Windows 7 requests some kind of consent or credential to do so. Unfortunately, UAC won’t allow the standard user to execute this task.

The recommended solution would be creating a script to run against the desktop folder to modify the ACLs during post installation of the OS. Alternatively, you can add the following commands to your Task Sequence in StateRestore.

attrib -h c:\Users\Public\Desktop

Icacls c:\Users\Public\Desktop /grant “\Domain Users”:M /T

attrib +h c:\Users\Public\Desktop

Remember to replace “ with the name of your domain. Also note, the reason for the attrib requirement is because the public desktop folder is hidden. In Windows 7 the public desktop is a reparse point of the folder known as desktop. Credit goes to Josh Brungardt,  my colleague, for countless testing scenarios to get this to work.



MSIEXEC and application uninstall tip

I was inspired to write this post when a colleague of mine approached me today asking how to uninstall a previous version of an MSI and install a newer version. While this doesn’t directly tie int to OS Deployments, the need to uninstall & reinstall applications deployed on the estate is a very common task amongst Enterprise Solutions Administrators. Unfortunately, there isn’t a single command you can run from MSIEXEC which will find and destroy all older versions of an application. To do this, it would require the use of WISE packaging studio, or some other app packaging program.

One of the easiest methods for uninstalling an MSI is to use the /x command. Here is an example below.

msiexec /x “c:\vmtools\VMware Tools.msi” /qn /norestart /log c:\toolsUnInstall.log

However, what if you find yourself in the scenario where you don’t have the MSI of the older version you’re trying to uninstall. Luckily, that information can be found in the REGISTRY.

The information can be found at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

There should be the product ID there as well as a direct command you can run to uninstall the software.