Automating Windows Deployment in a Cisco UCS Manager Environment

Contents

Introduction

Outline

Workstation Configuration

Assessment and Deployment Kit (ADK)

Directory Configuration

C:\WinPE

E:\Share

NewSPdirectory.ps1

Copy Files

Local User Account

NewShareUser.ps1

Cisco UCS PowerTool / [Java]

Microsoft Operating System Virtual Hard Disks

Windows Server (Hyper-V Server)

NewWindowsServerVHD.ps1

Nano Server

Remote Management

Consistent Device Naming

Tailor WinPE

Basics

Inject Cisco Device Drivers

Intel Chipset Drivers

Windows PowerShell

Cisco UCS PowerTool

Custom WinPE Scripts

Startnet.cmd

WinPE_Automation.ps1

Dismount WinPE Media

Create Bootable WinPE Media

Sample Automation Scripts

Automation.ps1

Get-ServiceProfile

Populate Parameters

Partition-Disk

Mount-Vdisk

Create-Unattend

Setup-Complete

ServerSetup.ps1 (Windows Server)

NanoSetup.ps1 (Nano Server)

Variables.xml

ForcePxeBoot

Summary

Author

Introduction

If you are regularly deploying Windows operating systems, the combination of Cisco UCS tools and Microsofttoolswork together to speed up the deployment of Windows Server operating systems. The purpose of this document is to provide step-by-step guidance to configure an environment that enables automating the deployment of Windows Server. This includes the various operating system installation options, such has Hyper-V Server, Standard or Datacenter, Core or Full, plus it shows how to use the procedure for a new installation option available in Windows Server 2016 called Nano Server.

The primary components used for this automation process are Cisco UCS Manager, Cisco UCS PowerTool, Microsoft PowerShell, and Microsoft WinPE.

Cisco UCS Manager – (UCSM) is designed to streamline many of the most time-consuming daily activities, including configuration, provisioning, monitoring, and problem resolution. Through a comprehensive and open XML API, UCSM enables programmatically managing hardware configurations.
Cisco UCS PowerTool – is Cisco’s PowerShell module that enables full programmatic access to the UCSM environment by providing a Microsoft PowerShell module that accesses the UCS API.
Microsoft PowerShell – is Microsoft’s task automation and configuration management framework, consisting of a command-line shell and associated scripting language built on the.NET Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.
Microsoft WinPE – Windows Preinstallation Environment (WinPE) is a lightweight version of Windows used for the deployment of PCs, workstations, and servers, or troubleshooting an operating system while it is offline.

The core of this solution is WinPE. WinPE is a stripped down version of Windows that can be booted via PXE, USB, DVD, or UCS Manager virtual media, providing a way to quickly get a working operating system onto the system being targeted for deployment.

Out of the box, WinPE contains basic elements. To make it really useful, it generally has to be modified. For example, it comes with a minimum number of device drivers. Therefore, it is often necessary to add additional device drivers that you know will be needed to deploy your system. For Cisco, that means the enic driver at a minimum, but can also include other specific hardware drivers. It also comes with basic scripting abilities. For purposes of this document, it will be tailored to provide the flexibility of PowerShell.

This document will describe the procedure to create virtual hard disk (VHD) images of Windows Server and Nano Server and a bootable WinPE image that can used for deploying those VHDsto Cisco UCS hardware. This procedure will create a virtual hard disk that can be used for natively booting the physical system. This actually provides more flexibility in deployment because a VHD can be easily mounted to another Microsoft operating system and files added or removed, making the options for deployment nearly limitless.

There are four major sections in this document.

Workstation configuration – what tools, directories, etc. need to be configured to run the sample automation shown in this document
Microsoft operating system virtual hard disks – automating the creation of the virtual hard disks that will eventually be used to boot the Cisco UCS server
Tailor WinPE – how to tailor WinPE to automate the deployment of the VHDs
Sample automation scripts – scripts developed to automate the deployment and configuration of the VHDs

Note: Though these scripts have been extensively tested, they are provided “AS IS” with no warranties, confer no rights, and are not supported by the author or Cisco Systems. They should be evaluated and tested for each individual environment to ensure they meet the standards in place.

Outline

Workstation configuration
Download and install the latest Assessment and Deployment Kit (ADK)
Directory configuration
Local user account
Cisco UCS PowerTool / [Java]
Microsoft operating system virtual hard disks
Windows Server (Hyper-V Server)
Nano Server
TailorWinPE
Basics
Inject Cisco drivers
Install Windows PowerShell
Install Cisco UCS PowerTool
Custom Scripts
Create bootable WinPE media
Sample Automation Scripts

This document assumes deployment into a Cisco UCS managed environment. The scripts automatically determine the name of the computer on which the scripts are running by making use of the capabilities of Cisco UCS Manager. If these scripts are to be used in an environment that is not managed by UCS Manager, for example a CIMC managed environment, a different method will have to be used to determine the computer name. Once that method is implemented and the scripts changed to reflect the alternate method, these scripts should work (though they have not been tested in a CIMC environment).

Workstation Configuration

A workstation for preparing the WinPE environment will need to be configured. This can be a Windows 8.1, Windows 10, Windows Server 2012 R2, or Windows Server 2016 system. It is recommended to use the latest version available of the operating system to ensure that you are using the latest tools. This process assumes Windows 10 (Windows Server 2016), but slight modification will make it possible to use Windows 8.1 (Windows Server 2012 R2).

You will also be using this workstation for creating the VHD files that will eventually be deployed to the physical servers. The target VHD file will be copied to a local physical disk on the server being deployed and then be used to native boot from VHD instead of booting from an installation performed to the local physical disk.

Assessment and Deployment Kit (ADK)

The copy of WinPE to be used in this process is available as part of Microsoft’s Assessment and Deployment Kit. It is best to always use the latest kit. Newer kits work with earlier versions of the operating system. The latest kit available at the time of this writing is for Windows 10 Version 1511. Download the Windows ADK for Windows 10 (

When you launch the installation program from the above link, you will be presented with two options – one to install the ADK and the second to copy down all the files needed for offline installation. Choose which option you want.

The ADK contains more capabilities than we need. When you run the installation, you will be presented with a window that looks something like this:

By default, several options will be pre-selected. All that is needed for this process are the Deployment Tools and Windows Preinstallation Environment (Windows PE). Unselect all options but those two and click Install.

Directory Configuration

The workstation in this example is used for several purposes:

Creating WinPE media
Creating the VHD files for deployment
File share for automation files

A specific directory structure is assumed throughout this document. There is a great deal of flexibility in how you may want to create your directory structure. Just be aware that the samples shown in this document assume the structure as defined in the following descriptions.

C:\WinPE

This directory and three subdirectories are created by the ADK. These directories hold the content of the files used to create the targeted WinPE media. You specify the exact location and name of this directory when you start the WinPE creation process and it creates the directory structure.

C:\WinPE\fwfiles – there are two files contained in this directory. They are used when you create bootable WinPE media, depending on the type of media created. The proper file is automatically selected so you do not need to be concerned about these files.

C:\WinPE\media – this directory contains all the files needed for creating the WinPE media. For the most part, the only file you are likely to reference is the C:\WinPE\sources\boot.wim. This is the file you are going to mount and tailor to your needs.

C:\WinPE\mount – this directory is used to mount the boot.wim file so you can access the contents of the WIM file.

E:\Share

You create this directory and the subdirectories on the workstation. It files that will be used in the tailoring of both the WinPE media and the VHD target, as well as the automation scripts and configuration files. Again, this directory structure is the structure used for this document. It can be on any volume, and it needs to be shared for network access with specific ACLs.

Note: Some of the sample scripts presented in this document have this value hard-coded. If you use a different root directory, you will need to make changes to the hard-coded values in the sample scripts.

The following subdirectories of the \Share need to be in place. The first subdirectory is \Automation. It contains six common subdirectories and then a series of subdirectories used to contain information specific to individual servers that are being deployed.

E:\Share\Automation\Base – This is an optional subdirectory that can be used during the creation of the Nano Server image.

E:\Share\Automation\Drivers – This subdirectory contains all the device drivers that need to be added to any image being created. At a minimum, you should include the UCS VIC enic driver. Go to Cisco.com and download the appropriate driver ISO files. Mount the ISO file. Copy thedriver files for each driver that you want to add to the image into this directory. You may want to create a separate subdirectory for each unique driver, just to keep things straight. For example, here is a sample directory for the Cisco UCS C240 M4 servers used for this document.

E:\Share\Automation\Mount – This subdirectory is used as a mount point for the install.wim file when tailoring it into a virtual hard disk. Nothing is permanently stored here.

E:\Share\Automation\Nano – This subdirectory is used to contain the automation scripts for building a Nano Server image. The scripts are copied to this subdirectory from the Windows Server distribution media.

E:\Share\Automation\Scripts – This subdirectory contains scripts that are common across any deployment process used to automate the deployment of a specific server. These scripts will be executed by WinPE, but it is easier to manage these scripts on the workstation than it is to manage them on the WinPE image. Scripts that are used to tailor a specific image will be contained within a different subdirectory.

E:\Share\Automation\VHDs – This subdirectory will contain the created VHD from the Windows Server or Nano Server wim file. Each VHD will be a base image that can be tailored later in the process by including other script files. For example, you might want to have four images for Windows Server 2016 – Standard Core, Standard with Desktop, Datacenter Core, and Datacenter with Desktop. Due to the way Nano Server images are created, you might want to have images for Compute with Cluster, Compute Standalone, File Services with Cluster, File Services Standalone, and any other combinations that are appropriate to your environment. This document will show you how to create an individual image, but it will not show the creation of all those listed above.

The following PowerShell commands will create the above directory structure.

New-Item-Path‘E:\Share\Automation’ -ItemTypeDirectory

New-Item-Path‘E:\Share\Automation\Base’ -ItemTypeDirectory

New-Item-Path‘E:\Share\Automation\Drivers’ -ItemTypeDirectory

New-Item-Path‘E:\Share\Automation\Mount’ -ItemTypeDirectory

New-Item-Path‘E:\Share\Automation\Nano’ -ItemTypeDirectory

New-Item-Path‘E:\Share\Automation\Scripts’-ItemTypeDirectory

New-Item-Path‘E:\Share\Automation\VHDs’ -ItemTypeDirectory

E:\Share\Automation\<SPname> – There will be multiple subdirectories of this format. You will need one for each Service Profile being deployed. <SPname> must match the name of the Service Profile, as the Service Profile is used to determine which configuration is being deployed. This allows a single file server to contain the automation files for multiple deployments, and the deployments can be occurring simultaneously.

E:\Share\Automation\<SPname>\Executables – Any executables that you want to get onto the VHD file so they can be executed by the Windows StartupComplete.cmd script or other automation scripts you may include. For example, you might want to install an agent or utility on every system you deploy. You would place the .exe or .msi file into this directory and its contents would get copied to the VHD. Then at the appropriate time after the system’s initial boot, the StartupComplete.cmd script can be modified to run these installations.

E:\Share\Automation\<SPname>\Scripts – This subdirectory contains scripts particular to tailoring the system. It must contains a Variables.xml file that define things like IP addressing, passwords, domain join information, etc. A sample is shown later in this document. If anything besides the basics covered in the common automation file is required, those files would also be present. For example, you might need a SetupComplete.cmd file which is executed upon completion of the installation. That script may call another script, ServerSetup.ps1, to perform other functions such as domain join or role installation.

E:\Share\Automation\<SPname>\Logs – This subdirectory is used to store log files created during the automation steps. The access to this subdirectory differs from the rest of the subdirectories. The rest of the subdirectories are configured for Read/Execute access for the local account used to access the root share. Because log files will be written during the automation process, the ACL on this subdirectory is changed to add Write and Modify access for the local account.

NewSPdirectory.ps1

The following script will take a Service Profile name as input and create the proper subdirectory structure. It requires that the $shareRoot and $shareUser variables be modified to reflect the customer environment. Before running this script, the $shareUser variable must be defined as a local user on the workstation (NewShareUser.ps1 script is shown in the next section).

Note: Remember when entering the Service Profile name that is it case sensitive within UCS Manager.

Param

(

[Parameter(Mandatory =$true, Position =0)] # Service Profile name

[String]$spName

)

$shareRoot ="E:\Share\Automation" # Local share root

$shareUser =$env:ComputerName+'\'+'BuilderUser' # Local user account to add to share ACL

$spPath =Join-Path$shareRoot$spName

$spExecutables=Join-Path$spPath"Executables"

$spScripts =Join-Path$spPath"Scripts"

$spLogs =Join-Path$spPath"Logs"

If (Test-Path$spPath)

{

Write-Host"Directory $spPath already exists. Exiting"-ForegroundColorRed

Exit

}

$null=New-Item-Path$spPath -ItemTypeContainer

$null=New-Item-Path$spExecutables-ItemTypeContainer

$null=New-Item-Path$spScripts -ItemTypeContainer

$null=New-Item-Path$spLogs -ItemTypeContainer

# Get ACL on log directory. Build Modify permission for share user. Add to ACL.

$acl =Get-Acl$spLogs

$colRights =[System.Security.AccessControl.FileSystemRights]"Read,Modify,ExecuteFile,ListDirectory"

$permission=$shareUser,$colRights,"ContainerInherit,ObjectInherit”,”None”,”Allow”

$accessRule=New-ObjectSystem.Security.AccessControl.FileSystemAccessRule$permission

$acl.AddAccessRule($accessRule)

$acl|Set-Acl$spLogs

Write-Host"Directories created:"

Write-Host" $spPath"

Write-Host" $spExecutables"

Write-Host" $spScripts"

Write-Host" $spLogs`n"

Write-Host"$shareUser granted Modify access to $spLogs`n`n"-ForegroundColorYellow

Copy Files

Once the above directory structure is created, you must copy in any custom script files (Variables.xml, ServerSetup.ps1) and executables appropriate for the platform you are targeting. Additional scripts and executables you may reference within ServerSetup.ps1 also must be copied into the appropriate directories.

Local User Account

The above share needs to be accessed by the WinPE automation scripts. The simplest way to provide access to the share is to create a local user account on the workstation that has read access to the share. It only needs read access because the complete process copies the VHD file from the share to WinPE which writes it out to the local disk. So all modification of the VHD file occurs on the targeted server. Once you have successfully created your WinPE media, you can reuse the VHD file to many different servers simply by modifying a couple variables in the scripts.

The Logs subdirectory mentioned above needs to allow Write/Modify access to the local user account as log files will be written to that subdirectory.

In this sample, the user account created is BuilderUser with a password of P@55w0rd.

It is also possible to configure the share with Anonymous access, but that opens a larger security surface to exploit, so I opted for this method.

The following script asks for a user name and password and uses the entries to create a local account on the machine running the script. The account is set to have a non-expiring password that cannot be changed by the user.