A WordPress.com site dedicated to System Center and Cloud Management

Posts tagged ‘PowerShell Deployment Toolkit’

My Experience With The PowerShell Deployment Toolkit (PDT) – Part 4 (PDT GUI for PowerShell Deployment Toolkit)


Recently, via Twitter, I was alerted to something new and exciting with the PowerShell Deployment Toolkit (PDT). 

Previous, I have written a series on My Experience With The PowerShell Deployment Toolkit (PDT). which continues to get hits/views every day! 

I was very excited to see a Tweet about a new PowerShell Deployment Toolkit (PDT) GUI! So, instead of using the command line process for using the toolkit, if you are more comfortable in a GUI, you now have that option!

Here is the description:

“The PDT GUI is a Graphical User Interface for the Powershell Deployment Toolkit. The original PDT is created and maintained by Rob Willis from Microsoft Corporation. The PDT GUI is created and maintained by German Microsoft Partner ‘Elanity Network Partner GmbH’ and is not an official Microsoft Product. The PDT GUI helps to create fast PDT Configuration-Files (Variable.xml) for Zero Touch System Center Deployments. PDT GUI creates and validates the configuration files for PDT, it does not alter the existing PDT in any way.”

For further information on the PDT GUI for Powershell Deployment Toolkit, see the following: http://gallery.technet.microsoft.com/PDT-GUI-for-Powershell-6908b819#content.

So, here’s a quick extension article to the ‘My Experience With The PowerShell Deployment Toolkit (PDT) series.

NOTE: At the time of originally writing this post, the current PDT GUI version available was v1.0. However, approximately a week ago the tool was updated, so some of my original article was no longer accurate. Therefore, to ensure that I provide something of value to the community through my posts, I have taken the time to update this post (even though I didn’t publish my original article to the public yet) accordingly.

So, with that being said, I will walk through my experience using this GUI for the toolkit. This is very useful for re-building your lab when you need to.

 

Start by downloading the PDT GUI. If you do a Google search for the “PDT GUI”, you will end up at the following (http://gallery.technet.microsoft.com/PDT-GUI-for-Powershell-6908b819#content).

PDT GUI 1.1 Download

Download the ZIP file and extract it, which will contain the following folders and files:

  • System Center 2012R2
  • System Center and WAP Complete
  • Windows Azure Pack
  • PDT-GUI.Export.ps1
  • ValidationInfo.xml

ZIP File Contents

Right-click on the file, and choose Run With PowerShell.

Run With PowerShell

 

In case you have not yet downloaded the PowerShell Deployment Toolkit (PDT) itself, or you have it in a different directory, you also may encounter the following message.

No PDT Workflow Message

Press OK, and you will be presented with the following License Terms of Use screen. Click “I Agree“.

EULA Prompt

The PowerShell window will then show the following, as it downloads the PowerShell Deployment Toolkit (PDT).

PowerShell Window - Download PDT

If you look back in the PDT GUI folder, you will now see the additional files:

  • Downloader.ps1
  • Installer.ps1
  • Variable.xml
  • VariableAD.xml
  • VMCreator.ps1
  • Workflow.xml

Downloaded PDT Files

Once the process finished downloading the PDT files, it will automatically re-launch the GUI script.

When the PDT GUI loads for the first time, you should see the following screen. Either click the “Select File” tab, or the Next button.

PDT GUI - About

On the Select File tab, you can either select an existing Variable.xml file to use, or point to your own customized version. If you are selecting an existing file, you have to click the Open button to load the file, and the click either the “General” tab, or the Next button.

PDT GUI - Select File

On the General tab, you can provide the Product Keys for System Center, and SQL Server, provide information about the installation Service Account, directory paths for the installation files, etc. As stated on this screen, the variables/fields that are required are in bold; namely: “Installer Service Account”, “Installer Service Account Password”, “Source Path”, “Registered User”, and “Registered Organization”.

When you have filled out all of the variables/fields you want/need, either click the “VMs” tab, or press the Next button.

PDT GUI - General

On the VMs tab, you will notice 3 sub-tabs; “Domain“, “Default VM Settings“, and “VMs“.

Starting with the Domain tab, you can select the checkbox “Create a new AD Forest“. If you select this, you will then be able to provide the Name, Service Account OU, and the Group OU. Don’t forget to click Save Changes once you complete these fields, then click on the “Default VM Settings” sub-tab.

NOTE: If you click the “Next” button, this will bring you to the “SQL” tab, and not the “Default VM Settings” sub-tab.

PDT GUI - VMs - Domain

On the Default VM Settings tab, you will see a list tree with all of the default settings you can configure for each VM. Note the message at the top of the screen which says “Specify the Default Settings for all VMs generated, switch to VMs tab to set individual settings per VM.”

The fields of importance in this screen are as follows:

  • Host: This is the your physical server that is hosting/running all of the VMs
  • VM Folder & VHD Folder: This is the directory that will hold all the VM related files. By default this is set to C:\VMs, so if you have a dedicated drive to host your VMs (instead of hosting them on the same volume that is running the Host OS), make the change here.
  • Network Adapter > Virtual Switch: Ensure that you already have a Virtual Switch created for you environment, and change the value here to match. By default it is set to “CorpNet01”.
  • Network Adapter > IP > Prefix: If your virtual network will be using something different other than 192.168.1.x then change the value here
  • Network Adapter > IP > Gateway: Similarly to the IP Prefix, if you Gateway is not 192.168.1.254, then change it here. Note that even if you change the IP Prefix (and save that change); for example to 192.168.2.x, the corresponding Gateway and DNS IP values do not update to reflect this (i.e. they remain at their default 192.168.1.1 and 192.168.1.4 respectively, instead of changing dynamically to 192.168.4.x).
  • Network Adapter > IP > DNS: Identically to the note above about the Gateway, change the value for your DNS as required.
  • OS Disk > Parent: If you used the Convert-WindowsImage.ps1 script (as described in this post: https://adinermie.wordpress.com/2014/01/26/my-experience-with-the-powershell-deployment-toolkit-pdt-part-2-vmcreator-ps1/), then you will need to change this value to point to the location of your .VHDX file.
  • Join Domain > Domain: You will need to provide your Domain Name in this field. Note, even if you selected the option (on the Domain tab) to create a new AD Forest, and supplied a Name for this, this value is not dynamically updated into this field.
  • Join Domain > Credentials > Domain: You will need to enter the Domain Name again in this field, as similarly stated, the field is not dynamically populated with changes you’ve made previously.
  • Join Domain > Credentials > Username & Password: Provide the Service Account credentials that will be used to join all the VMs to the domain. Note that the password is in plain text.
  • Administrator Password: Provide the password for the default Administrator password. Note that the password is in plain text.

After you have  completed all the fields you would like to modify, don’t forget to click Save Setting after each modified field. Then click on VMs sub-tab.

NOTE: If you click the Next button, this will bring you to the “SQL” tab, and not the “VMs” sub-tab.

PDT GUI - VMs - Default VM Settings

On the VMs tab, you can modify the VM-specific settings to be different than the defaults provided. The settings that you are able to modify will vary depending on the role of the VM.

For example, if I select any of the Database VMs (labelled DB##), I can change the Memory settings, and the Data Disks.

NOTE: The DB02 lists the modifiable Settings in reverse order compared to all the other Database VMs (i.e. DataDisks then Memory, instead of Memory then DataDisks).

If I select the VMM VM (VMM01), I can change the Memory, but if I select the Orchestrator VM (OR01) I can only change the VM Name. Similarly, for the SCCM VM (CM01) I can additionally change the Data Disks. For the Service Manager portal VM (SM03), I can change OS Disk > Parent property (as it requires Windows Server 2008 R2 and not Windows Server 2012), and the Network Adapter > Identifier property. Finally, the DPM VM (DPM01), there are 2 sets of Data Disks, both sets containing 4 disks at 100 MB each (by default).

So there are a lot of settings/customizations that can be made. Make the changes required, remembering to click Save Settings after each modification, and then either click on the “SQL” tab, of click the Next button.

PDT GUI - VMs - VMs

On the SQL tab, we have all the settings for each of the SQL Datatbase VMs. This screen shows all of the SQL installations that will occur, along with the Instance information. You will notice that all installations of SQL Server will be using the SQL Server 2012 version, and will all use the same Instance name of “MSSQLSERVER“.

If you select one of the servers from the Instances list, the Instance Variables area will update to reflect that Instance’s settings. Of interest, because I changed the Domain Name, not on the VMs > Domain tab (though I changed it there as well), but on VMs > Default VM Settings > Join Domain > Domain (I changed it to Test.com), the dropdown list containing the server name (above the Save Changes button) now shows the proper FQDN for the VM Name (i.e. DB01.Test.com, instead of the default DB01.Contoso.com). If I select it from the dropdown list and then click Save Changes, the Instance list will be updated and show this change immediately.

Unfortunately, even though the Instance information is updated in the list, this does not change the Instance Variables fields to reflect the newly referenced Domain Name. Note: I will contact the developers and provide this feedback as a suggestion for improvement.

For now, once you have modified all the SQL Instance information required, click on the Roles tab, or click the Next button.

PDT GUI - SQL

On the Roles tab, there are 3 areas that are displayed: “Components“, “Role“, and “Components and Roles that will be installed“.

The Components section lists all of the Components available to be installed. This includes all the System Center 2012 SP1 components (including the Service Provider Foundation), all the System Center 2012 R2 components (including the Service Provider Foundation, Service Management Automation, and Service Reporting), along with a few others like the Windows Azure Pack, Windows Azure Services, and both required versions of SQL Server (namely 2008 R2, and 2012).

When you select a Component, the Roles area will populate with the various role within that component.

For example, selecting the System Center 2012 R2 Virtual Machine Manager component, you will see the 8 roles associated with that product, including the ability to make an Active-Passive cluster of the Management Server!

Also of interest, if you select a Role that has “Database” in its name, the Server list is filtered to only show/display the VMs that will have SQL installed (which corresponds to the Instances list on the SQL tab).

After selecting a Component, and a corresponding Role (of which you can only select one at a time), you will need to specify which Server to install it onto. If you have made a change to the Domain Name (presumably from the VMs > Default VM Settings > Join Domain > Domain property), the Server list correctly shows/reflects the Domain Name changes made.

When you click the Add Selected Role, the tool will validate what other system/product is already going to be installed on that specific server, and produce an error message if Role combinations are invalid.

PDT GUI - Roles

Role Combinations Are Invalid

Further, once you have added a Component/Role combination, or if you just select one of the existing ones, you will be able to modify the application specific settings. Review the settings (which again, don’t automatically update to reflect the Domain Name changes), and don’t forget to click Save Values, then either click on the Finish tab, or click Next.

Component_Role Settings

On the Finish tab, there are 3 sections: Downloader, VMCreator, and Installer. These correspond to the PowerShell Deployment Toolkit (PDT) scripts. If you are interested, see the beginning of this series for a walk through on the XML files and each of the scripts.

You are going to run each in succession. The Start Downloader option will download all of the source files required. The Run VMCreator option will, of course, create all the VMs required for deployment. And the Run Installer will perform the installation. It is recommended to run the Validation Process first, so that the source files, and VMs are validated to ensure there is no issues. You wouldn’t want to end up with a partial deployment.

PDT GUI - Finish

This is definitely a useful tool, especially for setting up a custom lab quickly (as in my experience it completes within a few hours), or even in an actual Production deployment, as deploying System Center utilizing the PowerShell Deployment Toolkit (PDT) is fully support by Microsoft, since it is just utilizing the scripting abilities of the individual products.

 

As always, if this post helped you in any way, and you would like to show your appreciation, please rate it and comment on it. Also, feel free to contact me with requests for future articles.

Advertisements

My Experience With The PowerShell Deployment Toolkit (PDT) – Part 3 (Installer.ps1)


In our last post, we used the PDT’s VMCreator.ps1 script to create all the VMs that are required to setup all System Center components.

Now, we are going to use the Installer.ps1 script to finish the installation.

Installer.PS1 SCRIPT

Start by running PowerShell command prompt as Administrator. Right-click on PowerShell and choose ‘Run As Administrator’.

Administrative PowerShell Prompt

In the PowerShell command prompt, change the working directory to where the Installer.ps1 script is located (in my example, in the Downloads folder); for example: cd “C:\Users\Adin\Downloads”.

Before running the script to execute the installation, it is best to run the validation option first, to ensure everything is in place. To do this, run the Installer.ps1 script with the “-ValidateOnly” parameter, like this: PS C:\Users\Administrator\Downloads\PDT2.5.2509> .\Installer.ps1 -ValidateOnly. This will initiate the validation, which checks things like the VMs, dependencies, SQL Server installations, and media for installation.

As you can see in my lab example, the Media validation has failed.

PDTInstallerScript-MediaValidationFailed

You will notice that the Installer.ps1 script is looking for the media in the C:\Temp directory. But wait, didn’t we download all of the required files by running the Donwloader.ps1 script? Yes we did. Then why is this validation failing?

Simply, the Downloader.ps1 script downloaded all the required files, but rather than placing them into the C:\Temp directory, it put them in C:\Installer\Prerequisites. If you look at the Variable.xml file, specifically lines #7 and 8, you will see the following:

<Variable Name=”SourcePath” Value=”$SystemDrive\Temp” />
<Variable Name=”Download” Value=”C:\Installer” />

These lines tell the scripts where path to the source files are, and where (originally) to download those files.

So at this point, we have 2 choices. Either we can move all of the files into C:\Temp, or we can change the “SourcePath” directory to match where the files are downloaded to (namely C:\Installer\Prerequisites).

In my case, I’ll just move the files. But if you want, you could modify the SourcePath variable.

Re-run the Installer.ps1 script with the “-ValidateOnly” parameter. The validation for the Media should pass now. However, as you can see in my lab example, I am now getting validation failures on the Service Accounts.

PDTInstallerScript-ServiceAccountValidationFailed

So, how do we fix this? Well, first, I should mention that I am running the PowerShell scripts on my HOST machine; which is NOT a part of the domain. This is why the validation of the Service Accounts fails.

So you have 2 choices, either join your HOST to the domain, or copy the Installer.ps1 script and C:\Installer directory to the Domain Controller. Since I like to re-build my lab over and over, I don’t prefer to add my HOST to the domain. So, in my lab example I opted to copy the files to my Domain Controller VM, and re-run the Installer.ps1 script with the “-ValidateOnly” parameter.

Now, when I did this, I am STILL getting validation errors, but this time with the Server and Access validation.

PDTInstallerScript-ServersAndAccessValidationFailed

Why is this? Honestly, I don’t know. But I do recall reading/hearing somewhere about possibly having to run these scripts from an Administrator’s workstation, and NOT from any of the systems that the scripts are designed to work with. Since I was originally running the scripts on my HOST system that was NOT connected to the domain, that was one issue. Then I ran the scripts from the Domain Controller, which resolved the Account validation.

So, I thought that I would try one last thing. I decided to create an Administrator workstation and run the scripts from there. Now, of course I ran the Installer.ps1 script with the “-ValidateOnly” parameter just to see if everything passed prior to actually running the script to perform the installation. And guess what! Everything passed!

So, now that we know everything is green and we won’t end up with a partial/incomplete installation, we are now ready to run the Installer.ps1 script, and complete the final part of our installation.

Run the Installer.ps1 script, and the validation will be completed again (as designed), then the installation will be initiated.

PDTInstallerScript-InstallationStarted

Just like the VMMCreator.ps1 script, the display will turn green when each item is completed. Eventually, it will complete all pieces.

PDTInstallerScript-InstallationCompleted

Congratulations, you have now successfully used the PowerShell Deployment Toolkit (PDT) to automatically install and configure an entire System Center environment!

One final note. You may not have noticed, but all of the System Center consoles were actually installed onto server RD01. Why is that? It’s not the Administrator’s workstation. The answer is because that server is the System Center Orchestrator Runbook Designer server, which requires all of the consoles for the interoperability/connectivity to create runbooks, and thus System Center automation.

SystemCenterConsoles

So, if you are looking for the console for a specific System Center component (i.e. SCOM, SCCM, etc.), you will need to log into the RD01 server and launch it from there. Alternatively, since we had to setup an Administrator workstation, you could install each console on the workstation as well.

I hope this post series on the PowerShell Deployment Toolkit has been helpful. Happy lab-ing.

My Experience With The PowerShell Deployment Toolkit (PDT) – Part 2 (VMCreator.ps1)


In our last post, we used the PDT’s Downloader.ps1 script to download all the files, pre-requisites, etc. that are required to setup all System Center components.

Now, we are going to use the VMCreator.ps1 script to create all the VMs we need.

For more information about the VMCreator.ps1, see the following: http://blogs.technet.com/b/privatecloud/archive/2013/02/18/deployment-the-pdt-vm-creator.aspx

IMPORTANT: This script only support creating of VM’s on Microsoft Windows Server Hyper-V.

Variable.xml File

The PDT2.5.2509 directory contains 2 important files, called Variable.xml, and VariableAD.xml. This is the file that tells the script what to label the VMs, etc.

NOTE: The file “Variable.xml” will create all VMs created for System Center, but requires the existing of Active Directory first. The file “VariableAD.xml” will create all the VMs including a Domain Controller with Active Directory. This is the best option to use if you want to re-build your lab environment completely automated. This is the file that I will be using.

Let’s first take a look at this file, so that I can point out the area(s) you may want to customize.

Start by editing the VariableAD.xml file.

VariableADXML

There are a few things to note.

First, you should take note that the domain used is “CONTOSO”. If you want to customize your setup to have a specific domain name, you will need to Find and Replace all entries of “CONTOSO” with your domain.

In my lab example, I am going to change it to “SC.LAB”. However, there are 2 different types of entries that contain the word “CONTOSO”. One for Service Accounts, using the ‘Domain\UserName’ pattern (44 entries), and another that uses ‘Domain.com’ (46 entries) for the database server references.

VariableADXML-ChangeDomain

Therefore, to make it easier to use Find and Replace, I have found that replacing the ‘Domain.com’ references first is best. In my case I will use Find and Replace and replace the existing “Contoso.com” with “SC.LAB”. If your domain uses the “.com” ending, then you can just simply replace all entries of “CONTOSO” with your domain name.

Once you have the domain modified, save the file as “Variable.xml” replacing the existing one, or you can name it something specific like “VariableADCustom.xml”.

VMCreator.ps1 Script

Now that we have a customized Variable.xml file, we are ready to make a few minor modifications to the VMCreator script and then run it.

If you have re-named the Variable.xml to something different, you will need to edit the VMCreator script first (because by default it looks for Variable.xml). I have not attempted this yet, so re-name your XML file to be “Variable.xml”. Once I have attempted with a re-named file, I will post an update to this section.

Now, before we can run the VMCreator script, we need to create a sysprep’d VHD file for each OS required (namely Windows Server 2008 R2, and Windows Server 2012 R2). To make this easy, you can use the Convert-WindowsImage.ps1 script (found here: http://gallery.technet.microsoft.com/scriptcenter/Convert-WindowsImageps1-0fe23a8f).

Convert-WindowsImage.ps1 Script

Using this command-line tool allows you to rapidly create sysprepped VHDX and VHDX images from setup media for Windows 7/Server 2008 R2, Windows 8/8.1/Server 2012/R2.

This script actually has a GUI to make it easier to work with, which I will walk though here.

Start by running PowerShell command prompt as Administrator. Right-click on PowerShell and choose ‘Run As Administrator’.

Administrative PowerShell Prompt

In the PowerShell command prompt, change the working directory to where the Convert-WindowsImage script is located (in my example, in the Downloads folder); for example: cd “C:\Users\Adin\Downloads”.

Now call the script, and include the “-ShowUI” parameter, like this: Convert-WindowsImage.ps1 -ShowUI. This will cause the GUI to appear.

ConvertWindowsImage-UI

From this UI, choose 1). the Source (which is the ISO of your Operating System), 2). the SKU (like Standard, Enterprise, Datacenter, etc.), 3). specify the file format (I choose VHDX for 2nd Generation VMs running Windows Server 2012), Dynamic, and the size (I left mine at the default of 40 GB).

Leave the Working Directory as is, since that’s where the script is running from. Provide a name for the VHD file.

NOTE: If you do choose to provide a name, you MUST enter the file extension or else you will encounter an error as follows (i.e. W2012R2.vhdx).

INFO : Launching UI…
INFO : Opening ISO en_windows_server_2008_r2_with_sp1_vl_build_x64_dvd_617403.iso…
INFO : Looking for F:\sources\install.wim…
INFO : Scanning WIM metadata…
ERROR : There is a mismatch between the VHDPath file extension (), and the VHDFormat (.VHDX). Please ensure that these
match and try again.
INFO : Log folder is C:\Users\Adin\AppData\Local\Temp\Convert-WindowsImage\fe5ad446-cd0a-4e4d-b72b-f5916feb7d9e
INFO : Done.

ConvertWindowsImage-UI_ErrorOutput

When you are ready, click the Make My VHD button.

Windows(R) Image to Virtual Hard Disk Converter for Windows(R) 8
Copyright (C) Microsoft Corporation. All rights reserved.
Version 6.3.9600.3.amd64fre.fbl_core1_hyp_dev(mikekol).131226-2000 Release to Web

INFO : Launching UI…
INFO : Opening ISO en_windows_server_2012_r2_x64_dvd_2707946.iso…
INFO : Looking for D:\sources\install.wim…
INFO : Scanning WIM metadata…
INFO : Image 2 selected (ServerStandard)…
INFO : Creating sparse disk…
INFO : Attaching VHDX…
INFO : Disk initialized with MBR…
INFO : Disk partitioned…
INFO : Volume formatted…
INFO : Access path (F:\) has been assigned…
INFO : Applying image to VHDX. This could take a while…
INFO : Signing disk…
INFO : Image applied. Making image bootable…
INFO : Opening F:\boot\bcd for configuration…
INFO : BCD configuration complete. Moving on…
INFO : Drive is bootable. Cleaning up…
INFO : Generating name for VHDX…
INFO : Closing VHDX…
INFO : Closing Windows image…
INFO : Done.

The script will show in the PowerShell command prompt what it is doing.

ConvertWindowsImage-UI_Output

You will need to create 2 VHDs, one for Windows Server 2012 R2, and another for Windows 2008 R2. This is required because the System Center Service Manager portal runs on SharePoint 2010, which is only supported on Windows Server 2008 R2.

Variable.xml File (VHD Files)

Now that we have the sysprep’d VHD files ready, we can now use the VMCreator.ps1 script to create all the Virtual Machines (VMs) for all the System Center components automatically.

By default, the VMCreator.ps1 script uses the Variable.xml file to generate the VMs. Therefore, by default it will check for the VHD file in the following location: C:\VHD\WS12R2D.vhdx.

This means that you will have to either move/re-name your sysprep’d VHD file, or change the XML file to point to the correct location. In my example, I will change the XML file accordingly, as follows.

At line # 235 the section begins. Within there, there is a reference to which is the sysprep’d VHD file that we created (specifically the Windows Server 2012 R2 disk). Change this entry to meet the location and name of the VHD file you created with the Convert-WindowsImage.ps1 script.

<OSDisk>
<Parent>C:\VHD\WS12R2D.vhdx</Parent>
<Type>Differencing</Type>
</OSDisk>

At line # 399 the  section begins. Within there, there is a reference to which is the sysprep’d VHD file that we created (specifically the Windows Server 2008 R2 disk). Change this entry to meet the location and name of the VHD file you created with the Convert-WindowsImage.ps1 script.

<OSDisk>
<Parent>C:\VHD\WS08R2E-SP1.vhdx</Parent>
<Type>Differencing</Type>
</OSDisk>

Variable.xml File (Virtual Switch)

Before you run the script, you also need to ensure that the Hyper-V Virtual Switch is already created.

In the Variable.xml file, at line # 222 the section begins. Change this entry to match whatever Virtual Switch you have created in Hyper-V, or create a Virtual Switch labelled the same “CorpNet01”.

<VirtualSwitch>CorpNet01</VirtualSwitch>

In my lab example, I created an Internal Virtual Switch, and labelled it “Internal Lab Virtual Switch”.

 

Variable.xml File (VHD Location)

One more minor note. In the Variable.xml file, at line # 208 and 209, there is a and reference. On your Hyper-V host, if you have a different drive that you want your VM files to be stored on, you need to change this reference. In my lab example, I have a dedicated SSD drive labelled as Y:\ for my VMs.

<VMFolder>C:\VMs</VMFolder>
<VHDFolder>C:\VMs</VHDFolder>

Now we are finally ready to run the VMCreator.ps1 script and watch it create all the VM’s for us!

VMCreator.ps1 Script (Continued)

Start by running PowerShell command prompt as Administrator. Right-click on PowerShell and choose ‘Run As Administrator’.

Administrative PowerShell Prompt

In the PowerShell command prompt, change the working directory to where the VMCreator.ps1 script is located (in my example, in the Downloads folder); for example: cd “C:\Users\Adin\Downloads”.

Now run the script: VMCreator.ps1. The command line will show you its progress. First it will validate everything, and then start creating the VMs. You will notice that it first creates the Active Directory Domain Controller, and waits for that to be up and running (with Domain Services installed), and then create the other VMs. This is because all other VMs are joined to the domain.

VMCreator-AD

VMCreator-AllVMs

Once all the Virtual Machines are up and running the script will appear to be completed, as follows.

VMCreator-VMsCompleted

However, if you connect to the Domain Controller, you will see that another script is running to install all the components for each System Center product.

VMCreator-DC-ComponentInstall

Eventually, you will notice that some lines will turn yellow. This is because some elements are dependant on others, so it needs to wait for those to complete. For example, SQL Server needs to be installed before Management Servers, Management Servers need to be up and running before Consoles are installed, etc.

PDT Installations Pending

When an element is complete, the line will turn green.

PDT Installations Completed

This entire process will take some time, and is dependant on your hardware. In Microsoft’s MMS demo, it took them just less than an hour. With my lab hardware (described here), it took approx. 1 and a half hours.

In the last post in this series, we will go onto using the next script, Installer.ps1.

Tag Cloud

%d bloggers like this: