Why a Potato you may ask? well, I guess that all the french speakers understood it, but PDT is the abbreviation in french for “Pomme de terre”, which actually means Potato. I was searching for a sexy image of a potato, and well, that one was the sexiest 😉
One of the things I do most in my daily work, is trying things out. If it works it is great. If not, I adapt/correct it until it works.
This said, beeing able to test things is not that straight forward, because we need to have a test machine.
More then that, for system center engineers like me, a test machine is often not enough; You need a complete sandbox where you can create and test things without having to be afraid of breaking anything (And sometimes actually breaking them ;)). A good thing to do is to create your self a complete lab.This is particullarly usefull for migration scenario tests for example. I would actually recommend to create a clean lab for each new project that you start. But I agree, it can be time consuming, and sometimes our test could be done in an already existing lab. But using the right tools will make this installation time defenitly shorter then with others!
Several methods exists to help you in order to create a complete LAB without minutes. Some of them are famous, other ones are more obscure, but there are all pretty good in general, and I will present you one that I particularly like: The powershell deployment toolkit or PDT.
The PowerShell deployment ToolKit is a set of PowerShell scripts that allows you to create a lab in not time. It is a great tool, which works really really well, when it is properly configured. But that configuration can become quickly someting frustrating because of the lack of detailed documentation.
The lack of documentation can turn this easy to use tool into something way more complicated then it actually is. There is no real documentation that you can refer to, in comment based help, nothing that helps to drill in the different options that are offered by the PowerShell deployment ToolKit. The only documentation that is available (that I know of at least) are the other blog posts and links that I am sharing in this post, AND in the PowerShell deployment toolkit code it self!
But no worries, I will try point out in this post firstly where to get it, and how to get all of the dependencies. Secondly I will show with an own example how to configure it. And last but not least, I will share my troubleshooting exepriences and the most common errors / issues you can find with the powershell deployment toolkit.
- Download Scripts
- Download prerequisites
- Download the (missing) prerequisites manually
- Create differenciating disks
- Configure variables.xml
- Launch VMCreator.ps1
- Launch Installer.ps1
As described above, the procedure it self is not very complicated, but there are several scripts / pieces involved which can make you confused. This post tend’s to guide you through the 4 big steps so that you can actually do the work, and not waist your time building your test environment.
1-Download the powershell deployment toolkit Scripts
Well, here we go! The download of the scripts, is actually not ONLY composed of downloading scripts.
The PDT script actually allow us to download around 90% of the things (which is already great!) but in order to be able to have absolutley everything ready, we need to follow these steps to make this work out:
Download to $Drive\PDT\
If not already present, Download and install the following components:
- Download and install the Web Platform installer (Download here)
- A zip application such as Winrar or 7Zip. I personally work with 7Zip which can be found here (Download here)
Also, be sure to have the following Iso’s some where near by:
- Windows Server 2012R2.Iso
- Windows Server 2008 R2.iso (only needed for Service manager).
If everything is installed, then we are ready for the next step!
2-Download the Prerequisites for the powershell deployment toolkit
Now that we have downloaded all the scripts, we can start the download of the prerequisites which will take a while depending on your system and infrastructure (Took me around 2 hours).
What is great about the PDT, is that it will download everything for you. But actually, it is not 100% true. But no worries, if you continue reading this blog post, you won’t miss a byte of it!
The method is based on one of the scripts that we downloaded during Step 1: Downloader.PS1
This script is branded as beeing the only thing that is needed in order to download everything, but as I mentionned already earlier, this is incorrect.
The downloader.ps1 script is based on one the variables.xml file. It contains all the information that the script needs in order to get the prerequisites from the internet.
Customization can be done by editing this variables.xml file. The variables “SourcePath” and “Download” specify the scripts are located, and where the prerequisites will be downloaded. (See below on how to configure the variables.xml)
In order to download the BITS we need to call the Downloader.ps1 script as follow:
If the configuration file is configured correctly, the files will be downloaded automatically. Since there are a lot of files involved, it will take a while. So now is the time to go get a cofee 😉
3-Download the rest of the prerequisites for the powershell deployment toolkit manually
As I mentionned above, not all the prerequisites are downloaded using the Downloader.ps1 script
The follwing things still need to be downloaded manually before we can start anything else:
- Windows Server 2012 R2 –>Download here
- Windows Server 2012 –> Download here
- System Center R2 Virtual Machine Manager –> Download here
- System Center R2 Orchestrator –> Download here
- System Center R2 Operations Manager –> Download here
- System Center R2 Service Manager –> Download here
The thing is that we could actually download everything prior to System Center R2, and that was great! Now, the site has changed, and Microsoft webmasters have added a choice of choosing to download a .ISO file or a .VHD, and we also need to ‘register’. I have the impression that the Downloader cannot identify the correct version, therefore these components have to be downloaded manually.
4-Create differenciating disks
While all of this is downloading, we can create our two parent differenciating disks.
For this purpose, we need will use the Convert-WindowsImage.ps1 that we downloaded earlier, and we will then generate a Windows 2008R2 and a Windows Server 2012 R2 differenciating Parent disk.
The method is actully pretty simple once we know how to do it (as most things in life actually when I think about it!). Simply follow these few steps.
Launch a PowerShell prompt as administrator and call the script as fallowed:
This will automaticall launch a GUI which will make thinks much easier (even for PowerShell junkies;)).
The GUI is very easy to understand, simply create two VHDX:
- one of Windows Server 2012R2
- One of Windows Server 2008R2 (only needed if you plan to use Service Manager).
5-Configure the Variables.xml
Your main source of input will be the variables.xml file. This file from the powershell deployment toolkit will allow you to specify your own values, names and configuration that will reflect your personalized environment.
As it can seem very straight forward, You will quickly notice that having configured your variables.xml without correctly is MANDATOR. (Logic no?).
There is a basic help mechanism that helps you to identify some comon errors: Bad passwords for Service Accounts, Prerequist missing, unsuported role combination. But there are a lot of time that if you have actually written something that is incorrect, The powershell deyployment toolkit will not be able t let you know what you exactly did wrong. It will fail gracefully but without giving you enough information in order to troubleshoot the issue. So, in other words, take your time in order to configure this file, because this is THE file.
Here is an example of a modified version of the powershell deployment toolkit variable.xml file. I have deliberatly shorten it to only install a new lab composed with the following 3 components:
- Active Directory
- SQL server
- Configuration Manager 2012 R2
the variables section, is what I like to call the “General variables”. It will contain your input that is specefic to your environemet that PDT needs. The most important of them are the following ones:
- InstallerServiceAccount –> Your installation account name in format “Domain\Account”
- InstallerServiceAccountPassword –> the password of the Installation account.
- SourcePath –> the location of the downloaded bits.
- Download –> where the files should be downloaded too.
The component configuration node indicates which components of the System center Suite will be installed. Add or remove line in this section to add more system center components.
The system center components are build in a way that you can add features to a specefic component by attributing a new role to it. This role is used in order to add new features, or to add a redundant role for fail over / cluster purposes.
Bascially, the role attribution is the part where you specify on which server you want to install which role.
Let’s clarify this with an example:
- Configuration Manager has several roles that can be installed on seperate servers. The default ones that are available in the powershell deployment toolkit that are the following ones:
- System Center 2012 R2 Configuration Manager Database Server
- System Center 2012 R2 Configuration Manager Site Server
- System Center 2012 R2 Configuration Manager Provider Server
- System Center 2012 R2 Configuration Manager Console
- We can chose which one to install (For example the Reporting services point is not in the list) and where we want them.
If you look at my config file above, you can see that all the roles have been installed on the CM01.District.Local except for the DataBase role which has been installed on DB01.District.Local
As everyone knows, all the system center components are build on Microsft SQL servers. Each of the components can be build on one or several SQL instances. You can specify all the information related to the SQL instance installation in this section.
The VM’s section is the section related to your virtual machines that will host your System center Lab. Two configurations can be specified; A default one, or one for specefic VM.
The section is where you will specify the default value of RAM memory, HDD, Processors etc…
Each default setting can be overwritten in the section by specifying the name
If no specefic VM’s are defined, then several virtual machines can be created automatically generated with the prefix that is specified in the node.
This section is mostly used only with the VMCreator.ps1 script.
The VMCreator.ps1 script from powershell deployment toolkit, will, as it’s name mentions it, create the plane Vm’s in your new / existing environment.
The VMCReator.ps1 script is designed to work on HyperV only, but could also work on VMWare with some modifications.
The VMCreator.ps1 from the powershell deployment toolkit (PDT) is also based on the variables.xml file.More precisley on the section of the variables.xml. The principle is pretty simple, you specficy a number of VM’s you want to generate in the < VM > section (my example below is set to 3). And it will create the number of appropriate VM’s. Each counted VM’s can have either a default section of values, or some specefic to his needs (DB’s will need more disks for Log files and Databases for example). Here under you will find my Default example that I used for my own lab.
The VMcreator is optional and can be skipped. However, the section can be very usefull if you are planning to create a LAB from scratch. Setting the < Domain> section value to False will launch the creation of the specefied domain on the very first VM that as been deployed by the VMCreator.ps1 script (DC01 by default) from the powershell deployment toolkit (PDT).
The VM section is pretty straigtforward to understand. Below you have a few more details on that part of the variables.xml
The last step that we need to do, is to actually launch the installation. If you have launched created the VM’s using the VMCreator.ps1 from the PowerShell deployment tool kit, you will certainly have seen all the different validation steps, and the installation will launch.
Eventually, the installation will finish.
In my case, in order to install A configuration Manager Server, with a AD and DB it took a bit less then 1h30mn.
Well, the screen is green, but I had to retry the operation quite often in order to fix all the little details until the PowerShell deployment toolkit was able to complete it’s task.
That is one of the strenghts of the PDT, you can simply relaunch the script until you got no error messages anymore. You can then work in a Try / correct manner.
Hopefully, this post help you to get more straight forward approch of using the PowerShell deployment toolkit.
Setting everything up to is actually the very easy part, and as every system engineer might know, you very often face unexpected errors. Here are the ones I have been facing. (Please share your errors/fixes in the comment section below)
A-Waiting for active Directory or “C:\:\Windows\NTDS” error during Active Directory promotion
In the variables.xml if you select “Existing=false”
The PDT scripts will create a domain for you with the given information. If you are using the VMCreator version 2.65.5 of the VMCreator.ps1 there is actually a bug in it, where your first domain controller will be able to promote it self.
There is a typo in the VMCreator.ps1 where the NTDS database is created on C:\:\NTDS instead of C:\NTDS. To correct this, you have to correct the typo directly in the VMCreator.ps1
Basically, the error takes place line 1768 and adds an extra colomn in the NTDS parameter. We simply need to remove that extra colum by doing a search and replace of the following line:
Search and replace:Search:–> Sort-Object Number).Number).DriveLetter + “:\Windows\NTDS” to
–> Sort-Object Number).Number).DriveLetter + “Windows\NTDS”
Thanks for the help and feedback from Tim 🙂
B-$MachineName is not created in this deployment
If you have the error “$MachineName is not created in this deployment” (Where $MachineName is one of the machines of your lab), that means that have an error in your variable.xml
To fix this verify that the machine names that server names in your section are identical to the ones in your section.
C-SQL Server version not specified
If you face the error “SQL Server version not specified” you have again, a miss match of your VM names in your variables.xml
To fix this, verify the server property of the node in the variables.xml and double check that the server name is identical with the one in the VMs section
6-Some other ressources
Presentation at the TechEd 2014 by Rob Willis (with apparition of Benedict Berger introducing the PDT GUI).
Step by step made by Raidar Johansen:
Blog post of aidan finn:
An interesting series of posts on system center central:
Blog post on Rack space:
A very complete blog post on 4 sysops: