There are many advantages to using a single image to deploy all servers across your organization. Consolidating images can save you and your organization time, money, and disk space. Now you can have an easy, predefined, trainable process to deploy new servers. This tutorial will teach you how to accomplish this in a manner that does not require top level technical expertise, or advanced scripting knowledge.
Sysprep and Server Roles
When first trying to put this solution together the first thing you will realize is windows has limited support for deploying server roles through Sysprep. My first reaction was one of disbelief, but these things happen it’s not a perfect world. Below you can see a table with the main supported and unsupported roles.
Windows Server 2008
Windows Server 2008 R2
|Active Directory Certificate Services (AD CS)||No||No|
|Active Directory Domain Services (AD DS)||No||No|
|Active Directory Federation Services (AD FS)||No||No|
|Active Directory Lightweight Directory Services (AD LDS)||No||No|
|Active Directory Rights Management Server (AD RMS)||No||No|
|Hyper-V™||Not applicable||Yes -Not supported for a virtual network on Hyper-V™.|
|Network Policy and Access Services||Yes||No|
|Network Policy Routing and Remote Access Services||Yes||Not applicable|
|Remote Desktop Session Host (Terminal Services)||Yes-Not supported in scenarios where the master Windows image is joined to a domain.||Yes-Not supported in scenarios where the master Windows image is joined to a domain.|
|UDDI Services||No||Not applicable|
|Web Server (Internet Information Services)||Yes-Not supported with encrypted credentials in the Applicationhost.config file.||Yes-Not supported with encrypted credentials in the Applicationhost.config file.|
|Windows Deployment Services (WDS)||No||No|
|Windows Server Update Services (WSUS)||No||No|
If your organization is like mine the majority of servers deployed use roles that are unsupported by Sysprep, meaning you cannot simply define a role to be installed when Sysprep runs through the answer file. Since roles cannot be installed by Sysprep, one would conclude that the best way to template out your servers is to create a template for each role, .(i.e.1 for Exchange 2010 MB, 1 for CAS, 1 for HUB., 1 for Domain Controller, and 1 for Web Server etc.) This theory works well you simply prepare a server with all prerequisites for a role then Sysprep that server and you have a template for that role. The down side is this means multiple templates taking up valuable disk space in your infrastructure.
The solution I have authored uses the Sysprep answer file to call a .cmd file once OOBE (Out of Box Experience) completes but before explorer and the desktop launches. Using this logic, we can create a batch file that, with minimal deployment effort, will call a series of PowerShell scripts that will install the most commonly used roles for the most commonly used servers in your organization.
In theory this means one template for Standard Edition and one template for Enterprise edition with a master script folder in each that we can use to install any role prerequisites during initial spin up. This solutions is hypervisor agnostic so it can be performed with any Virtualization technology that supports templates. Below you will find the steps we are going to take to complete, while not difficult it is time consuming so let’s get started.
Steps for Completion
1) Get PowerShell scripts
2) Create .cmd script
3) Create Sysprep answer file with appropriate settings
4) Create Answer File
5) Create master image
6) Run Sysprep
7) Create Template from Syspreped machine
8) Run Syspreped machine and test
Get PowerShell Scripts
Step 1 is actually quite simple. If you are using well documented roles for the servers such as Exchange 2010, Web Servers, etc., script creation is a breeze. For this example we will use Exchange Roles (http://technet.microsoft.com/en-us/library/bb691354.aspx). To create my scripts I simply copied the PowerShell code of the Microsoft website listed above, inserted it into a text file and saved it as a .ps1 file. I used the cmdlets available to create scripts for Exchange CAS and HUB, Mailbox, and all roles for a single server deployment. Here are my examples:
Code: Import-Module ServerManager
Code: Import-module servermanager
Code: import-module servermanager
If you need other types of roles they are readily available to you on the Internet. If you are using Server 2008 features and roles whose combination is specific to your builds or applications it will require a little more work to write out your cmdlets. A list of all available features and commands can be brought up in PowerShell by using the “Get-WindowsFeature” cmd. You can only use this command after you have imported the Server Manager tools into PowerShell. You do this by running “import-module ServerManager” cmd. You can use this list to build your script with the following syntax:
Import-Module Server Manager
Add-WindowsFeature role, role, role
Don’t forget to replace the word role in this command with the Windows Feature/Role you would like to install
**Important** there should be 1 PowerShell script for each server type you want to deploy! Make sure your execution policy in PowerShell is set to Remote Signed by using the Set-ExecutionPolicy RemoteSigned command.
Create CMD Script File
Once you have completed the PowerShell scripts, you will have to create a .cmd script that will run after Sysprep OOBE. This script runs when you use the Synchronous Command option in Sysprep, but we will get into that later. I know that we can get a lot more complex when creating scripts and possibly even just creating one PowerShell script with all options we need. Unfortunately like many other overloaded administrators and engineers who wear many different hats, I do not have the PowerShell acumen required to make such a script, nor the time to learn it. Since we all know basic scripting this seemed like the next logical choice for accomplishing what I want without having to invest days in learning to do so with more advanced features. So let’s dive in.
We will create a basic script that will provide us with choices to run each of the PowerShell scripts we created. The code for this is pretty simple and straight forward. First I will provide the code, then the output, and then a brief explanation.
title Server Type Selection Screen
echo Server Type Selection
echo 1) Exchange Single Server (MB,HUB,CA)
echo 2) Exchange Mailbox Server
echo 3) Exchange Hub and Client Access
echo 00) Exit
set /p var=Enter Numeral Option:
if %var%==1 PowerShell -ExecutionPolicy RemoteSigned -file “c:\deploy\Exchange_CA_HUB_MB.ps1″
if %var%==2 PowerShell -ExecutionPolicy RemoteSigned -file “c:\deploy\Exchange_MB.ps1″
if %var%==3 PowerShell -ExecutionPolicy RemoteSigned -file “c:\deploy\Exchange_CA_HUB.ps1″
if %var%==4 \\vbscript missing
if %var%==5 PowerShell -ExecutionPolicy RemoteSigned -file “c:\deploy\Web.ps1″
if %var%==6 PowerShell -ExecutionPolicy RemoteSigned -file “c:\deploy\Set-Lync2010Features.ps1
if %var%==00 Exit
The very first line of code turns off the line showing you where you are in the directory as shown below.
As you might deduct every line with echo in front is displayed as readable text in the command window. The next line Set /p allows for user input, the /p for promptstring waits until a value is entered then it stores the value for execution. The next line defines the variables and the commands to run if said variable is selected. Fairly straight forward, though it is easy to make mistakes, check you work by running the script and trying to select an option, you can cancel once you see the tell-tale power shell 000000’s at the top of the command window
Create the Answer File
If you are not familiar with creating an answer file I will provide an in depth tutorial in the future. For now I will give you a down and dirty outline of the steps required.
First thing is first you have to download and install the Windows Automated Installation Kit (AIK). After installation, navigate to your start menu and open the Windows System Image Manager. This will allow you to create your answer file but before you do that you will need to specify the “image” to use. You can do this by going to the file menu and selecting “Select Windows Image”. You will have to navigate to the Sources folder on the root of your Windows Installation disk and select the appropriate “image” for your installation.
There are a plethora of options for one to select when creating the answer file but for our purposes we only need two. One is the option to specify the default Administrator Password and the other is the option to run the script on first logon. Both options can be found in the amd64_Microsoft-Windows-Shell-Setup container.
You will want to drag both of these selections to the oobeSystem container in the answer file and fill in all required information, as shown below. Once complete save this file and copy it to your Master Image in the Sysprep folder under System32.
**Caution** the administrator password is stored in plain text in the Answer File and it remains in the Sysprep folder. You can use another SynchronousCommand with an “Order” of 2 to run a batch file that deletes the answer file, or you can delete it manually.
Create Master Image
This should be pretty straight forward and shouldn’t require much explanation. Simply create a VM and install a fresh image of Windows Server 2008 R2, make sure you install all virtual hardware, drivers and software that will be shared amongst all images. Install no Features or Roles, and copy all scripts onto a folder on the root of C: and name it Deploy.
**Important** Make sure your execution policy in PowerShell is set to Remote Signed by using the Set-ExecutionPolicy RemoteSigned command.
In my experience I have found the best way to do this is via command line simply open a new command window, navigate to the Sysprep folder and run the following:
sysprep.exe /oobe /generalize /shutdown /unattend:Sysprep.xml
Create Template and Test
Once the VM has shut down after running the Sysprep command, you will want to copy it to a template which you will use to deploy all servers in the future. This process varies depending on your hypervisor and we will not be discussing this process further as this tutorial is hypervisor agnostic.
Once you have created your template deploy a new VM from template and test. Verify all your scripts are installing the required services. Once you are happy with the result simply bring your new template into production and you are done.
The Tony – @TonyInTheCloud