Deploying System Center 2012 SP1 Using the PowerShell Deployment Toolkit

Introduction

Microsoft has released a set of PowerShell scripts that allows automating the deployment of System Center 2012 SP1. The PowerShell Deployment Toolkit (PDT) was originally developed to help quickly rebuild a System Center environment that Microsoft technical sales force can use to demonstrate private cloud management to customers. This article provides an overview of the PDT, the function of each of the components, and some critical steps needed to properly leverage the toolkit.

The PowerShell Deployment Toolkit is a set of PowerShell scripts that was designed to deploy the System Center 2012 SP1 suite of components. It not only installs System Center components, it also performs post-installation configuration to integrate into a private cloud scenario deployment. While it was originally designed for that specific scenario, it was also developed with the concept of allowing flexibility in the deployment process. This translates into allowing different selections of System Center components to install and customization of their deployment in various ways.

Overview

The PowerShell Deployment Toolkit is a free download from the Microsoft website

The PDT download consist of a ZIP file that includes three PowerShell scripts and two XML input files, as shown in Table 1.

Table 1. PowerShell Deployment Toolkit Files

PowerShell Development Toolkit Prerequisites

Before you can leverage the PDT scripts, you need to prepare the environment and install prerequisite software. The PDT is designed to be executed from an installation workstation that is running Windows Server 2012 or Windows 8. The installation targets can be either virtual or physical machines, and they have to already be deployed and running. In addition, the PDT requires an Active Directory forest for installation of the System Center components.

In order to deploy the System Center components in virtual machines on a single host, it is recommended to use a Windows Server 2012 server running Hyper-V. This host should be configured with a minimum of a dual core processor, 32 GB of RAM, and sufficient storage for the virtual machine files and additional data.

Further, the PDT requires VHDX files with supported operating systems that have been sysprepped to deploy System Center component in virtual machines. System Center 2012 SP1 components can be installed on Windows Server 2012 or Windows Server 2008 R2 SP1, with the exception of VMM 2012 SP1 which requires Windows Server 2012. In order to make this task easier, you can use a PowerShell script called ConvertWindowsImage.ps1 that is a free download from the Microsoft Website.

It is highly recommended that you use this PowerShell script to create the virtual machines because the PDT has a requirement that the VHDX can only have a single partition. If you attempt to install from Windows Server media to create the VHDX, it will automatically create a required partition to support Bit Locker and the PDT will not work properly. Using the ConvertWindowsImage.ps1 script, you can create the Windows Server 2012 and Windows Server 2008 R2 VHDX images that are sysprepped and have only a single partition. It is recommended that you also patch the images before you start the System Center component installation with the PDT.

Understanding the Downloader.ps1 Script

The Downloader.ps1 script does what you might gather directly from its name, which is to download all the files required by the Installer.ps1 script. Be aware that you will need a fast connection to the Internet because the download will consist of all the System Center 2012 SP1 source files (evaluation versions) and all the installation prerequisites. These files amount to about 13 GB of data. It is also recommended to run the Downloader.ps1 script on the workstation that will be used to perform the installation and not the host where the VMs reside.

The Downloader.ps1 script verifies the files that are downloaded. If a component has already been downloaded, then it will not download it again. This allows you to interrupt the download process and start it again at a later time. However, the script will not resume the download of a large file, so if you stop the download, it restarts the interrupted file download from scratch.

By default, Downloader.ps1 leverages the C:\TEMP directory for file storage. It creates a folder called C:\TEMP\DOWNLOAD and a list of subfolders for the downloaded files. Here is the list of subfolders that you should expect to see once created by the Downloader.ps1 script:

• Prerequisites
• SharePoint2010Module
• SharePoint2010SP1Foundation
• SQLServer2008R2
• SQLServer2012.en
• SystemCenter2012SP1
• WindowsServer2012

Under each subfolder you will find additional folders. For example, the SystemCenter2012SP1 folder has subfolders for each System Center component and a folder for the integration packs.

Once Downloader.ps1 has completed the download of all files, it will create a duplicate of the folder structure under C:\TEMP and then expand all of the files and perform any required actions.

By the end of the Downloader.ps1 script execution, it will have used approximately 33 GB of storage space for the downloaded files and the expanded files. Once Downloader.ps1 completes successfully, you can delete the C:\Temp\Download folder, but unless you are low on disk space it is recommended that you keep the download source directory until the installation is complete.

Understanding the VMCreator.ps1 Script

If you decide to use the VMCreator script to create the VMs for the installation, be aware of the following items:

• The OS for the Service Manager Web portal must be Windows Server 2008 R2, not Windows Server 2012
• Once you build the VM for the Web portal, you may need to execute WINRM QUICKCONFIG to ensure that the WinRM is configured secure communication
• The VMCreator script does not do either of the above steps

Understanding the Variable.xml File

Variable.xml is an input file that is used by the VMCreator.ps1 and Installer.ps1 scripts. It contains the following major sections:

• Variables – Product keys and general values that are used during installation
• Components – Definition of the System Center components, the service accounts, the groups, the service account passwords, and other component specific information needed for installation
• Roles – Role assignments for servers and the names of SQL instances for the roles
• SQL – SQL server installation locations, SQL versions, instance names, and admin groups
• VMs – Information for the VMCreator script used during VM creation and unattended installation settings

In the Variables section, you provide unique deployment information. Some key variable settings include:

• The product keys that are used to convert evaluation media to retail or volume license media
• The account and password used to install the System Center Components (this account needs local administrator rights on all the servers)
• The location where the downloaded media is stored.

In the Component section, you provide the following settings:

• Delete any component name sections for System Center Components that are not going to be installed
• For the remaining components, modify the service accounts, groups, and passwords or verify that they are as desired
• For the System Center Operations Manager (SC OpsMgr) component, verify that the management groups are correct
• For the System Center Configuration Manager (SC ConfigMgr) component, verify that the database and site information is correct

In the Roles section, you provide the following settings:

• Delete any roles that you do not want installed on the server
• Modify the server names that the roles are assigned, as needed
• Modify any SQL instance names, as needed

In the SQL section, you provide the following settings:

• Modify the server names where the SQL instances will be deployed

• Modify the SQL Admin group name

In the VMs section, you provide the following settings:

• Modify the hostname where the VMs will be created
• Modify the VM folder locations
• Modify the prefix for the VM names
• Modify the Virtual Switch that will be used
• Modify the parent VHDX name and location
• Modify any of the domain join information

Understanding the Workflow.xml File

Workflow.xml should not need to be modified unless you are looking to change the installation process or tasks.

Creating Accounts and Groups

Before you can run the Installer.ps1 script, you need to create all of the required role accounts, groups, and set passwords as specified in the Variable.xml file. Be sure to understand the group membership requirements of each role you are installing and ensure that the accounts are members of the correct groups.

Running the Installation

Once you have configured the target servers for the installation (potentially using the VMcreator.ps1 script), modified the Variable.xml file, and created all the required accounts and groups, then you can execute the Installer.ps1 script. In order to do this, you open a PowerShell command window on the installation workstation and execute the following command:

• ./Installer.ps1

When the Installer.ps1 script runs, it validates that all of the required inputs to the process already exist and are available. For example, it will validate that all the required media and prerequisites in the folder structure are present, that it can communicate with all the target servers, that WinRM communication to the target servers is working as expected, that all the specified service accounts, groups, and passwords are correct, and that it can it communicate to domain controllers.

If any validation step fails, the Installer.ps1 script will exit and provide an error message to assist in troubleshooting the issue. If all the validation steps are successful, then the installation of the components will begin. During the installation, the script will display each component that is being installed, the current step that is being performed, and if any steps fail.

At the end of the installation and configuration, a summary will be displayed and any failures will be reported.

Conclusion

In this article, you learned about the free Microsoft PowerShell Deployment Toolkit that allows you to automate the installation of System Center 2012 SP1 in a private cloud configuration. Using the PDT allows the automation of the deployment, and simplifies repeated installations granted proper editing of the configuration files to ensure that the required information is appropriately specified.