Create a bootable WinPE boot disk to capture images using imagex

Here is a quick list of commands to create a basic WinPE bootable ISO image to use for capturing images of computers using imagex. First of all make sue that you have downloaded and installed the Windows AIK (Automated Installation Kit) on your computer which can be found here. Once the Windows AIK is installed run the ‘Deployment Tools Command Prompt’ form the Start Menu under ‘Microsoft Windows AIK’. In the ‘Deployment Tools Command Prompt’ run the following command which will create a folder on your C:\ drive called ‘winpe-bootdisk’ with all the necessary files to create the bootdisk:

copype.cmd x86 c:\winpe-bootdisk

The copy the winpe.wim base image to the c:\winpe-bootdisk\ISO\sources folder, renaming it to boot.wim

copy c:\winpe-bootdisk\winpe.wim c:\winpe-bootdisk\ISO\sources\boot.wim

Next you can mount the boot.wim image file to add any other tools that you want to include on the bootdisk. Once mounted the file system for boot.wim file can be found under c:\winpe-bootdisk\mount:

Dism /Mount-Wim /WimFile:C:\winpe-bootdisk\ISO\sources\boot.wim /index:1 /MountDir:C:\winpe-bootdisk\mount

If necessary copy any other tools you want to the boot.wim image e.g. imagex:

copy “C:\program files\Windows AIK\Tools\x86\imagex.exe” C:\winpe-bootdisk\mount\Windows\System32

You may also want to add additional packages or tools e.g. WSH (Windows Scripting Host) support

Dism /image:C:\winpe-bootdisk\mount /Add-Package /PackagePath:”C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\en-us\”

When you have finished adding stuff to the wim image unmount the boot.wim image and commit ther changes using the following command:

Dism /unmount-Wim /MountDir:C:\winpe-bootdisk\mount /Commit

Finally use oscdimg to create the boot disk ISO image

Oscdimg -n -bC:\winpe-bootdisk\ C:\winpe-bootdisk\ISO C:\winpe-bootdisk\winpe-bootdisk.iso

After this you can burn the image to CD, and start using it! To capture an image of a computer using your new WinPE boot disk run the following command, where DRIVE_TO_CAPTURE is the name of the drive you want to cature and DESTINATION_FILE is the location and name of the wim file that you want to save the image to:

imagex /capture DRIVE_TO_CAPTURE DESTINTATION_FILE /compress fast verify


imagex /capture E: D:\win7-corp.img /compress fast verify


Deploying Java and Adobe Reader via Group Policy


Firstly download the latest Java Windows offline installer here.

Run the installer, and wait for the Welcome screen to appear. Next, navigate to the following directory, where USER_NAME is the name of the logged on user, and jre_VERSION is the name of the version of Java that you have just extracted:


In this folder you will find an msi file and a file. Copy the jre_VERSION folder to you network deployment point, and then add the msi file path to a new package in the software installation section of the Group Policy Object (GPO) that you wish to deploy Java to.


Adobe Reader:

Simple Method:

Download the most recent MSI file from and deploy that to a new package in the software installation section of the GPO that you wish to deploy to e.g. AdbeRdr11000_en_US.msi. Note that Adobe only issue MSI files for the major releases e.g. 11.0.00.

Complex Method

This method includes how to patch the MSI file of the major release outlined in the simple method to include all the latest security patches. Firstly download the MSI file for the major release which you want to patch and place it in a folder on your computer e.g. C:\ADOBEREADER

Next download the .exe file for the update version which you want to patch to e.g. 11.0.01 from and extract the contents using the following command, where _VERSION is the version number of the file you downloaded:

AdbeRdr_VERSION_en_US.exe -nos_ne

e.g. AdbeRdr1101_en_US.exe -nos_ne

This will extract the contents of the .exe file to a subfolder in the C:\ProgramData\Adobe\Setup folder. Copy the .MSP file contained in this folder to the C:\ADOBEREADER folder you created earlier. From the command prompt navigate to the C:\ADOBEREADER folder and run the following command where MSI_VERSION is the version of the MSI file that you are updating and PATCH_VERSION is the version of the patch that you are applying :

msiexec /a AdbeRdr_MSI_VERSION_en_US.msi /p AdbeRdr_PATCH_VERSION.msp

e.g. msiexec /a AdbeRdr11000_en_US.msi /p AdbeUpd11001.msp

Click through the steps of the installer, and then click finish. Your .msi file has now been patched

Finally, copy your new patched msi file to your network deployment point and create a new package in the software installation section of the GPO which you wish to deploy Adobe Reader to.


How do I deploy Java using Active Directory across a network?

How to extract an MSI file from the EXE for Adobe Reader

Generate a new SID on Windows Server 2008 and Windows 7

With the NewSID tool no longer supported by Microsoft for more recent versions of Windows, you may find yourself in a situation where you need to generate a new SID on a Windows Server 2008 or Windows 7 computer, and wonder which tool you need to use. I myself have run across an issue in the past in our development environment where duplicate SIDs caused a problem. Care needs to be taken when cloning Windows virtual machines, particularly if they will later be used as domain controllers.

In order to avoid any issues like this, the new preferred method to set a new SID on a Windows machine is to use Sysprep. Before running Sysprep, you may wish to verify the current SID on the sytem that you wish to modify. This can easily be done by running the psgetsid utility, which is part of the excellent Pstools developed by Mark Russinovich. The output of the psgetsid command can be seen below, showing the current machine SID:

Output of psgetsid before running Sysprep on Windows Server 2008 R2

 Next you can sysprep by running the following command:


Running Sysprep
On the Sysprep, screen make sure that you tick the ‘Generalize’ tick box as shown below:

Choose settings for the System Preparation Tool

 The Sysprep process will take a few minutes to run, and will automatically reboot the system if you chose to do so. On reboot, the following screen will be displayed. Click ‘Next’ to continue:


Click next to continue the Sysprep process

 After the sysprep process is complete, you can run psgetsid again to verify that a new SID has been generated for this computer:

Output of psgetsid after running Sysprep on Windows Server 2008 R2



Set deadline for windows update installation in WSUS

In certain circumstances, when using WSUS (Windows Server Update Services) in your environment, you may wish to deploy a critical Windows update sooner than your scheduled installation window. Personally, I would excercise extreme caution using this setting due to the gotchas outlined at the end of this post.  However, this can easily be achieved by setting a deadline for installation when you approve the update or updates. In the WSUS console simply select the update or updates, and then right click them and choose ‘Approve …’ as shown.

Approving an update in the WSUS console

Once the ‘Approve Updates’ screen opens, choose which group of computers you want to approve the update for. In this case I have chosen ‘All Computers’, and then  ‘Approved for Install’. Next right click the ‘All Computers’ group again and choose ‘Deadline’ and then ‘Custom’ as shown:

Set a custom deadline for installation of an update in the WSUS console

The ‘Choose Deadline’ screen opens. Choose the date and time that you want the update or updates to be installed at, as shown:

Choose the date and time for your deadline

Thats it, your update will now be installed at the time that you have set. There are a couple gotchas using this setting that it is worth being aware of. Firstly if the update with the deadline requires a restart, the computer will reboot after installation regardless of what the user is doing at the time. It is therefore probably best to avoid deadline times in the middle of the working day when users may suddenly find their computers reboot with little or no warning causing them to lose work. Secondly, a deadline will override the ‘No auto-restart with logged on users for scheduled automatic updates installations’ Group Policy setting, so again be careful if you have this GPO setting enabled, as you may not expect your computers to reboot, but they will in this case.


tftp timeout on PXE boot when using WDS

I came across a peculiar problem today when trying to PXE boot a client computer on a newly commissioned Windows 2008 WDS server. This server had been commissioned in exactly the same way as all of our other WDS servers, but the client refused to boot the wim image that we had published in the WDS server. We recieved the message ‘tftp timeout’. We could tell that the client machine was picking up an IP address ok from the DHCP server, it seemed though, that it was unable to download the wim image file from the WDS server. We turned on WDS client logging and increased the logging level using the following 2 commands:

WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes

WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:info

Further information on enabling logging for Windows Deployment Services can be found here. After doing so we could see event: 4101 Source: Deployment-Services-Diagnostics stating ‘The following client failed tftp download’ as shown below:

Event ID: 4101 Source: Deployment-Services-Diagnostics

In this particular scenario we had WDS, DHCP and DNS installed on the same server. After a bit of digging we found the following Microsoft KB article (KB977512). It turns out when you have DNS and WDS installed on the same server there is the potential for DNS to grab the entire port range that WDS uses for tftp, preventing clients from connecting. The workaround is to increase the size of the port range on the WDS server so that it is larger that the range that is used for DNS. To do this you need to open the Windows Deployment Services console and right click on the affected server and choose properties. Once in the properties screen amend the UDP port range in the ‘Network Settings’ tab to 50000 to 65000 as shown below:

Amend the UDP port range in WDS Network settings

Click OK and you’re done. It also turns out that this problem has been fixed in Windows Server 2008 R2, which is why we hadn’t experienced this on our other WDS servers.

Enable a KMS Host for Windows 7 and Office 2010 Volume Activation

In order to simplify licensing and activation for Windows clients and servers on you network, you can set up a KMS host to automatically activate these machine with Microsoft, rather than having to install license keys individually on machines.

There are two types of license keys with Windows Vista, Windows 7, and Windows Server 2008, which are KMS and MAK. MAK (Multiple Activation Keys) are more like your traditional license keys, which you can use to manually license a product. Once the key is installed, that product stays licensed on that machine indefinitely. If you have multiple machines that you want to license using MAK keys in one go, you can use the Volume Activation Management Tool (VAMT 2.0).

The second option is to use KMS (Key Management Service). When using KMS you set up a server on the network to act as a KMS Host. This host collects licensing information information about client computers on the network, and then activates them in bulk with Microsoft’s activation servers, at regular intervals.

When you install Windows Vista, Windows 7, or Windows Server 2008 from Volume Licensing media, these machines will be installed as KMS clients by default. This means a fresh installation using volume licensing media will install a KMS license key on the client during the installation. Once the machine is installed and joined to your domain, if a KMS host is available on the network the new machine will report in to the KMS host, and the KMS host will in turn activate the client. There is a caveat to this. You need to have at least 25 KMS clients (for Windows 7 and Vista), or 5 KMS Clients (With Windows Server 2008) on your network in order for the KMS host to activate these machines with Microsoft. So in summary, for small deployments of less than 25 computers you will need to use MAK keys, but for larger  deployments, you can take advantage of the simplified activation process, by using a KMS host on your network.

So how do we set up a KMS host? Actually the process is pretty simple, especially if you set up a Windows Server 2008 R2 machine as your KMS host. You will need to obtain the ‘Server 2008 R2 Std and Ent Volume:CSVLK (KMS_B)’ KMS license key from the Microsoft Volume Licensing Service Center. To be sure that I was using the correct key, I verified it using the product key verify function using VAMT 2.0. The good thing about using this key, and indeed setting up your KMS host on a Server 2008 R2 computer is the fact that it will license and activate Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 KMS clients! Once you have the key handy you need to run up a command prompt using elevated privileges on the host that you want to set up as the KMS host.

At the command prompt type in the following to install the KMS_B key on your KMS host, where YOUR_KMS_B_LICENSE_KEY is the license key that you obtained from the Microsoft Volume Licensing Center:

slmgr.vbs /ipk YOUR_KMS_B_LICENSE_KEY

You should get a message like the following:

Installing the KMS Host license key

Next you need to activate the new license key by typing:

slmgr.vbs /ato

After a few seconds you should get a confirmation message like the following:

Successful activation of the KMS Host key

Next there are a few other checks you can make to ensure that your KMS host is enabled successfully. Firstly run the following command and review the output:

slmgr.vbs /dlv

Displaying detailed licensing information about your KMS host

You can use the output from this command to see the number of licensing requests that have been received by the KMS host. In the example above a single request has been received, and the current count is 1. As mentioned earlier in order for the KMS host to activate Windows 7 clients, the count must reach 25 i.e. 25 computers on the network must all have sent license requests to the KMS host. The command slmgr.vbs /dlv is an easy way to keep track of the progress of the current count in the early stages of your KMS deployment. If you want to obtain this infomation from a remote client machine you can use the slmgr.vbs KMS_HOST_NAME /dlv, where the KMS_HOST_NAME is the name of your KMS host.

A second useful check after enabling your KMS host is to make sure that the relevant DNS SRV record has been created, in order for KMS clients to discover the location of your KMS host. In the DNS console on one of your DNS servers look for a record called _VLMCS._tcp.YOURDOMAINNAME


Finally, check that tcp port 1688 is enabled incoming on your firewall in the domain profile on the KMS host to allow clients to make licensing requests.

Verify the Key Management Service (TCP-in) rule is enabled

After that your KMS host should happily pick up licensing requests for Windows Vista, 7, and Server 2008. In the early stages of our deployment we had set up a few clients using MAK licensing keys, until such time as we had 25 computers available on the network. Once we had enough Windows 7 machines available we converted them back to KMS clients, using the default KMS client keys listed here, and the VAMT 2.0 to install these keys on the client computers.

Next up, setting up the Office 2010 KMS host. In our environment it made sense to use the same server that was already acting as our Windows KMS host. Firstly we downloaded the Microsoft Office 2010 KMS Host License Pack. On Windows server 2003 other steps are required to install this (outlined in the system requirements), but on Windows Server 2008 R2, just run the downloaded KeyManagementServiceHost.exe file.

Accept the license agreement, and the file will run. You will receive confirmation that the license pack has installed correctly. Next you will be asked to enter your Office 2010 KMS Host license key, which you can obtain from the Volume Licensing Service Center. Enter your key and click OK, and you will receive the following confirmation:

Office 2010 KMS host activation success message

You can verify that the computer is activated, as a KMS host for Office 2010 by running the following command :

slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

The long code shown in the command is the Office 2010 activation ID. Running this command will give you a similar summary to the slmgr.vbs /dlv command for Windows Clients. It will show you the current count for Office 2010 KMS client installations as well as the number of license requests. With Office 2010 the current count must reach 5 before the KMS host will activate your Office 2010 installations i.e. there must be at least 5 computers running Office 2010 with a KMS client product key installed before the KMS host will activate these clients. More information on Deploying Office 2010 using KMS can be found here.

As a final note, you will notice in the above example that the output of the slmgr.vbs file is directed to a popup dialog box. If you would prefer to direct the output of the slmgr.vbs script to the command window that you are working in you can use cscript to run slmgr.vbs. To do this firstly navigate to the C:\Windows\System32 folder using the command:

cd C:\Windows\System32

You can then run slmgr.vbs using cscript as shown below:

cscript slmgr.vbs /dlv

As you can see below, the output will display in the command window rather than a pop up dialog box. I mention this for completeness as I have seen slmgr.vbs run both ways. It doesn’t really matter which you choose.

Running slmgr.vbs using cscript

Copying, moving and replicating the MDT 2010 deployment share

During our recent Windows 7 and Office 2010 rollout we decided to set up MDT 2010 on each of our branch Windows Server 2008 servers to automate the client upgrades. We had previously been using MDT 2010 at our central site to install and commision new computers, or rebuild existing computers, but to get Windows 7 rolled out quickly we needed this functionality in each of our branch offices. Having finalised our new task sequence for Windows 7 SP1, we started looking at options for copying the deployment share from our central MDT server to the branch offices and came up with several methods.

Method 1: Simple Copy

In the first instance it is simple enough to take a copy of the deployment share to a USB drive, and then copy this on to the branch server and add then add it to the Deployment Workbench on the branch server. The only significant change you need to make using this method is to edit the DeployRoot setting in the bootstrap.ini file found in the ‘Control’ folder of your deployment share. This setting should be edited to reflect the UNC path to the distribution share on the new server.

e.g.  DeployRoot=\\NewServerName\DeploymentShare$

You can also update the deployment share properties to reflect the new path if required:

Deployment Share Properties

The only other thing you need to be careful of is any hard coded references to the UNC path of the old server deployment share that you may have in any custom scripts that you are using to install applications or make customisations.

Finally, update the deployment share by right clicking on it in the Deployment Workbench and choose ‘Update Deployment Share’.

Method 2: Using Linked Deployment Shares

Whilst the method above is a quick and dirty fix to get your existing deploment share up and running on a new server, it has several shortcomings. One of the main problems is that when you make changes to the deployment share on your central MDT server, the changes will not be updated on your branch server. You would need to manually copy your deployment share, or some of its subfolders to your branch server in order to update it.

New in MDT 2010 is the ability to create Linked Deployment Shares. This allows you to replicate your central deployment share or certain selected parts of your deployment share to other servers. You could for example set up a link which replicates the drivers folder from your central MDT server to your branch server. To set up a link to your branch server for replication you need to look in ‘Advanced Configuration’, under your deployment share in Deployment Workbench.

Deployment Share Advanced Configuration

There are a couple of areas to look out for here. Firstly, you have ‘Selection Profiles’ which define what content you are going to replicate to your branch server. There are a number of predefined selection profiles, but you can also create your own if you wish, by right clicking the ‘Selection Profiles’ container and choosing ‘New Selection Profile’. Here you can choose which content you want to add to your selection profile for replication, as shown below:

Selecting which content to add to your selection profile

Once you have your selection profile set up, or alternatively if the predefined selection profiles meet your needs, you can proceed with creating your linked deployment share. To create a new link right click on the ‘Linked Deployment Share’ container, and choose ‘New Linked Deployment Share’.

Creating a new link

As you can see on the screen shown above, you need to specify the UNC path to the target deployment share, choose a selection profile, and also decide whether you want to merge, or replace content with the target deployment share on your branch server. Click next through the wizard to finish creating the Link. Once your link is created you can replicate the chosen content to your branch server by right clicking the newly created link, and choosing ‘Replicate Now’. Replicating in this way is a manual process. If you you want to replicate automatically to a schedule, you can write a powershell script to replicate the content over the link, and set it up as a scheduled task.

You can see that it is possible to set up multiple links to branch servers to replicate content, but depending on how many branch servers you have, this will involve setting up lots of links, and scheduled tasks if you want to replicate automatically. Another disadvantage of setting up linked deployment shares in this way, is that the performance over slow WAN links is not great. Linked Deployment Shares use a mix of SMB and robocopy to sync content which can be slow if bandwidth between sites is limited, especially on the initial copy.

Method 3: DFS Replication

The final method we looked at was using DFS Replication to replicate the deployment share to branch offices. This seemed like a good idea as content would easily be kept in sync, and replication could be throttled back during business hours. Another advantage over linked deployment shares was the fact that DFS Replication is able to compress the traffic as it passes over the slow links, minimising the amount of bandwidth required to update the branch copies of the deployment share.

Reading around the subject suggested that replicating an MDT deployment share, needed to be set up as a standalone DFS root, rather than domain based. We set up a replication group in a hub and spoke topology, where the central server acted as the hub and the remote branches were the spokes. This would also be easily scalable if further branch deployment shares needed to be added in the future.

The only problem with this method is the fact that there are hard coded references to the central deployment share in the bootstrap.ini file, which need to be changed in some way to be compatible with all the branch servers. We found 2 solutions to deal with this problem.

The first was very simple and just involved making a simple change to the DeployRoot setting in the bootstrap.ini file. By changing this setting to use the variable %wdsserver% rather than the actual MDT/WDS server name the bootstrap.ini file will work with any wds server, providing the deployment share name is the same.

To use this method simply edit the bootstrap.ini file to so that the ‘DeployRoot’ setting is something like this this:


The second method, is much more thorough, and uses the ‘DefaultGateway’ setting in the bootstrap.ini file, which enables you to specify the wds server name and deployment share location for each site. In this method when you PXE boot the client computer that you want to commission on to the network, the default gateway it is assigned by DHCP is used to determine its physical location. It is then pointed to the correct deployment share.

An example using the ‘DefaultGateway’ method showing the bits you need to add/modify is shown below:

Priority=DefaultGateway, Default






So in conclusion, we opted for the use of a standalone DFS root to replicate the deployment share out to remote sites, in order to ensure that all content was always up to date at our branch sites. We then customised the bootstrap.ini file using the DefaultGateway setting, allowing us to set deployment share paths for each of our physical locations. Once the deployment share was available at the branch offices we installed MDT 2010 and the Windows Deployment Services role on each of the local servers, and then added the newly replicated deployment share in the deployment workbench on each of the local servers.