PowerShell Deployment Toolkit (PDT) Troubleshooting: Installer.ps1 Fails With “Failed Installing Server Feature Group 1"

  • Article

https://msdnshared.blob.core.windows.net/media/2016/08/0841.NinjaAwardTinySilver.pngSilver Award Winner

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.

http://i2.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/Domain-Controller-Installer-Script-Failures.png?resize=700%2C570

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:

<Group Name=”1″>

<Source>$WindowsServer2012R2Source\sources\sxs</Source>

<ServerFeature Name=”.NET Framework 3.51″>

<Install>NET-Framework-Core</Install>

<Validation>220</Validation>

</ServerFeature>

</Group>

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

http://i2.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/Workflow-XML-Group-1.png?resize=695%2C184

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?

http://i2.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/Installer-Directory-Contents.png?resize=416%2C393

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

http://i1.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/Installer-PS1-Source-Of-Error-Message-Output.png?resize=700%2C201

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.

http://i0.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/Variable-XML-Installer-Variables.png?resize=700%2C170

I recall that I encountered a similar type issue with the Installer.ps1 script originally when I started using the PowerShell Deployment Toolkit (PDT); which I blogged about here: http://micloud.azurewebsites.net/my-experience-with-the-powershell-deployment-toolkit-pdt-part-3-installer-ps1/

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.

http://i1.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/PDT-Downloader-Script.png?resize=700%2C513

The originally posted article about the PDT Downloader script hasn’t been updated, and it can be confusing about the directory structure required. Thankfully I discovered this article by Reidar Johansen that helped clarify the folder structure.

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.

http://i2.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/PDT-Installer-Second-Attempt.png?resize=700%2C713

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.

http://i0.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/Installer-Log-Files.png?resize=700%2C736If 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.

http://i1.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/VMM01-Log-File.png?resize=700%2C538

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.

http://i1.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/ADK-Log-File.png?resize=700%2C538

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.

The manually initiated offline download contained 154 files at 2.78 GB. The PDT Downloader.ps1 script downloaded content only contained 111 files at 1.71 GB! So, a slight difference I’d say! So I copied the missing files onto my Domain Controller (where the Installer.ps1 script was initiated from), and re-ran the Installer.ps1 script.

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

http://i2.wp.com/micloud.azurewebsites.net/wp-content/uploads/2015/05/PDT-Installer-Third-Attempt.png?resize=700%2C781

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.