WDS service refuse to start with error 0xFFFFFBB3 when using more than 20 logical cpus

The other week I stumbled across a very interesting fact, a fact that the Windows Deployment Server service refused to start on a clean installed Windows Server 2008 R2. After troubleshooting for a whole day, even reinstalling the OS, reproducing the error even without any patches seemed very strange. The WDS service is a service that normally just works. The following error was logged:

Log Name: Application
Source: WDSServer
Date: 2010-10-04 17:14:23
Event ID: 257
Task Category: WDSServer
Level: Error
Keywords: Classic
User: N/A
Computer: wds.contoso.com
Description:
An error occurred while trying to start the Windows Deployment Services server.
Error Information: 0xFFFFFBB3

An important fact is that the server to be used for deployments was a retired yet powerful TS/RDS server with two six core processors using hyper threading, making it 24 logical processors.  Not likely to be the hardware specs of a regular deployment server but hey, it can obviously be scenarios where this might be an issue. Thanks goes to a colleague (Jeanette) who figured out that we could try to set the number of logical processors being used to two. Guess what, after a reboot the WDS service started just fine!

To change the number of used processors we used:

bcdedit /set {current} numproc 2

To revert this change you could use:

bcdedit /deletevalue {current} numproc

After some work with Microsoft Product Services and Support it appears to be a bug nevertheless. The limit for the number of logical processors you can have for the WDS service to start is 20. Bear this in mind…

Bug with PXE booting pre-staged machines for deployment returns event 519

There is a bug in Windows Deployment Services (WDS) in Windows Server 2008 R2 which prevents your pre-staged computers from booting via PXE. In the Event logs on the WDS server you can find event 519 stating that there are duplicate machines with the same GUID or MAC address, even though this is not true. There is a hotfix for this problem which is available from http://support.microsoft.com/kb/2028840/en-us.

The event looks like:

Log Name: Application
Source: BINLSVC
Date: 2010-09-24 10:29:04
Event ID: 519
Task Category: BINLSVC
Level: Error
Keywords: Classic
User: N/A
Computer: wds1.contoso.local
Description:
Multiple machine accounts with the same GUID or MAC address were found in Active Directory Domain Services. The Windows Deployment Services server will use the first listed machine account.

List of matching machines: CN=DEPLOYTEST1,OU=CONTOSO,DC=stenis,DC=local

Modify default profile in Windows 7 with the least amount of effort

I’ve received a question on why Microsoft stopped supporting the old way of making changes to the default user profile in Windows 7. As you might already know the only supported way to make changes to the default user profile is to make them with a local user account and then sysprep the image with an answer file containing CopyProfile=TRUE.

The question or should I say problem is that the user in question find it ineffective to make changes to the default user profile, by installing the image to a machine then make the changes and once again to sysprep and capture the image.

Fortunately there is a much more effective way to make changes (though unsupported). Just mount the image using imagex or dism, and then add or remove the files you want. If you want to change some settings they most likely stored in the registry so then you can just start the regedit.exe utility as usual and then mount the ntuser.dat file within the image to make the changes and when done just applying the changes and you are done!

Annoying Windows 7 deployment bug fixed at last

Deployment Guru Johan Arwidmark wrote a blog post today stating that there is now a hotfix that resolves a rather common problem during deployment, where one after the deployment get to choose the network location although the profile used is the domain profile and the location therefore should be “Work”. The fix has KB article number 2028749.

Patch machines during deployment with MDT 2010

In MDT 2010 you can enable two settings that during deployment of your machines will patch them automatically using a WSUS server of your choice.

Take a look at your existing task sequence(s) and look for “Windows Update (Pre-Application Installation)” and “Windows Update (Post-Application Installation)” and choose to enable them both or just the latter.

In your customsettings.ini somewhere beneath the [Default] section add the row:

WSUSServer=http://WSUSServerName

Custom commands when deploying Windows 7

I got a question the other day on a problem where a person is installing a set of applications during deployment of Windows 7, using MDT 2010. The problem is that one application requires to be run in Vista compatibility mode before it can even be installed, most likely due to a check in the installer for which Windows version is being used, a rather common compatibility issue.

One solution to this is to use Compatibility Administrator which is a part of ACT to create a so called “shim” which makes the installation go through, fooling the application that the OS is Windows Vista even though it is Windows 7. But, how do we get the shim applied during our deployment, which we want to automatic?

It is rather simple, just add a “run custom command” in the task sequence before the application is installed, which applies the compatibility shim to the machine, making the installation run through. Also note that you can run custom commands in the “applications” section in MDT2010, just add the command line to the path field and off you go!

Deployment bug found in Vista RTM

Long time no see! I have lots of things to blog about, I just haven’t had the time to do so lately. Last week though I learnt  about a tricky NetBIOS computer naming bug when deploying Vista using Windows Deployment Services (WDS). As you might know  the NetBIOS computer names cannot be longer than 15 characters and when you in Windows Vista (and all previously released Windows versions as well) change the computer name to a name with more than 15 characters you will get a warning message 
that will look something like the screenshot attached to this post.

When using Windows Deployment Services with the new option “Name and approve” the client before pushing out the image to the client, you can as you might have figured name the computer object in Active Directory and then fully automate the  installation process. In the unattended answer file in the computer name section for deploying Vista we have entered %MACHINENAME% to make sure that the computer name is not randomly generated with a name like LH-XY45YHGKL and to make sure 
that we will not get any questions to answer when deploying automatically.

We have a computer naming standard which obviously sometimes makes the computer name more than 15 characters. The bug is when you name a computer longer than 15 characters during Name and approve in the WDS. Then the unattended installation will fail at the specialize pass, without any particular error message, probably because it wants to show the same error message dialogue as when we are in the GUI version of Vista.