Active2 years, 3 months ago
My problem is that Group Policy is not applied when a client is freshly booted. Directly after boot, the client posts an error message in the event log with source 'GroupPolicy (Microsoft-Windows-GroupPolicy)' and Event ID 1058: 'The processing of Group Policy failed. [..]'. In the Details tab, the ErrorCode is 50, which stands for ERROR_NOT_SUPPORTED.It is not just a cosmetic issue: the policies really aren't applied properly: the mapped network drives aren't there, for example. After waiting a while, executing 'gpupdate' works and the policies are applied normally: the mapped network drives appear.
- Some Group Policy preferences are not applied successfully on computers that are running Windows Vista, Windows Server 2008, Windows 7 or Windows Server 2008 R2. Update the Group Policy preferences again. To do this, type the following command at a command prompt, and then press ENTER: gpupdate /force.
- GPO not updating on Client Workstations? Also if your not already use the group policy management tool. You can use PsExec to update group policy to all client computers,this is.
My problem is that Group Policy is not applied when a client is freshly booted. Directly after boot, the client posts an error message in the event log with source.
The simplest scenario in which I was able to reproduce the problem: Newly created domain on freshly installed Windows Server 2012R2, client is a freshly installed Windows 10 64-bit machine. The domain consists of just the one domain controller and does not have any relations with other domains.
Since the error message states that Windows can't read a .GPT file from the Sysvol-share of the domain, I tried to access the same file from a Command Prompt. And indeed, when I open a Command Prompt right after boot I get this:
After waiting a minute or two, executing the same command will give a directory listing. Running gpupdate at this point will work just fine.
I did set the Group Policy setting 'Always wait for the network at computer startup and logon' to 'Enabled', and I know that this policy is applied: in the same policy object a Registry setting is specified, and when I check the Registry on the client the specified setting is there. Intervention and reflection 8th edition.
Other factors that could be relevant:
- NTLM is restricted in the domain, but this doesn't seem to matter: even after enabling it, updating policies and rebooting all machines, the symptoms remain the same.
- It doesn't matter whether the server is configured using DHCP or with a static configuration.
- The DNS server for the domain does not support Dynamic Updates. The necessary records were added manually (from C:WindowsSystem32confignetlogon.dns)
- Hibernation is disabled on the client (using
powercfg /h off
) so each boot is a full boot, not a Fast Boot - The policy Startup Policy Processing Wait Time is set to 120 seconds
- Connectivity to the DC works fine. Pings will work. Turning off the client, disabling my account in AD, turning on the client will result in the client not logging me in: it immediately notices that the account is disabled.
- Apart from this issue, I don't notice anything out of the ordinary.
This seems to be more of an SMB issue than a Group Policy issue. Sniffing the connection on the server side shows something interesting:The first time I perform the command
dir domain.example.comsysvol
, the following shows in Microsoft Message Analyzer on the DC:- Client sets up a TCP connection to port 445 of the DC, and aComNegotiation is successfully performed (DialectRevision: 0x02FF).
- Immediately after that, a Negotiate is successfully performed. TheDialectRevision is 0x0302.
- Immediately after that, the client closes the TCP connection with aTCP RST (??)
Every following time I issue the command and get the error, steps 2 and 3 occur.
When the command starts to work, steps 1 and 2 occur, but instead of the client sending a TCP RST a SessionSetup is performed, then a TreeConnect, and then a whole lot of (seemingly normal) SMB chatter occurs. Lg flash tool keygen generator.
So, it looks like somehow the client will not properly talk SMB to the DC until a minute or two after boot, and this causes Group Policy processing to fail.
Anybody know how I can debug and solve this issue?
Jurjen
JurjenJurjen
4 Answers
Group Policy Not Updating On Reboot With Joey
Starting with Windows 8, Microsoft introduced this notion of 'fast boot', where, when you shut down the OS, they hibernate OS memory footprint just like Hibernate works in normal hibernation scenarios. This results in the OS coming up faster, but it also has the side effect of disabling per-computer GP processing on startup. That is probably what you're seeing and this can be disabled by disabling the policy under Computer ConfigurationPoliciesAdministrative TemplatesSystemShutdownRequire use of fast startup
If that doesn't solve the problem then it is most likely a network stack timing issue, where GP processing for the computer is kicking off before the network stack is fully initialized. This has been around since XP and starting in Windows 7, Microsoft added a policy under Computer ConfigurationPoliciesAdministrative TemplatesSystemGroup PolicyStartup Policy Processing Wait Time where you can increase the time that GP waits before initiating. Try setting it to 60 seconds and see if that helps.
Darren
Darren Mar-EliaDarren Mar-Elia
Auslogics boostspeed serial free. I managed to solve this problem myself. For reference here's what solved my problem:
First, I was wrong in that disabling all blocking of NTLM resulted in the same symptoms. It resulted in a different symptom, that happened to have the same effect. Without any NTLM blocking policies in effect, the
dir
command now resulted in an access denied error. Group Policy still wouldn't apply, which makes sense: SYSVOL was still not accessible.A bit of web searching told me that I know had a more common problem. though. Apparently, Windows 10 clients can have problems accessing the SYSVOL share of domain controllers (and perhaps the NETLOGON share as well). Supposedly Windows 10 changed something in the way it accesses those shares, which can result in problems. The workaround is to disable UNC Path Hardening on the client for these shares, by setting the 'Hardened UNC Paths' Group Policy for the Windows 10 clients like this:
(If you're experiencing problems with accessing the Netlogon share from Windows 10 clients, it could help setting all three parameters to zero for that share as well.)
See the article from Microsoft about MS15-011 for more information. It contains a good description of the security implications of changing this setting, as well as detailed steps of how to change the policy.
Warning: Note that the settings above disable some or all of the protections against the security issue MS15-011 was created for! Do not just blindly copy/paste them, but take an informed decision based on the risks involved. Also, this issue is likely to be solved sometime in the future. When that happens, don't forget to set this policy to the recommended values as described in MS15-011.
Group Policy Not Updating On Reboot With Joe Pdf
JurjenJurjen
I tried several suggestions including registry changes and local group policy changes, none of which solved the problem -- mapped drives still were X'ed out on boot. A gpupdate would fix it every time, but that was an added step for the user.
What ended up fixing it was manually mapping the network drives, replacing the GPO entries on each of them. No need to disconnect and replace, I mapped them the same as they were mapped, just manually.
CoryCory
Just FYI for anyone else who finds this thread, turning off UNC hardening via setting mutual auth to 0 is disabling some of your security. We're running same issue with win7 clients, and I was trying to work with Microsoft on it. They told me it's a bug, but so far haven't given me a way to track when the bug will be addressed.
Karl marx books in telugu pdf. See this other thread for more infohttps://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64
sally5432sally5432