Fixed: Non-Functional Start Menu After Sysprep of Server 2016 - Including AWS

Fixed: Non-Functional Start Menu After Sysprep of Server 2016 - Including AWS

At Infor we are increasingly using Server Core due to it’s superior scaling time. However, when I do need to build a server with the GUI - having a non-functional start menu defeats the point. Windows 10 and Server 2016 suffer from a specific sysprep bug which causes the start menu to not pop when the start button is clicked. Here’s how to fix it - including a code snippet for automating the AWS build.

Server 2012 R2 As Well

In my work, this problem seems to have spread to Server 2012 R2 with recent patches.

The Problem

It appears that Windows 10 and Server 2016 both suffer from a specific sysprep bug that is well known, but somehow keeps creeping back into Windows - so it seems Microsoft may be having a difficult time keeping this bug out:

This technet thread shows that the problem was first noticed on Windows 10 and crept back in during the Creators Update:

This technet thread shows that, like myself, others found that it also affects Server 2016:

The Quick Fix (Server OS Oriented)

If you comb through the above articles you will find that disabling “CopyProfile” in unattend.xml fixes this problem. On desktop OSes it may not be a realistic option to disable this due to the requirements of customizing individual user logons. However, for Server OSes user customization is rarely needed. So I elected to take the easy way out and just disable it in unattend.xml

AWS Special Considerations

If you automate Windows AMIs in AWS you know that there are special scripts and a special unattend.xml provided and used by AWS when they prepare machines. In addition, in Server 2016 AWS started using a new approach to preparing Windows. Instead of using the legacy ec2config service, it uses ec2launch - which is implemented as a handy PowerShell module with many system preparation functions.

This being the case, I want to edit rather than replace the unattend.xml so that I will keep using the one provided by AWS - this way if they enhance or bug fix it, I get the benefits of those updates without having to discover the hard way that my static copy of unattended.xml no longer matches the one provided by AWS.

The following lines of code will update the AWS provided unattend.xml on a Server 2016 GUI or Core machine that is made from an AWS AMI.

$unattendxml = "C:\ProgramData\Amazon\EC2-Windows\Launch\sysprep\unattend.xml"
(gc $unattendxml).replace('<CopyProfile>true</CopyProfile>','<CopyProfile>false</CopyProfile>') | Out-file $unattendxml

This Concept In Production

I am using this code in Infor’s automated Windows AMI build process.