GET-IT: TEAMS DAY | 1-Day Free Virtual Conference all about Teams. Here on - 8/12/20 GET-IT: TEAMS DAY - 8/12/20

Powershell Deployment Toolkit: Introducing Variables.XML

Following our previous post on how to use PowerShell Deployment Toolkit to deploy System Center, your PDT share is now in place and we can begin to leverage this great tool to help is quickly deploy our environments by simply editing the variables.XML file.

PowerShell Deployment Toolkit and Variables.XML

As we introduced in the previous post, this file is responsible to instructing the PDT system about the tasks we would like to have executed for us, which will include both the ability of deploying the necessary VMs for the environment, along with the actually installation of the components.

The format of the variables.XML file is quite easy to navigate. It is dissected into five primary sections.

  • Installer
  • Components
  • Roles
  • SQL
  • VMs

This simple configuration approach is one of the key befits of using the PDT system. In normal use, you may create a number of different variables.XML files, each potentially describing different environments, or you may create different combinations of resources to be deployed in a specific environment, enabling fast deployments for specific validation scenarios. As the XML file is easily edited, you are quite likely to create an initial file to use as a starting template, and create a copy for each scenario you will deploy.


To help us understand this structure a little better, we will define a variables.XML that will deploy a single VM along with both a SQL 2012 instance and a copy SCVMM 2012 R2.

We will begin with the initial section of the XML, which is the “Installer” area. In this section of the file, we define most of the settings which is common to all the components we will deploy, including settings such as Product Keys, Error Reporting, CEIP, and Microsoft Update, and User Details. In addition, this area helps to direct PDT to locate where the Installation media is hosted, and what account should be utilized by PDT to install the necessary components.

The settings defined in this section are specific to your environment, but they tend to be static once you have them defined.


With the global settings defined, our next section is to define the settings, which are specific to the component that PDT is to deploy. Each component will offer a different range of customization options that can be quickly learned by searching for the Component Name section in the Workflow.XML file, which matches the component you are working on. In many cases, the default options will work well. However, you are likely to want to customize at least the service accounts and administrative accounts or groups that you will use.

PowerShell Deployment Toolkit has the ability to also create the matching Accounts and Groups if you request that PDT create a Domain Controller dedicated to your testing environment as part of its creation process. If you are going to use an existing domain, or not leverage the PDT ability to create a dedicated domain, then you are responsible to ensure that all service accounts and groups you define in this section are already available in the target environment. PDT will check this requirement is met as a validation test prior to the actual installation.


The heart of the configuration settings in variables.XML is the roles which we wish to deploy. The options available for deployment are expanded with each new release of the PDT component (the workflow.xml file); In the example I am listing all the roles currently available for SCVMM in the current workflow.XML file (version 2508).

From the list of roles available we can quickly see that we have the ability to deploy both in standalone or clustered format. If you choose to deploy as a clustered format, the installer will validate that you have defined only a single Active Server, while permitting you to still define multiple passive servers.

To successfully deploy the role, you will need to define a management server (standalone or clustered), and a database server that will be used to host the SCVMM database. Many of the roles offered are either mandatory, or optional, or required to be defined as group dependency. To determine the correct mix of roles, you can refer to the workflow.XML file or simply run the installer and it will run a validation on your options to ensure that you have these defined.

In the sample, the roles chosen will use the same server for the Management Service, the database, and the console. In addition, I have added an additional role to deploy the SQL Management tools to help in the event we may need to run some queries directly on the database.


Most components in System Center have a dependent on SQL. As you will observe from the role installation of VMM, we will be defining a database server, including both a SQL server name and instance as part of the role definition. The data provided for the role must match up with a SQL configuration, so that PDT can correctly validate the course of action it must take to prepare prior to installing the role.

As with the roles section, our options are quite flexible, including the ability to instruct PDT to use a previously established SQL instance or create a new instance. If the option is defined to create a new instance, this can be easily defined to be cohosted with other instances or deployed to dedicated servers. This even supports the ability to define static TCP ports for SQL, which is important for Configuration Manager. In addition, PDT has the ability to deploy standalone or clustered instances.

Virtual Machines

The final section of the configuration defines the virtual machines (VMs) to which the components, roles and databases will be deployed. As with the other sections of the configuration, we have the ability to deploy multiple virtual machines to support our environment. PDT is supplied to two main PowerShell scripts that we leverage for preparing the environment – these are VMCreator.ps1 and Installer.ps1.

The VMCreator script is optional, and has the ability to create all the virtual machines necessary for our environment. We can even create a new Domain Controller if we define it in the variables.xml. The configuration of these VMs are defined in detail in this section, including the normal VM settings (for example, CPU, disk, memory, network, etc.), but we also have the ability to have these nodes automatically join to the hosting domain, as well as inject the required source files to complete the installation of the roles defined for these servers.

VMCreator.ps1 will also run validation tests prior to creating the VMs, but once these have been successfully created and deployed, it will launch the Installer.ps1 process to install the defined roles.

Although the VMCreator.ps1 script is an optional step, in the variables.XML file, we are still required to define each of the VMs to which the installer will be targeting to deploy its roles. In this scenario, the installer will validate that the named servers are online and can be accessed by the service account we defined in the Installation secretion. Only after a successful validation will the installer then proceed to deploy the defined roles.

In the sample, I am requesting just a single Virtual Machine which is defined using the parameter <VMName>; The value provided in this parameter must match the server name provided in the Server= field in the Role.

As we mentioned already, VMCreator.ps1 also can create a Domain Controller for your environment. If you wish to leverage this function, PDT will assume that the first VM listed will be the domain controller. You will need to enable the section <Domain> to define the domain to create, and the organizational units (similar to the following sample).


With your sample variables.XML complete, running the VMConfigure.ps1 script, will begin the process of generating and deploying your new SCVMM lab, as illustrated in the screen shot below, providing verbose feedback as the PDT executes its tasks.

Powershell Deployment Toolkit: Variables.XML

Creating a PDT environment, along with a number of custom variable.XML files will enable you to quickly change your testing/demo/lab environments to use many of the cool functions and features enabled with WS/SC. I will provide you with some additional samples to cover Service Manager and Orchestrator, and of course the Windows Azure Pack.

For now, have fun getting PDT to create an SCVMM server, and let me know about the configurations you create.

Related Topics:

  • System Center

    Don't have a login but want to join the conversation? Sign up for a Petri Account