I noticed something similar with Windows Update group policy.  No matter how 
many times I tried to gpupdate, and went looking at the right WU keys in the 
registry, the Update section of Settings would not change to show the checkbox 
to “Look for updates on Microsoft Update”, you know the one I mean.  It wasn’t 
until hours later and no doubt many GP refreshes that it finally changed.  I 
got distracted with other work and never went back to this to investigate 
further.  This was soon after RTM.  It kind of reminded me of how SCCM staggers 
Software Updates, you know the policy is there, Software Center shows you the 
updates on a computer right next the one you’re on, and no matter how many 
times you refresh policy and start updates evaluation it still takes it a 
couple hours to pop Software Center up.



This is troubling especially since use of Windows 10 here is under the most 
scrutiny of any OS release by any vendor to date.  If I can’t apply policy to 
satisfy the security office and have it apply before users log in, we may not 
be deploying Windows 10 at all.  If this isn’t intended then at least until 
it’s fixed.



Todd



________________________________
From: [email protected] <[email protected]> on behalf 
of Marable, Mike <[email protected]>
Sent: Wednesday, September 9, 2015 6:42 AM
To: [email protected]
Subject: [mssms] Problems applying GPOs with Windows 10?


Has anyone else had problems with GPO processing on Windows 10?



I’m currently working on the Windows 10 replacement for one of our Windows 7 
products and consistently I’m seeing GPOs not applying in a timely fashion (in 
particular the AppLocker policies).  Once the machine is built I have to reboot 
it a second time to get all the policies in place.  The Windows 7 equivalent 
never had this problem.



Here is what I’m dealing with.  I have a single task sequence that will build 
using either Windows 10 or Windows 7 depending on a task sequence variable.  So 
the builds run through the same exact steps.  They are placed in OUs with 
identical GPOs applied.  I originally was setting the SMSTSPostAction variable 
to do a “shutdown –r –t 0” to reboot the machine at the end of the build.



On a Windows 7 build the machine comes up with all GPOs processed.  It has the 
proper wallpaper and all the restrictions are in place.



On a Windows 10 build the machine comes up and it has the wrong wallpaper and 
none of the restrictions are in place.  I have to reboot it a second time and 
only then does it come up properly.



Trying to resolve this I’ve set up a clunky hack at the end of my task 
sequence.  SMSTSPostAction calls a batch file.  This batch file calls a 
PowerShell script.  The PoSh script sleeps for 30 seconds to allow the batch 
file to exit, return control back to the TS and so the TS can close out.  The 
PoSh script then continues with resetting the Provisioning keys in the 
Registry, sleeping another 30 seconds, does a GPUpdate, sleeps, does another 
GPUpdate, sleeps and then restarts the computer.



With this in place the system comes up with most of the GPOs in place (i.e. the 
wallpaper is proper) but what concerns me is that the AppLocker policies that 
should have hidden “Search”, “Contact Support” and “Windows Feedback” did not 
apply.  They are all still present on the Start Menu.  Now “Contact Support” 
and “Windows Feedback” report that they are blocked by the administrator, so 
although not perfect at least they are blocked.  But the Search feature is 
still fully functional which allows the user (the general public in this 
scenario) to search and find things like PowerShell.  Once I reboot the machine 
a second time the AppLocker policy fully kicks in and Search is disabled.



Once this second reboot has happened all new users who log in receive the full 
GPO settings so AppLocker prevents the Universal apps from appearing on the 
Start Menu, Search is disabled, etc. but only after the second reboot.



I don’t want to further hack this and I’m hoping I’m just too deep in the woods 
and am missing something simple, but my next step will be to script in an 
immediate second reboot.



Again, I have none of these troubles building a Windows 7 machine.  Windows 7 
is 100% ready immediately post build.



Mike Marable

Microsoft Systems Engineer Lead

Enterprise Device Engineering and Management

MCPS, MCITP, MCTS, MCSA, MCSE, MS  
[Profile<http://www.mycertprofile.com/Profile/5319166625>] 
[Blog<http://thesystemsmonkey.wordpress.com/>]

----------------------------------------------------

"The difficult we do at once. The impossible takes a little longer."

-US Army Corps of Engineers



"It is better to have less thunder in the mouth and more lightning in the hand."

-Apache Proverb



I will rise when I have fallen.



"Unless you try to do something beyond what you have already mastered, you will 
never grow."

-Ralph Waldo Emerson



**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be 
used for urgent or sensitive issues




Reply via email to