Easier ways of setting up Windows Server 2008?

I need to set up a few Server 2008 dev servers and I'm struggling with how to do this efficiently.

With any debian-based distro, I pop in a CD, run through the install, reboot, apply apt-get update and I'm done.

After Server 2008 installs, I have to do run through Windows Update, reboot, update, reboot, etc.

Is there an easier way of doing the updates, without the multiple reboots?

From serverfault completenoob

• Yes. Run Linux.

  gWaldo : These kinds of comments aren't at all helpful.
  From MisterITGuy

• Not really, that's just one of the quirks of Windows.

  The only thing I might suggest (if you're not doing this already) is to set yourself up a WSUS server. This way, you download all the appropriate Windows Updates to your WSUS server from Microsoft, and then your servers download updates from your WSUS server. This is quicker than downloading updates from Microsoft every time, and will be considerably less bandwidth intensive.

  mfinni : You can also slipstream your Windows install media to already include the latest service pack, which should eliminate at least one reboot. Also, for a dev environment, perhaps not all the latest Windows updates are needed. In fact, depending on what your dev requirements are, maybe you should look at some sort of imaging product like Windows Deployment Services, so you have a standard build.
  From Ben

• That's pretty much how Windows works, and you're pretty much stuck with it.

  Now I can see you asking yourself:

  Why the heck does Windows do that when any self respecting Linux can do all the updates in one go?

  The answer comes down to how Windows and Posix *nixes handle the open file problem. On Windows, if a file is open it also has a DenyWrite lock on it and the file can not be written to. Such as for an update. On Linux, everything is a file, and all files can be updated, so the file just gets updated. If the file can't be updated for some other reason the installer throws a cryptic error and it gets tricky to figure out why the update failed.

  Because Windows can only update certain files during the reboot process, you get cases where you need multiple reboots to apply certain patch-sets. This happens the most when updates for different products overlap files in some way, and that later update needs the previous update to be actually applied before it can update. Windows has gotten A LOT better about dependency checking over the years, before Windows Update it was common practice to apply each update individually with its own reboot[1], but there are still some things it gets confused about; especially when it is also doing OS, IE, and Media Player patches all at the same time.

  The last time I staged up a Server 2003 server (not R2) it took four reboots to get everything updated, not including the service pack. If I'm staging up a SLES 9 server (dates from about the same time, on a 2.6.4ish kernel), that update set is also going to be fearsome. The 'rcd' process used on that distro will get confused by the size of the update, so I would have to update just that a couple of times before I could update the entire patch-set. It isn't multiple reboots, but it does require multiple applications of the update process. And on SLES9, RCD can take a bloody age to chew through large update sets, so that SLES9 server would probably finish updating everything after the Win 2003 server would[2].

  [1] There were some tools out there to help 'chain' updates, but different IT shops had different ideas about using these tools on production systems.
  [2] Which just shows the quality of the rcd process on that distro. So glad that died with SLES11.

  gWaldo : Thank you for providing a clear answer. +1 for not making me type that explaination... (and because you're right.)
  From sysadmin1138

• You can slipstream installs of Windows with all the patches... but this can be a very long & difficult process to do. If you frequently need to deploy new servers (either in a lab... or in production or both) This might save you some time & headaches... but I doubt it. Your best bet, is to setup a WSUS server or build an offline update CD every month-or-so... & run that immediately after an install. This doesn't avoid having to do reboots... but can definitely remove some of the pain of it. (the offline update cd will auto reboot if an update requires it & resume automatically)

  The advantage to building your own slip-streamed image... is that you can also pre-install any necessary drivers or applications you might need. But there really isn't a great method of building the image. Microsoft provides an AIK tool to do this, but you need to manually download each patch, extract it, and apply to an image.

  The advantage to using the offline-wsus package is that it takes minimal time to build the cd (need to wait on the downloads & building the iso/burning) and you can use it on every server. Both production & lab. Unfortunately, you are relying on a 3rd party tool to manage this process, but historically has shown that they're up to the challenge. (I've used it for 6 years+ with only minor problems that were quickly resolved.) You also can't pre-install other applications in the image. There are other tools out there that can make a single-click install of multiple applications, but that's a whole other conversation.

  mfinni : If you're doing a serious amount of building, you probably don't want to make new images monthly - I would say quarterly if you really need to be up-to-date with in one step, and probably annually or semi-annually for everybody else. Combining that with a WSUS server, you're pretty set.
  From TheCompWiz