Our Windows 7 Reference Image was originally built in 2011. At the time, we had some consultants in helping us migrate from Windows XP to Windows 7. At the time, the consultant who was building the image edited the Local Group Polices on the Windows 7 machine prior to capturing it. Since then, we’ve continued to service the WIM and use it as our production image. Some years later, we were trying to change our Windows Update settings and found these nice Local Group Policies just sitting there screwing everything up!

You can check if you have any Local Group Policies enabled by opening gpedit.msc as an Admin then expanding to the All Settings tab. Sort by State Descending and you should see if you have any Local Group Policies. Note: Other products may add local group policies, so review what you find before just assuming the settings should be removed.. You can also use GPRESULT -H to get an HTML report of ALL Group Policies being applied. Click Show All then search for Local Group Policy to find any settings that are applied from the local policies.

Fast forward to this week. We are in the process of rolling out Windows 10 and we hope to do a large portion of our clients as In-Place Upgrades. As I was comparing a completed In-Place Upgrade to a Bare Metal build, I noticed that the machines behaved differently when accessing Windows Update (Yep, again). I had wondered previously if local GPO’s would be carried forward during an In-Place Upgrade and the answer is ‘Yes’ - My ‘Just Upgraded’ machine had over 20 local machine policies listed, compared to a bare metal build, which only had 3.

One option to handle this would be to create new domain GPOs that counteract the local GPOs and let the domain GPOs win, but that just seemed like it would suck to maintain and potentially not work for some of the policies where Not Configured isn’t the same is Enabled or Disabled. After a bit of Googling, I found some options, most of which were manual steps. The ‘IF Nothing Else Works’ option was to just delete the GPO folders from the machine, so of course that’s the option I chose.

First I built a Windows 7 machine using our production build. Then I performed an In-Place Upgrade on it to Windows 10 1709. During the upgrade, just after the OS is upgraded then reboots, I delete any group policy files that exist. The imaging process completes and the Local Group Policies are mostly empty.

Disclaimer: I know there are more elegant ways to do this PowerShell but after several failed attempts to use the -Include and/or -Filter options, I finally just went to quick and dirty route. Forgive me. If you run this in Windows 7 as part of your Pre-Deployment steps (DON’T DO IT!!), you will wipe our ALL group polices and will need to GPUPDATE /Force before they return. You’ve been warned!

1

%SYSTEMROOT%\System32\Windows\PowerShell\v1.0 powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Command "Remove-Item -Path $env:windir\System32\GroupPolicy -Confirm:$False -Recurse -force; Remove-Item -Path $env:windir\System32\GroupPolicy\Users -Confirm:$false -Recurse -force"

Here’s a breakdown of the command line.

Run Powershell.exe without loading a profile in a hidden window and bypass PowerShell execution policies then run the command that follows in quotes. For more use powershell.exe /? to get commandline options.

1

%SYSTEMROOT%\System32\Windows\PowerShell\v1.0 powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Command

Delete the folders GroupPolicy and GroupPolicyUsers folders from C:WindowsSystem32.

1
2

Remove-Item -Path $env:windir\System32\GroupPolicy -Confirm:$False -Recurse -force; 
Remove-Item -Path $env:windir\System32\GroupPolicy\Users -Confirm:$false -Recurse -force

Just add a Run Command Line step to your OSD Task Sequence following the first reboot Post In-Place Upgrade and you should be good to go. I added it there so that it was cleared before attempting any other steps in the Task Sequence, but it can really go anywhere after the new OS is applied.