- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
The free PowerShell Deployment Toolkit (PDT) comes to the rescue. Designed to bring the installation time down from weeks to hours, it offers flexibility in picking which parts of the suite to install and even covering advanced options such as clustered System Center suite components and clustered SQL server for the backend. The 69 KB download contains five files:
- VMCreator.ps1. PDT doesn’t care if you’re installing to physical or virtual machines, nor which virtualization platform you use, as long as the servers have the right version of Windows server installed and are available on the network. If you’d like to setup new servers on Hyper-V you can use this script to create the necessary VMs automatically.
- Variable.xml is the key to customizing your setup and the only file that you have to edit. In this file you specify product keys (to install licensed versions instead of trial versions), which servers to install to, which SQL servers to use and which service accounts to use for all the different System Center components. You also specify company name, installer service account and source path. Because there’s the possibility of making a mistake as you type values in or the possibility of setting up a configuration that wouldn’t work (two incompatible System Center components on the same server for instance) the Installer.ps1 file will validate all your values before starting deployment.
This is probably the biggest timesaver in PDT, the script checks a LOT of settings and values to make sure that your System Center deployment has the biggest chance of succeeding.
- Downloader.ps1 will download all the prerequisites for every single System Center product as well as the trial installation media of every System Center 2012 product. It will download a trial of Windows Server 2008 R2 (for the SharePoint 2010 Foundation self-service site for Service Manager) and Windows Server 2012. If you’re planning to only install some of the System Center products you can limit the downloaded components with the deployonly switch which will read your variable.xml and figure out what you need. If a component is updated, you can just rerun it and it’ll pick up the newer download without having to get all the files again.
Just the chore of downloading all the System Center components AND all the prerequisites is a whole lot easier with PDT.
- Workflow.xml is the “knowledge” that’s built into PDT about how to install each System Center component, how to integrate them with each other and what dependencies exist between each part. Normally you won’t edit this file but if you’re interested in doing advanced installations you can see the variables necessary by looking through this file.
- Installer.ps1. This script is the one that’ll actually do the work, reading your settings from variable.xml and proceeding to install each System Center component you’ve specified, on each server, in the correct order. It’ll then proceed to setup the integration between each System Center component that can be automated.
The process of installation runs in parallel on several machines where possible and the script shows you exactly which component is being processed.
It’s important to realize that PDT isn’t designed to replace the great software distribution features in Configuration Manager, nor the great capabilities unlocked by service templates in VMM but rather its designed to solve the chicken and egg problem: get System Center in place first so you can then take advantage of all these great features. It’s also great for setting up a lab environment or a Proof of Concept implementation.
The downloader will take its time, depending on the speed of your internet connection, it’ll also use winrar (make sure this is installed on your machine before running it) to unpack each installer, as well as slipstream relevant service packs into SQL server. On my system the 15 GB or so download was unpacked to just over 32 GB of files into the default folder of c:\temp.
PDT uses Task Scheduler to create a job on each remote system which is then triggered to run, neatly working around the issues associated with PSExec, remote PowerShell and other remote system execution tools. PDT can be run from a Hyper-V host, on which you have the VMs running, note that the VMCreator script doesn’t create highly available VMs in a cluster. You could also run the installer from a workstation that’ll you’re planning to use as a management station. Make sure however that you don’t run it from a VM (or physical machine) that’s actually part of the deployment as a reboot will cause the installation to fail.
For troubleshooting (and let’s face it, in a complex setup such as this everything won’t always go smoothly) PDT gathers the installation logs from each component on each server and stores them as a subfolder in your \temp folder.
Some System Center installation logfiles are actually deleted in a normal installation, PDT helps out here as well by copying all logfiles to the installation server during the setup.
The bottleneck for a System Center installation is I/O, the faster your disk setup is, the faster the installation. If you’re going to run all the System Center VMs on a single host I recommend 32 GB of memory, 16 GB isn’t enough for all the VMs. Note that PDT isn’t foolproof and some customization might be needed, you can follow some people’s experiences here and here.
Overall the process of getting System Center installed as well as the components integrated is much improved with PDT and for anyone looking to get acquainted with System Center, needing to setup a lab or a study environment it’s invaluable. Of course PDT can also be used to setup System Center for production environments in a controlled fashion.