WDS

Slow WDS PXE Clients and Bad Memory

Following on from my post last week about UK Regional Settings for MDT 2013, I have been this week testing the deployment of a Lite Touch MDT image using WDS PXE over Multicast. Unlike what you will read online about Multicast, I haven’t personally had any issues with it and Multicast has worked off the bat but the problems I have been encountering are actually with Unicast, with the initial phase of PXE boot, downloading the Boot SDI and the WinPE LiteTouch WIM files.

In this case, I’ve been given eight client machines to test the deployment and we were finding that only about half of them were properly initiating the WinPE environment in a sensible timeframe with the other clients taking over 30mins just to download the Lite Touch WinPE image which obviously isn’t cricket as you should be able to lay down the entire Windows OS image is not much more time than that.

All of the machines are HP 8000 desktops with a matching hardware specification and matching firmware revisions so we were left wondering if the problem was the network, routing or such like however earlier on this afternoon, we found the issue and I have to say, it’s one of the craziest reasons I’ve seen something not working in a long time, especially considering how software defined our worlds have become.

Hynix Memory 2GB PC3-10600U-9-10

Yes, that is correct, the above is an image of a Hynix 2GB PC3-1006U-9-10 DIMM and this was the cause of our problems.

The machines in question were all configured with 6144MB of RAM in the form of three 2GB DIMMs. What we didn’t notice at an early stage and why would you really, was that some of the machines exclusively had three DIMMs of HP certified Micron memory in them and our faulting machines had a combination of HP certified Micron memory and Hynix HP certified memory.

All the DIMMs were of the same unregistered type, all of the same PC3-10600 speed and all have the same 9-10 CAS latency so it’s just crazy to think that a mismatched batch of Micron and Hynix memory could ruin things for us given that all of the other factors like registration, speed, latency and ranking were matched.

Simply by removing the Hynix DIMMs from the machines and leaving them with 4096MB made up of two 2GB DIMMs of Micron memory allowed these machines to load the Boot SDI and Lite Touch WinPE WIM files at the speed we expected to see and were already seeing on the other clients.

When we look at this logically, you can see why our issue was a memory problem because the download of the Lite Touch WinPE WIM is done into memory and the hard disk is not touched at this point but I cannot remember the last time I saw a simple DIMM cause so much of a problem. These days we automatically assume that hardware works and that our problems exist in software due to the configurable nature of everything but this was certainly a lesson to never forget the simple things in computing: the basic hardware like processors, memory, motherboards and the like.

Access Denied When Approving a Pending WDS Client

With WDS you can configure the server to automatically respond to known clients. You can additionally affect the behaviour for unknown clients.

In my environment I have it configured to answer the clients PXE boot request however they are not automatically served for two reasons:

  1. I may want to assign them to a different image or elect to manually install it without the unattended settings
  2. I may want the client to not automatically join the domain
  3. I want to name the something better than MININT-000000ABCDEF

When an unknown client connects to the WDS server the user is presented with a message to say that their request is pending administrative approval on the server.

Using the WDS console, you select the Pending Devices tree and select the option to Name and Approve a client, however doing so presents you with an Access Denied error.

Read more…

PXE Boot Errors When Using a WDS Client

Whilst configuring my WDS server to deploy Windows 7 in an unattended fashion, I’ve been using a VMware virtual machine to test the WDSUnattend.xml file and the ImageUnattend.xml files.

I ran into a problem whereby the VMware machine was reporting the following error whilst trying to PXE (Pre-eXecution Environment)

PXE-E55 ProxyDHCP: No reply to request on port 4011

Read more…

Deploying 64-bit with WDS

So as you probably guessed by my last couple of blogs, I’ve been hacking around with WDS, and there is something weird I’ve noticed.

I have a VMware ESXi virtual machine which is running on a 64-bit box with the VM configuration set to Vista 64-bit, however when I boot the VM into network boot mode, I only see the 32-bit images? How so?

I checked my WDS server and sure enough I have my 32-bit and 64-bit images all their ready to rock, but nothing.

I did a bit of a search and discovered this one. By default it seems that WDS does not allow the client to determine it’s processor architecture and will always dish out a 32-bit image.

Running the following command however will allow the client to determine the architecture and hence offer up the 64-bit images. I haven’t tested this yet but will do soon enough.

wdsutil /set-server /architecturediscovery:yes

Slipstream Integration for Windows Vista DVD

So I know that Windows 7 is Release Candidate now, but that doesn’t mean people don’t still want to install Windows Vista, and what a better time to rebuild your Vista box if you don’t fancy the step to 7 than now?

I spent a few hours last night working on my Vista image on my WDS (Windows Deployment Server) and I’m really happy with it. I’ve never really meddled with the Vista DVD much in the past because I got confused by the Windows Image format and how to service it initially but once you get your head round it, it’s really easy.

I’ve now got a Vista DVD with the following integrated:

  • Service Pack 2 RTM
  • Internet Explorer 8 RTM
  • Remote Server Administration Tools

Read more…