After updating the Windows Deployment Service (WDS) server, it didn't seem to work anymore. The clients would try a PXE boot but couldn't find a TFTP server to get the boot image from. A colleague of mine found a great article about this problem.
It seems that when you have a single server that is running WDS and DNS, the DNS server binds to all ports in the WDS port range leaving the WDS server unable to respond to the clients.
- TFTP downloads fail
- Multicast downloads fail with a possible error code 2
- When WDS tracing is enabled you will find one or more errors that resemble the following
 16:01:36: [d:\w7rtm\base\ntsetup\opktools\wds\wdssrv\server\src\udpportrange.cpp:755] Expression: , Win32 Error=0x2
 16:01:36: [d:\w7rtm\base\ntsetup\opktools\wds\wdssrv\server\src\regudpendpoint.cpp:192] Expression: , Win32 Error=0x2
 16:01:36: [d:\w7rtm\base\ntsetup\opktools\wds\wdssrv\server\inc\RegEndpoint.h:354] Expression: , Win32 Error=0x2
 16:01:36: [WDSTFTP][UDP][Ep=0] Registration Failed (rc=2)
- When you run
netstat –abnyou'll find that 64001 to 65000 is displayed as being used
- You've applied security update MS08-037: Vulnerabilities in DNS could allow spoofing
If you do not require WDS to use a static port range, you can configure WDS to dynamically query WinSock for available ports instead of using a port range. To do this you'll have to modify a registry key on the affected server.
Modify the key
UdpPortPolicy and set it to 0. Then restart the Windows Deployment Services.
More information can be found here: http://support.microsoft.com/kb/977512/en-us
When you install Windows 7 the old fashioned way, the resolution of the desktop is automatically set to the native resolution of the screen. However during my LTI deployment I noticed that it was still set to 1024 x 768 which annoyed me to no end. After a quick look in the default MDT unattend.xml I found the solution.
If a resolution is set in the unattend.xml (<deploymentshare>\Control\100), Windows will force itself to use that resolution. If nothing is set in the unattend.xml Windows will set the native resolution of the screen. Therefore the solution is to remove the display sections in the unattend.xml. These lines should be removed:
I added a couple of applications to my newly setup LTI deployment that didn't install properly. After a search in the log files I found an entry in the ZTIApplications.log (C:\Windows\Temp\DeploymentLogs) that shed some light on the problem. Some of the applications encountered error 1632. Google soon provided me with the description of the error (link)
The Temp folder is either full or inaccessible. Verify that the Temp folder exists and that you can write to it.
As indicated the temp folder was somehow locked out. This was due to a software deployment GPO that triggered after the reboot. The software couldn't be installed which locked the temp folder. After disabling the faulty GPO the applications were deployed properly.
The error message can differ a bit as it is network card controlled. Unfortunately there is no single fix for this issue. There are a lot of causes for this issue. I will list solutions down here as I run into them.
All approved and rejected devices are added to a database. If a device is rejected WDS will not respond to requests coming from this device. The best way to solve this is to clear the rejected and/or approved devices database. To do this log on to your WDS server and run the following command:
Wdsutil.exe /delete-autoadddevices /devicetype:rejecteddevices
Wdsutil.exe /delete-autoadddevices /devicetype:approveddevices
After I disabled a couple of steps in the task sequence, I was confronted with this error that had me puzzled for a while. However it was not related to my changes. The deployment before the changes ended in errors and the clean-up didn't finish all the way afterwards. When you start a new deployment it checks if a deployment is already in process on that computer. The harddrive had a partition with the folders minint and _SMSTaskSequence on it.
There are two ways to fix this issue:
- Start into PXE and when the error is presented press F8
- In the console type: diskpart
- Type: select disk 0
- Type: clean
- Start into PXE and when the error is presented press F8
- In the console type: c:
- Type: format c: /Q
Deploying desktops can take quite some time, however using Windows Deployment Services in combination with Microsoft Deployment Toolkit 2010 update 1 automates it all. In this article I will get down and dirty with deploying Office 2010 Pro Plus with language packs using MDT.
Start with copying the DVD/ISO to a separate folder. I choose to use the English version as the base, but you can use any language you want.
Copy the contents of the Office Language Pack 2010 <language> to the same folder. You will be presented with a couple of duplicate files and folders. You can accept the folders, but don't overwrite the current version of the files. You will end up with something like this.
Step 2 is to import the whole Office 2010 application into Deployment Workbench.
- Right click Applications in your deployment share and select New Application
- Select the option Application with source files
- Enter the Application Name, Version and Language
- Select the directory where you combined the installation source and the language packs
- Specify the name of the directory that should be created
- Enter setup.exe in the command line box
- Files are being copied to the Deployment Share
Step three is to edit the application settings and create an Office customization file with the Office Customization Tool.
- Right click the Office Pro Plus 2010 x86 application and select Properties
- Click the Office Products tab
- Select ProPlus in Office product to install
- Check the languages you want to include in the install
- Fill out the Customer name field
- Select None in the Display level dropdown box
- Check Accept EULA
You can leave the Product key field empty because I'm using the KMS key. The MSP that we will create with the Office Customization Tool will include this. If you're using the MAK key you may insert it here, however do note that the product key is stored in clear text as indicated in the warning. I advise you to enter the MAK key in the Office Customization Tool where it will be obfuscated.
Click the Edit Config.xml button to confirm that the following lines are present in the generated file.
<AddLanguage Id="match" />
<AddLanguage Id="en-us" ShellTransform="Yes" />
<AddLanguage Id="de-de" />
<AddLanguage Id="nl-nl" />
The Id attribute in those XML lines is the language that will be added to the installation. Make sure that the right language has the attribute ShellTransform set to Yes.
Now click the Office Customization Tool button. You will be presented with a dialog that tells you to save the MSP file in the location <deployment share>\Applications\Office Pro Plus 2010 x86\Updates when you're done. If you don't save the file in that location the MSP will not be used during the installation.
- Select the Microsoft Office Professional Plus 2010 (32-bit) product
- In the Default File Types dialog I recommend to select the Office Open XML formats option as this is most used and supports all the formatting options in the Office applications
- Select Licensing and user interface
- Check the I accept the terms in.. option
- Select Display level None and check No cancel if you want to remove the cancel button during installation
- Edit all other options that you want changed like: Organization name
- Click File > Save As and store the file in the previously mentioned location
Office Pro Plus 2010 is now available in the Task Sequence. Don't forget to add it to your task sequence.