I encountered this error when I attempted to re-build my lab environment.

What is interesting though, is that I ran the Installer.ps1 script like I had done so in the past, with no new modifications to the Variable.xml file. But this time, I encountered an error that I never received before: “Failed Installing Server Feature Group 1”. So, now we need to figure out why.

The first thing that I did was, of course, just try to re-run the script. But the same results occurred. So we first need to identify what exactly is in “Server Feature Group 1”.

If you take a look in the Workflow.xml file, you will see on line 44 the following code:

Notice that the only item in this “group” is the .NET Framework 3.5 server feature.

If you’ll recall, all of the Virtual Machines created by the PowerShell Deployment Toolkit (PDT), use Windows Server 2012 R2 (with the exception of the System Center Service Manager portal). Additionally, we know that when attempting to install the .NET Framework 3.5 server feature on Windows Server 2012 and above, you have to provide a path to the SXS folder (originally found on the installation DVD/ISO).

But if you look at my C:\Installer\ directory, I have a folder and the contents for Windows Server 2012 R2. So why is there an issue?

Let’s take a look at the Installer.ps2 script file for the message “Failed installing server feature group” and see what we find.

As you can see, on line 3288 we have the output: New-LogEntry -Deployment $Deployment -LogFolder $LogFolder -LogFile $LogFile -Server $Server -Message “Failed installing server feature group $Group” -Status $true

If you look a little above that specific line, you will notice other variables including: $ServerFeaturesResult, $ServerFeaturesInstall, and $ServerFeaturesSource.

There is also the following line: Copy-Source -SourceName “server features” -Source “$SourcePath\$ServerFeaturesSource”

Seeing the “$SourcePath” variable, immediately makes me think about the variable in the Variable.xml file.

As I understand it, after the Virtual Machines are created via the VMCreator.ps1 script, it copies the Installer.ps1 script to the Domain Controller (or first Virtual Machine), and then runs it.

To start from scratch, I re-ran the Downloader.ps1 script, to download a fresh copy of the source files. As the script shows, you need to manually download some of the files, specifically the Windows Server, System Center, and SQL Server source files.

For reference, this is the directory structure that the Downloader.ps1 script produces.

C:\Temp\

Prerequisites

SharePoint2010Module

SharePoint2010SP2Foundation

SQLServer2008R2

SQLServer2012.en

SystemCenter2012R2

IntegrationPacks

ManagementPacks

SystemCenter2012SP1

IntegrationPacks

ManagementPacks

WindowsAzurePack2013

WindowsAzurePack2013ServiceBus

WindowsAzurePack2013WebSites

WindowsAzureServices2012

And this is the expected directory structure. Please note that the extra directories (and thus source files) that you need to supply, are in bold.

C:\Temp\

Prerequisites

SharePoint2010Module

SharePoint2010SP2Foundation

SQLServer2008R2

SQLServer2012.en

SQLServer2014.en

SystemCenter2012R2

AppController

ConfigurationManager

DataProtectionManager

IntegrationPacks

ManagementPacks

OperationsManager.en

Orchestrator

ServiceManager

VirtualMachineManager

SystemCenter2012SP1

AppController

ConfigurationManager

DataProtectionManager

IntegrationPacks

ManagementPacks

OperationsManager.en

Orchestrator

ServiceManager

VirtualMachineManager

WindowsAzurePack2013

WindowsAzurePack2013ServiceBus

WindowsAzurePack2013WebSites

WindowsAzureServices2012

WindowsServer2012

WindowsServer2012R2

So after creating all the other required directories and extracting the source files, I copied the entire C:\Installer directory back onto my HOST machine. Then I re-ran the VMCreator.ps1 script with no extra parameters.

The Virtual Machines were created properly, including the Domain Controller, and all the VMs were joined to the domain. Then the Installer.ps1 script was automatically copied to the DC01 VM an initiated.

This time, most of the scripted installations completed successfully. However, as you can see from the screenshot, the VMM prereq of “Windows Deployment Tools 8.1” failed to install.

I believe this is in reference to the Windows Deployment Toolkit, which is a part of the Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1.

Since the rest of the deployment went without issue this time around, we should have some log files that we can examine. On the Domain Controller (DC01), which is where the Installer.ps1 is initially running from, we can look in C:\Users\Administrator\AppData\Local\Installer and we will see log files for each VM.

If we take a look at the VMM log file, we see that the prerequisite installation started, and apparently completed. However, it is reporting that the installation failed.

If we now look at the log file that is on the actual VMM server, located at C:\Windows\Temp\adk\Windows Assessment and Deployment Kit for Windows 8.1_20150518114006.log, we get a little more information.

The first error we see is: “Failed calling HttpSendRequest(). Win32 Error Code: 12007.” This is expected, since the VM does not have Internet connectivity.

The next few errors mention that it’s trying to find and verify a file called: “Kits Configuration Installer-x86_en-us.msi.” But if we look in the ADK directory, that file doesn’t exist.

So my next thought was: the Downloader.ps1 script is the one that downloaded and extracted the files required. Maybe it missed downloading a file?

I then compared a manually initiated download of the offline ADK files, with what the C:\Installer directory contained; and here’s what I found.

This time, everything that failed last time completed successfully, with the exception of the Operations Manager integration with Data Protection Manager.

So I ran the Installer.ps1 for a forth time! But, I still receive an error with the DPM integration with SCOM. Investigating this error, I noticed that the DPM Management Packs were not imported into SCOM.

Additional time/effort will need to be invested to figure out a solution, but as an alternative, you could manually import the Management Packs, and install the Data Protection Manager Central Console on the Operations Manager server.

Conclusion: It is unfortunate that the PDT doesn’t always deploy successfully every time, especially when I didn’t change anything from that last time that I ran it (in which it was successful). Also, since this tool was designed for internal Microsoft sales team, you would think that it would be made a little easier to work with/troubleshoot. But who knows, maybe the next version of the PDT (based on PowerShell Desired State Configuration) will do this and more; we’ll just have to wait and see.