The PDT (PowerShell Deployment Toolkit) is an amazing piece of technology put together by Rob Willis and is available on the TechNet gallery here:
http://gallery.technet.microsoft.com/PowerShell-Deployment-f20bb605
Basically, this toolkit enables the end user to deploy the entire SC stack along with the Windows Azure Pack (WAP) with minimal work. This is the perfect way to get started in any lab scenario. Three weeks ago, I flattened my lab and then used the PDT to stand my lab back up in its entirety within 4 hours. This included SCOM, SCSM, SCCM, SCORch, WAP and SCVMM. Not only does it install these products, but it does many of the integrations automatically for you as well. For example, the connectors for SCOM, SCCM and SCOrch were automatically configured in SCSM during the install. Very impressive.
In order to use the PDT, all you need to do is configure the Variable.xml file contained within the kit. You really shouldn’t change anything else. All you do is configure the Variable.xml file to contain the roles, features and SQL configs you need/want for your lab, run the downloader script, run the vmcreator to provision all of your VMs and then run the installer to do the rest. The downloader script is an incredible time saver. It downloads almost all of the files and stages them for you including ALL of the pre-reqs. The only pieces you have to drop in place are the bits for the SC and Windows Server installs.
The pure magic part of the PDT is the Workflow.xml file. This is the file that contains all of the install logic, the allowed combinations of roles, the integrations, etc. I recommend opening it up and checking it out…but don’t change anything. You don’t need to, which is another part that makes this file pure magic.
For a video demonstration of the PDT, check out the following TechEd 2014 session presented by the creator:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B361#fbid=
The gotchya I ran into when trying to deploy just a tear down SCOM environment was the placement and combination of the various roles. Here was what I was aiming for:
SQLOM01 – Contains two SQL instances – OMDB and OMDWDB
TSTOM01 – Management Server and Web Console
TSTOM02 – Management Server and Report Server
Pretty straight forward. However, this combination does not work because the PDT tries to pass TSTOM01 as the Management Server parameter to the Report Server install so the Report Server install fails. The only way to get this to work in a three server scenario was to do the following:
SQLOM01 – Contains two SQL instances – OMDB and OMDWDB
TSTOM01 – Management Server, Web Console, and Report Server
TSTOM02 – Management Server
All of the “extra” roles had to be stacked on the primary MS server. This may change in a future release, but as of 2.64.2608 this was the case. Attached below is the Variable.xml file I used for testing. If you wish to use, you will have to modify the top section to pertain to your lab, point the differencing disk to your parent disk for Windows Server 2012 R2 and replace the <#password#> tags with the appropriate accounts for your lab.
Happy PDTing!