Recently we’ve been having some random strangeness happening with our Windows Deployment Services (WDS) server in the office. A look around the environment didn’t uncover any “A-HA!” moments. All looked as it should. Performance counters and metrics were all where they should have been. But it didn’t change the fact that there was a noticeable, sudden downturn in performance of the WDS environment. We looked at the underlying SAN, the virtualization platform, the network infrastructure, the VMs themselves. They all were returning smiling happy faces and saying “Nothing to See Here.”
Now all this digging around did unearth some other issues that we needed to address, especially around patching of our VMs. I found a couple that somehow hadn’t been patched in over 2 1/2 years. Oops. That’s not really a good thing. The WDS server wasn’t one of those, but it did have quite a few pending so I took the opportunity to take it offline and do some maintenance and patching (and in the process of running terminal sessions from within VM console sessions from within RDP sessions I managed to trigger updates to our SAN. But that’s a story for a different blog post. Suffice it to say it all ended up just fine).
Patches downloaded, installed, server rebooted. A quick test . . . no change in the performance. Grrrrrrrrr. But not really unexpected.
And so, in the grand tradition of IT expediency and pragmatism I had the thought “I could have built a new server faster than this.” So after consulting with a few colleagues we decided I should do just that. It allowed us to tick a few different boxes anyway, and it just happened to coincide with some unexpected free time in my schedule. So off I went!
We decided to go with a side-by-side migration, basing the new WDS server on Windows Server 2012 R2, rather than an in-place upgrade. This was a good choice for us for lots of reasons, not least of which it is the recommended approach by Microsoft for most things. So we put together our big-picture plan, which looked like this:
- Do your homework. I’ve had some experience with WDS, but not massive amounts in the wild, so before I started down this path I needed to make sure I had enough knowledge to be able to confidently do the work without any major, preventable issues. I had a look through the topics found in course 20415-Implementing a Desktop Infrastructure, and then I headed off to TechNet. This article proved to be a useful starting point for me as well. It also gave me a useful basic checklist to make sure I didn’t miss any important steps.
- Plan and Install the Windows Server 2012 R2 VM. Using the VM configuration of the original WDS server as a starting point I made and documented the decisions about configuration and build of the VM. There were the obvious OS things like “Yes, it has to be a member of the domain”, computer name, static v. dynamic IP addressing (I went with static, so I could easily change the IP address later to take over the IP of the legacy server, thus reducing the need to reconfigure our network infrastructure), but also made decisions about some of the less obvious stuff, like how many and what type of virtual disks to use, where to store those disks (SCSI, in the shared storage, thin-provisioned), how much and what type of memory (dynamic, 2GB start-up 16GB max). Once that was done I created the VM and the disks, hooked up our WS2012R2 iso and built the VM to spec. I also tried to do as much patching as possible done here so I didn’t get interrupted when I was doing the WDS work.
- Set up the storage. We made the decision to make use of a few of the new features in WS2012 and WS2012R2, as well as trying to future-proof the configuration as much as we reasonably could. So what we decided in this case was to take the data disk (our second virtual disk) and set it up within Windows as part of a storage pool. If we need more storage later on we can create new virtual disks, and add them to the storage pool. Once we had that, I created a single virtual disk from that pool. Again, in the future we can extend that virtual disk if required, allowing us to relatively quickly and easily increase the storage available to hold our images. I also enabled Disk-Deduplication on the volume that was based on that virtual disk. For us, this was all about maximizing storage/minimizing storage use. WDS already de-duplicates the data in the WIMs, but it shouldn’t hurt for all of the other files.
Install and configure WDS services. This was probably the most straightforward part of the process. Using the checklist I got from TechNet, I added the Windows Deployment Services role to our new VM. I wanted a new server, but not new images, so from there the configuration was really nothing more than exporting the boot and install wims from the legacy WDS server, and then adding and configuring them. On the legacy server I mapped a drive to the data drive on the new server and used that as the target for all the exports. We made the decision to only export the current wims that we use, not all the historic wims. So I really only had 4 boot wims and 5 install wims to deal with. On top of that I needed to document and copy out the unattendimage.xml files that correspond to those wims.This really wasn’t anything more than an exercise in documentation and paying attention to detail. When you export an image from WDS it makes a copy of the wim file, but does not include the other properties/configurations of the image, like unattend files. So I made sure that I documented and copied out all the unattend files that I were going to need, and then I did our image exports. Once those were done I created new images on our new WDS server, using the exported WIMs, and then going in and configuring each image to use the corresponding unattend file. Fortunately, I only had a handful of images so it wasn’t a big deal. If I were to do this again I’d spend a little time digging around in PowerShell to see if there is a command that would allow me to script that or at least do it in bulk.
- Test the new server. This was an easy one. Since we only use our WDS environment late in the day, I could take a couple of client machines and use for testing. So that’s what I did. I shutdown the legacy WDS server, and then changed the IP address of the new server to take over from the legacy server. This meant I did not have to go and change firewall, networking and DHCP settings. I restarted the WDS services and then booted up some clients.The first tests proved to be reasonably successful. The clients all successfully found the server, connected to the TFTP service and deployed images. It did reveal a couple of minor configuration errors I had made. Specifically, I had forgotten to set the boot image priorities and timeouts, and I had used the wrong unattend file for one image. Minor configuration issues that were easily fixed in about 5 minutes. The second test went as planned. No issues. However, the jury is still out on the performance issues. We won’t really know until we put it under are normal loads. It seemed quicker, but that was just the eyeball test. Regardless we have a leaner and meaner WDS server than we did before, so overall a worthwhile project anyway.
- Phase out the legacy server. I are quietly confident that the new server will function as required, and initial testing indicates that it will cope with the workload. So we are shutting down the original VM on a semi-permanent basis, but will leave it registered on our virtualization platform for the next 2 weeks. If we encounter any major issues we can quickly shut down the new server and spin up the original. If we are all clear after two weeks I will be delete the VM and all its files from our virtualization platform. However, I have taken a copy of the virtual disk that contained all the images for the legacy WDS server, and it is stored on external storage. If push comes to shove I can attach to the VM and get access to those wim files.
- Monitor and maintain. Our initial testing indicates that the new server is performing better than the last, but I haven’t received definitive proof as wet. That will likely occur when we do our first large-scale rollouts using the new WDS environment. But all signs are looking good for new.
- Write blog post about it. Done.
Obviously, this wasn’t a hugely technical article, more of an overview of the process and what I went through. There was a lot of good stuff in TechNet around WDS server management, so if you’re embarking on a WDS project you might want to start there.