February 2009 - Posts

Fixing WDS Long Boot Times

Here’s a little tip from a colleague of mine, who we’ll call Geoff for no reason other than that that is his name.

When deploying images from Windows Deployment Services (WDS), sometimes the WDS server seemingly does not respond for about 10-15 seconds, even if the response delay is set to 0 seconds. The server will be authorised, it will have boot images, but the PXE “spinning bar” sits there attempting to hypnotise the user instead of booting from the network.

The cause appears to be DHCP configuration. Here’s a screenshot of the WDS console attempting to explain option 60:

WDS-Option-060

And here’s the help information for option 60, referenced directly by the link at the bottom of the dialog:

You can set the Dynamic Host Configuration Protocol (DHCP) configuration options on the DHCP tab of the server properties. The default configuration of Windows Deployment Services assumes that the Microsoft DHCP Server service and Windows Deployment Services server are on separate physical computers. If DHCP and Windows Deployment Services are running on the same computer, then you should configure the following options. You can also configure these options at the command prompt.

  • To configure DHCP option 60, run:
    WDSUTIL /set-server /DHCPoption60:yes
  • To configure port 67, run:
    WDSUTIL /set-server /usedhcpports:no

The reason you must configure these options in this scenario is because, DHCP must inform the client computer that there is a PXE server listening on the network by including DHCP option tag 60 in the DHCPOffer packet. In addition, because DHCP listens on port 67 by default, when Windows Deployment Services and DHCP exist on the same computer, the Windows Deployment Services PXE server is not able to listen on port 67 for incoming PXE boot requests.

As you can see, the documentation is of no help. So instead of trying to set option 60 to “PXEClient”, set it to the IP address of the WDS server.

I did this in my test environment and the average boot time of both new and existing PXE clients went from 25 seconds to 2 seconds.

Awesome Geoff!

Posted by davidr with no comments
Filed under: ,

Australians Can’t Drive

For the past couple of months I’ve been commuting from my house in suburban Sydney to a customer site in Orange, about 3 hours (225km, 140mi) away. About half of the commute time is highway driving, with a speed limit anywhere from 80km/h to 110km/h (50mph – 65mph).

Now for those who don’t know Australian country highways, it’s pretty common for the highway to be a single lane anywhere up to 90% of the time, with irregular short overtaking zones (1-5km long) where the road widens to 2 lanes. Other than those zones, you can overtake on the wrong side of the road if the road is suitably marked, and you have sufficient courage.

With that in mind, here’s what I was faced with last week, showing only problems exhibited by fully licensed drivers (no L (Learner) or P (Provisional) plate holders), on my commutes; not only from home to customer site, but also on the 50km trip from hotel to the customer site:

  • Drivers that would overtake a few cars in the overtaking zone, then, as they were passing the last car they wanted to pass, would slow down to ensure that at the end of the overtaking zone, the car being overtaken would slot in behind them (thus holding up the other 3 people who wanted to pass). I’d call it an accident except that it happened in 5 overtaking zones in a row. Here’s a hint: The sign says Keep Left Unless Overtaking. That means you, ***!
  • Drivers who travel 20% below the posted limit until they reach the overtaking lanes, whereupon they accelerate to 110% of the posted limit, preventing those who were held up from overtaking. You know who you are.
  • Drivers who, at the first sign of rain, panic and travel 30% or more below the posted limit. If you can’t drive at or near the speed limit, pull over and let those who are being held up pass.
  • Drivers who, at highway speeds (110km/h is 30 metres every second) feel the need to sit 5m or less from your rear bumper – if I have to stop quickly, you’ll place your engine in my back seat, and I won’t be nice;
  • Drivers who are so focused on passing the slow B-Double truck in front of them that they position themselves 10m behind the truck, weave back and forth so they can see past, then take 2km to pass on the wrong side of the road because they’re scared of exceeding the speed limit.

Does no-one teach highway craft any more?

I know my father showed me the different ways to drive on highways. And I didn’t even have a license at the time – I was 13 (no I wasn’t driving, he explained it to me):

  • If you’re going to overtake on the wrong side of the road, do it quickly. Start 50-100m from the vehicle to overtake, accelerate so that as you pull into the oncoming lane, you’re moving significantly faster than the overtaken vehicle. Continue accelerating until you move back to your own lane, thus minimising the time and distance in the wrong lane, then return to the speed limit;
  • If you overtake in the overtaking lane, DO IT QUICKLY AND GET OVER. You never know when someone faster than you will pop up in the mirror. It might even be an emergency vehicle trying to get somewhere.
  • Be aware of the other drivers around you. That means if there are no overtaking opportunities, and you’re holding up a stack of cars (perhaps more than 4 or 5), pull over to the emergency lane for a few seconds so they can pass. Everyone is less stressed, and there’s no pressure on the faster cars to do something stupid;
  • If you’re travelling below the speed limit, don’t accelerate in the overtaking lanes to prevent people passing you. Not only is it rude, it’s STUPID.
  • Travel at or near the speed limit, assuming reasonable conditions. If it’s a bright sunny day, and you’re travelling at 75% of the limit, then you are obstructing traffic. It’s an offence rarely prosecuted today;
  • Rain does not erase your memory. Two water drops on the windscreen does not mean you forget how to drive. The most you should do in that scenario is watch for heavier rain (in which case you might drop 5 km/h, or 10 in heavy rain).

Now admittedly 20 years ago the police could be, and frequently were more lenient about speeding than their government masters permit today. 20 years ago they didn’t blink if you were moving along at a slightly more rapid pace than the posted limit, as long as the speed differential between the cars travelling “together” was close to 0 (that is to say, if everyone is moving at 120 in a 100 zone, it’s perhaps safer to do the same rather than travel 16% slower and create congestion, frustrate other drivers and potentially incite those frustrated drivers to make a fatal mistake). Today, of course, if you’re travelling at 105 in that same 100 zone, you’re worse than a murderer.

Posted by davidr with no comments

Microsoft Doesn’t “Get” Documentation (In Other News, Water is Wet)

I don’t mean to say that TechNet and MSDN are bad – quite the opposite in fact. I don’t know that I’ve ever seen such a huge repository of documentation. But what always appears to be missing is the “overview” or “tie it all together” document, required so that the student knows what he doesn’t know.

Here’s a case in point from the Windows 2000 beta, and likely Windows 2003 as well – by the time Windows 2003 came around I already had the knowledge so I wasn’t hunting for it. What’s the first step in getting the Remote Installation Service going?

Veteran users of RIS from Windows 2000 and Windows 2003 will know that the answer is simple – RISetup.exe on the server. But where was that documented? All the “Quick Start” type guides spoke of having the Windows media and your applications being MSIs, then (paraphrasing), “set up your RIS Server and add the images to it”. No mention of RISetup.exe or RIPrep.exe to be found. No documentation on the SIF files, their locations etc. Nothing on post-RIPrep customisation, or what you could and couldn’t do while the image was still on the server.

Nor was there guidance on sizing, performance, deployment, multiple site deployments etc – it seemed that it was expected that every admin and consultant would just “work it out”.

The latest item in this vein, funnily enough, is Windows Deployment Services – the replacement for RIS. Well not WDS, specifically, but the Microsoft Deployment Toolkit or MDT. MDT is built on top of WDS, and is for creating hardware-independent images and being able to deploy device drivers, applications, patches and customisations on top of a standard Windows image – so you can plaster Vista across your network in no time flat.

Except that once again, despite thousands of pages of documentation, the initial “here’s how you get a basic one going” is spread across the entirety of the MDT documentation pack. You have to know which of the MDT documents (there are about 25) contains the information you want, and it’s not the planning guide or the Getting Started guide.

No, critical information about the Distribution$ share (wait, how do I even know about this share?) is in the helpful documents, “Workbench Imaging Guide” and “Image Engineering”. But you also need the documents, “Infrastructure Remediation Feature Team Guide” and “Preparing for LTI Tools”.

Infrastructure Remediation Feature Team Guide? Are you kidding me!? I’m deploying a new SOE not building a new data centre!

Here’s what I think a “Getting Started” guide should look like for MDT, remembering that this is targeted at the administrator who has never seen MDT before:

  1. Install Windows Deployment Services. Links here to separate documents, one each describing a vanilla install of WDS on a supported OS– i.e. add the role for Windows 2008, or install SP2 for Windows 2003 and then add the Windows Component.
  2. Create this hierarchy (Distribution$) on your server and share it. Use this tool and this wizard.
  3. Install the AIK and MDT (with links to the downloads). Maybe even make it an unattended install so the right components are installed!
  4. Use this wizard to put a copy of a client OS on the server (two links – one for Vista/2008 and the other for XP/2003).
  5. Use this wizard to put an MSI application on the server (Browse to any MSI, Add to the “image”)
  6. Use this wizard to add a new driver to MDT (Browse to the .INF files)
  7. Here’s how you create a Capture Image. (Use this tool and this tool and this tool.)
  8. Here’s how to capture the PC using the capture image.
  9. Here’s how to deploy the simple image.

Each step should have links into the documentation hierarchy. But no admin I know has the time to read 2000 pages of documentation so he can roll out a new desktop.

The quick list above is probably 75% of the process for most administrators. Each step can describe the tools being used – what the shortcut name is for a GUI tool, or the executable name for a command line tool. After all, how many administrators still don’t know about PEIMG and ImageX?

Also MIA in the documentation are the answers to all the initial “WTF”-type questions. What’s a task sequence? Why and when would I create a new one? What are the phases of installation? How do I know what piece goes where (e.g. application deployment – Post Install or Restore State)?

Where’s the document that shows how things get used (rather than documents describing what a folder is for)? Or that says, “Here’s an example of a really good way to start with this hierarchy of new folders”?

And my biggest annoyance (MDT specific this one) is that the MDT documentation seems to assume a team of 30 or 40 people – dozens of pages in the MDT documentation set deal with the need for more than half a dozen different teams, all with their own roles and responsibilities. For example, the “Stablilizing Phase” has the following management roles (ignoring actual, you know, workers), which all seem to be assumed to be separate people:

  • Release Manager
  • Change Owner
  • Training Coordinator
  • Communications Coordinator
  • Documentation Coordinator
  • Testing Coordinator

Sure it’s nice to have that for the dozen companies with that many spare and underutilized IT staff, but we’re not all deploying 100,000 machines and we don’t have time to figure out all the connecting bits ourselves.

Posted by davidr with 1 comment(s)