This post if part of the Student Project Express, a series in which I am showing how to complete a Student project using Microsoft technologies. The table of contents for the series is available here and I will keep it updated as as publish more content.

At the end of the last post, we ended up having our production machine installed, fully patched and ready to be used. It has been a quite long process with all the installations and updates we had to do so… is there any way to speed this up now that we need to create additional IDENTICAL servers?

Luckily there is… the outcome of the work we have done so far is 3 files as shown in the picture below:


The first file is the virtual hard drive, as mentioned before it is a file that basically simulates a physical drive and that can be “mounted” into virtual machines to be accessed natively (it actually can be mounted in any Windows and you can find instructions on how to do this on Windows 7 here).

The advantage of having a disk as a file is that… we can copy it! So in this case all we need to do to have an exact replica of our production server is to copy this file, change it’s name, attach it to a new virtual machine and… done!

So, let’s copy the file first. I am going to create two more folders called PreProd and Test in my Virtual Machine folder and copy the .VHD file from the Production to the PreProd one. The file is now about 10GB so this will take a while. Once this is done, let’s change the VHD file name to PreProd.vhd (always best to use consistent naming conventions).

Once this is done we can create a new Virtual Machine and attach this VHD file as its virtual HD:


Compared to when we created the production machine, the only difference is that this time we will point it to an existing VHD file, while all the remaining settings should be the same.


Now that we are done, let’s open this VM and see what happened. The new machine should come up nicely and be an exact, 100% replica of the production one which is what we wanted with one exception… the machine name is the same so if we try to fire them both up at the same time we would get all sorts of conflicts.


We may think we can just change the machine name and all will be well, but this is actually not the case because when Windows is installed, it generates a unique machine ID (the Security Identifier or SID) and this won’t change if we just change the name… so how do we get around this?

Luckily there is a very handy tool that has been designed for this very scenario called SYSPREP. To launch sysprep, just open the start menu and type “sysprep”. This should give one result (a folder called sysprep):


Clicking on it, will open the folder which will contain the sysprep utility. Just double click on it to launch it:

This will open the sysprep window. In our case let’s select the options as per the image below (more info on sysprep can be found on technet):


Once we click on OK, sysprep will perform all is tasks and then shutdown the machine… the VHD file is now our real baseline and can be used to deploy a number of different servers. So let’s copy it to the test one (which we will call… test). Once this is done, let’s start the PreProd machine again.

Windows will go through some initial setup:



And then will fire up the initial configuration utility which will ask us to enter some additional information such as the system language, the licence, the computer name (which will be PreProd for one and Test for the other of course) and define the administrator password. Note that until it is fully configured, Windows will not be able to enable the integration features and as such will capture the mouse and be a “sluggish” until we finis the configuration!






Note that even though the screen says that you must change the password, you can still use the same one for all the servers.


Just like when we buy a new PC from a store, right? Well… SYSPREP is actually the tool that PC vendors use to create their PCs so this is not surprising :)


We are now all set with out production, preproduction and test environment. Let’s take a look at our development machine. This will be the subject of the next post!