Enabling quick server rollouts with Sysprep

At the beginning of this chapter, we walked through the process of installing the Windows Server 2019 operating system onto your new server. Whether this was a physical piece of hardware or a virtual machine that we were working with, the installation process was essentially the same. Plugging in the DVD or USB stick, booting to it, and letting the installer run its course is an easy enough thing to do, but what if you need to build out ten new servers instead of just one? This process would soon start to get tedious, and it would seem like you were wasting a lot of time having to do the exact same thing over and over again. You would be correct—this does waste a lot of time, and there is an easier and faster way to roll out new servers as long as you are building them all from a relatively similar hardware platform. If you are building out your servers as virtual machines, which is so often the case these days, then this process works great and can save you quite a bit of time with new server builds.

Now, before I go too far down this road of describing the Sysprep process, I will also note that there are more involved technologies available within the Windows infrastructure that allow automated operating system and server rollouts that can make the new server rollout process even easier than what I am describing here. The problem with some of the automated technologies is that the infrastructure required to make them work properly is more advanced than many folks will have access to if they are just learning the ropes with Windows Server. In other words, to have a fully automated server rollout mechanism isn't very feasible for small environments or test labs, which is where a lot of us live while we are learning these new technologies.

So, anyway, we will not be focusing on an automation kind of approach to server rollouts, but rather we will be doing a few minutes of extra work on our very first server, which then results in saving numerous minutes of setup work on every server that we build afterward. The core of this process is the Sysprep tool, which is baked into all versions of Windows, so you can take this same process on any current Windows machine, whether it be a client or a server.

Sysprep is a tool that prepares your system for duplication. Its official name is the Microsoft System Preparation Tool, and to sum up what it does in one line, it allows you to create a master image of your server that you can reuse as many times as you want in order to roll out additional servers. A key benefit to using Sysprep is that you can put customized settings onto your master server and install things such as Windows Updates prior to Sysprep, and all of these settings and patches will then exist inside your master image.

Using Sysprep saves you time by not having to walk through the operating system installation process, but it saves you even more time by not having to wait for Windows Update to roll all of the current patches down onto every new system that you create.

Now, some of you might be wondering why Sysprep is even necessary. If you wanted to clone your master server, you could simply use a hard disk imaging tool, or, if you were dealing with virtual machines, you could simply copy and paste the .VHDX file itself in order to make a copy of your new server, right? The answer is yes, but the big problem is that the new image or hard drive that you just created would be an exact replica of the original one. The hostname would be the same, and, more importantly, some core identification information inside Windows, such as the operating system's security identifier (SID) number, would be exactly the same. If you were to power on both the original master server and a new server based on this exact replica, you would cause conflicts and collisions on the network as these two servers fight for their right to be the one and only server with that unique name and SID. This problem exacerbates itself in domain environments, where it is even more important that each system within your network has a unique SID/GUID—their identifier within Active Directory. If you create exact copies of servers and bring them both online, let's just say neither one is going to be happy about it. If you do this inside a production environment, you can wreak havoc on your network. I know from personal experience what it looks like to help someone recover their domain after a domain controller's hard drive was simply copied, pasted, and turned on as a second server. It's the definition of a bad day.

Sysprep fixes all of these inherent problems with the system duplication process by randomizing the unique identifiers in the operating system. To prepare ourselves to roll out many servers using a master image we create with Sysprep, here is a quick-reference summary of the steps we will be taking:

1. Install Windows Server 2019 onto a new server
2. Configure customizations and updates onto your new server
3. Run Sysprep to prepare and shut down your master server
4. Create your master image of the drive
5. Build new servers using copies of the master image

And now let's cover these steps in a little more detail.

Installing Windows Server 2019 onto a new server

First, just like you have already done, we need to prepare our first server by getting the Windows Server 2019 operating system installed. Refrain from installing any full roles onto the server, because, depending on the role and its unique configuration, the Sysprep process that we run shortly could cause problems for individual role configurations. Install the operating system and make sure device drivers are all squared away, and you're ready for the next step.

Configuring customizations and updates onto your new server

Next, you want to configure customizations and install operating system updates onto your new server. Each setting or installation that you can do now that is universal to your batch of servers will save you from having to take that step on your servers in the future. This portion may be slightly confusing because I just told you a minute ago not to install roles onto the master server. This is because a role installation makes numerous changes in the operating system, and some of the roles that you can install lock themselves down to a particular hostname running on the system. If you were to do something like that to a master server, that role would more than likely break when brought up on a new server. Customizations that you can put into place on the master server are things such as plugging in files and folders that you might want on all of your servers, such as an Admin Tools folder or something like that. You could also start or stop services that you may or may not want running on each of your servers, and change settings in the registry if that is part of your normal server prep or hardening process. Whatever changes or customizations you put into place, it's not a bad idea to run a full slew of tests against the first new server that you build from this master image, just to make sure all of your changes made it through the Sysprep process.

Now is also the time to let Windows Update install and to put any patches on this new server that you want to have installed on all of your new servers in the future. There is nothing more frustrating than installing a new operating system in 5 minutes, only to have to sit around and wait 4 hours for all of the current updates and patches to be installed before you can use the new server. By including all of these updates and patches in the master image, you save all of that download and installation time for each new server that you spin up.

Running Sysprep to prepare and shut down your master server

Now that our master server is prepped how we want, it is time to run the Sysprep tool itself. To do that, open up an administrative Command Prompt and browse to C:\Windows\System32\Sysprep. Now you can make use of the Sysprep.exe utility inside that folder to launch Sysprep itself.

As with many executables that you run from Command Prompt, there are a variety of optional switches that you can tag onto the end of your command to make it do specific tasks. From your Command Prompt window, if you simply run the sysprep.exe command, you will see a graphical interface for Sysprep, where you can choose between the available options, as shown in Figure 2.36:

Figure 2.36: Sysprep options

Since I always use the same set of options for Sysprep, I find it easier to simply include all of my optional switches right from the command-line input, therefore bypassing the graphical screen altogether. Here is some information on the different switches that are available to use with sysprep.exe:

• /quiet: This tells Sysprep to run without status messages on the screen.
• /generalize: This specifies that Sysprep is to remove all of the unique system information (SID) from the Windows installation, making the final image usable on multiple machines in your network, because each new one spun up from the image will get a new, unique SID.
• /audit: This restarts the machine into a special audit mode, where you have the option of adding additional drivers into Windows before the final image gets taken.
• /oobe: This tells the machine to launch the mini-setup wizard when Windows next boots.
• /reboot: This restarts when Sysprep is finished.
• /shutdown: This shuts down the system (not a restart) when Sysprep is finished. This is an important one and is one that I typically use.
• /quit: This closes Sysprep after it finishes.
• /unattend: There is a special answerfile that you can create that, when specified, will be used in conjunction with the Sysprep process to further configure your new servers as they come online. For example, you can specify in this answerfile that a particular installer or batch file is to be launched upon the first Windows boot following Sysprep. This can be useful for any kind of cleanup tasks that you might want to perform, for example, if you had a batch file on your system that you used to flush out the log files following the first boot of new servers.

The two that are most important for our purpose of wanting to create a master image file that we can use for quick server rollouts in the future are the /generalize switch and the /shutdown switch. /generalize is very important because it replaces all of the unique identification information, the SID info, in the new copies of Windows that come online. This allows your new servers to co-exist on the network with your original server, and with other new servers that you bring online. The /shutdown switch is also very important because we want this master server to become sysprepped and then immediately shut down so that we can create our master image from it.

So, rather than simply throwing all of the switches at you and letting you decide, let's take a look at the ones that I typically use. I will make use of /generalize so that I make my new servers unique, and I also like to use /oobe so that the mini-setup wizard launches during the first boot of Windows on any of my new systems. Then, I will of course also use /shutdown, because I need this server to be offline immediately following Sysprep so that I can take a copy of the hard drive to be used as my master image. So, my fully groomed sysprep command is shown in the following code:

sysprep.exe /generalize /oobe /shutdown  

After launching this command, you will see Sysprep moving through some processes within Windows, and after a couple of minutes, your server will shut itself down, as shown in Figure 2.37:

Figure 2.37: Sysprep and shutting down

You are now ready to create your master image from this hard disk.

Creating your master image of the drive

Our master server is now shut down, and we are ready to create our master image from this server. If it is a physical server, you can use any hard disk imaging utility in order to create an image file from the drive. An imaging utility like those from the company Acronis will create a single file from your drive. This file contains an image of the entire disk that you can use to restore down onto fresh hard drives in new servers in the future. On the other hand, most of you are probably dealing with virtual servers most often in your day-to-day work lives and prepping new servers in the virtual world is even easier.

Once our master server has been sysprepped and shut down, you simply create a copy of the .VHDX file. Log into your Hyper-V Server, copy and paste the hard disk file, and you're done. This new file can be renamed WS2019_Master_withUpdates.VHDX , or whatever you would like it to be named, in order to help you keep track of the current status on this image file. Save this image file or copy of the .VHDX file somewhere safe on your network, where you will be able to quickly grab copies of it whenever you have the need to spin up a new Windows Server 2019.

Building new servers using copies of the master image

Now we get to the easy part. When you want to create new servers in the future, you simply copy and paste your master file into a new location for the new server, rename the drive file to be something appropriate for the server you are creating, and boot your new virtual machine from it. Here is where you see the real benefit from the time that Sysprep saves, as you can now spin up many new servers all at the same time, by doing a quick copy and paste of the master image file and booting all of your new servers from these new files. No need to install Windows or pull out that dusty installation DVD!

As the new servers turn on for the first time and boot into Windows, they will run through the out-of-box-experience, mini-setup wizard. Also, in the background, the operating system gives itself a new random and unique hostname and SID information so that you can be sure you do not have conflicts on your network with these new servers.

For example, before running Sysprep and creating my master image, the server that I was working on was named DC1 because I had originally intended to use it as a domain controller in my network. However, because I had not installed the role or configured anything domain-related on it, this server was a perfect candidate for displaying the Sysprep process and so I used it in our text today. I sysprepped it, shut it down, made a copy of its .VHDX file (to be my master image file), and then I started DC1 back up. You can now see inside the system properties that I am back to having a randomized hostname, and so if I still want to use this server as DC1, I will have to rename it again now that it has finished booting through mini-setup, as shown in Figure 2.38:

Figure 2.38: System properties

Hopefully, this process is helpful information that can save you time when building out new servers in your own environments. Get out there and give it a try the next time you have a new server to build! You can further benefit yourself with the Sysprep tool by keeping many different master image files. Perhaps you have a handful of different kinds of servers that you prep regularly—there is nothing stopping you from creating a number of different master servers and creating multiple master images from these servers.