none
Group Policy Preferences are not applied at logon

    Question

  • Hello

    I have a problem where if a user logs in to his/her computer immediately after a reboot, no GPP's are applied.  If the user waits for one minute before logging in, everything is there.  If the user runs gpupdate after a quick login, everything shows up.  This happens to all users.

    This is the error I get for one of the GPP's attempting to map a drive: Group Policy Object did not apply because it failed with error code '0x80070035 The network path was not found.' This error was suppressed.

    I already have the "always wait for the network at computer startup and logon" setting enabled and verified with rsop.  Also I know the network is up, because I'm using Teamviewer to log in remotely.

    I have tried these two bandaid workarounds:

    • Put gpupdate into a GPO logon script batch file but that freezes my computer on a black screen for ten minutes at logon
    • Put gpupdate into a scheduled task to run at logon but it fails with this error: Group Policy Object did not apply because it failed with error code '0x8007007b The filename, directory name, or volume label syntax is incorrect.'

    It would be nice if my users could log in right after a reboot and have their network drives.  Hopefully someone can help me to figure out why the GPP isn't applying or failing that, maybe help me to figure out why my workarounds are failing.


    Hutch

    Thursday, February 23, 2017 7:22 PM

Answers

All replies

  • It would be nice if my users could log in right after a reboot and have their network drives.  

    Do you disconnect and reconnect all drive maps at every user logon ? (if so, that seems,,,,unnecessary?)

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, February 23, 2017 8:16 PM
  • I do not have the reconnect option selected because if I do then at every logon we get the "Could not reconnect all network drives" nag.  Then all the drives have a red X on them until you click through them. 

    That doesn't matter though.  Network drives are just one thing.  None of the GPP settings are applying.  Map drives is just one of them.


    Hutch

    Thursday, February 23, 2017 9:13 PM
  • ok, so depending upon the capabilities of the client OSversion you're using, some event/log diving might reveal what's going on.

    similar discussion here where I suggested a couple of things to look at

    https://social.technet.microsoft.com/Forums/en-US/85faed81-f2e1-4fe8-9f7a-28812512d018/unable-to-apply-gpo-setting-without-running-gpupdate-force?forum=winserverGP

    In your case, it seems that GP is trying to process (rather than other scenarios where it's not known if it's even trying). That suggests to me that the pre-flight-check by GPSvc is succeeding, but name resolution or SMB/CIFS slot to the server/share for the drive map is failing.

    Is it only GP-Preferences CSE's failing? Or are classic GP's (those which use ADM/ADMX templates etc) also failing to apply?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, February 24, 2017 8:24 AM
  • Hi,
    >> Group Policy Object did not apply because it failed with error code '0x80070035 The network path was not found
    Please check the following the article regarding this error to see if the troubleshooting steps are working for you:
    https://social.technet.microsoft.com/wiki/contents/articles/12223.troubleshooting-the-drive-maps-preference-extension-in-group-policy-adding-a-share-name-with-trailing-slash-returns-error-code-0x80070035.aspx
    >> Group Policy Object did not apply because it failed with error code '0x8007007b The filename, directory name, or volume label syntax is incorrect.
    Please have a try to enable the following policies in GPO for client computers to see if it helps:
    Computer Configuration\Administrative Templates\System\Logon\ Always wait for the network at computer startup and logon
    And you could refer to the similar threads for suggestions: https://www.experts-exchange.com/questions/25059294/Group-Policy-Preference-Printer-Error.html
    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, February 24, 2017 8:35 AM
    Moderator
  • Hi Wendy

    I appreciate the response but you obviously didn't read the question.  Your first post is irrelevant because my drives do map as long as the user doesn't log in within the first minute the login screen is presented to him/her.  If the user does login within that time, running gpupdate will map the drives.

    Your second point was already addressed in my question.


    Hutch

    Friday, February 24, 2017 2:29 PM
  • Classic GP and Computer GPP are both fine.  It's only User GPP that fails and only if the user logs in within a minute of having the login screen presented after reboot.

    Hutch


    Friday, February 24, 2017 2:37 PM
  • Hi,
    What are the settings on the drive maps: Replace, Create or Update? And on the "common" tab, did you uncheck "run in logged in user's security context"?
    In addition, I would suggest to check the DNS settings on the machine. As far as I know, long logon times and long drive mappings could be due to long lookup times because of a DNS issue.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, February 27, 2017 2:00 AM
    Moderator
  • Hello Wendy

    I think you're too focused on the mapped drives.  The issue is User GPPs are not applied.  Mapped drives are just one of the symptoms.  I also do not get shortcuts created or files placed either.  It doesn't matter if I use replace, create or update when the GPP isn't even applying.  Here is the error I get for shortcuts:
    Group Policy Object did not apply because it failed with error code '0x80070002 The system cannot find the file specified.' This error was suppressed.

    I do not have long logon times.  I'm logged in and at the desktop 25 seconds after the BIOS finishes its POST.  I do not have any DNS issues

    Hutch


    Monday, February 27, 2017 4:22 PM
  • Hi,
    Maybe, we could have a try using the Group Policy Service Debug logs (gpsvc.log) to check what is going wrong, here is an article reading to analysis gpsvc.log, you could refer to:
    https://blogs.technet.microsoft.com/askds/2015/04/17/a-treatise-on-group-policy-troubleshootingnow-with-gpsvc-log-analysis/
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, March 1, 2017 1:48 AM
    Moderator
  • I enabled the logging and it looks like Windows gives up on waiting for the network in about a second.   Here are the pertinent lines:

    07:26:29:847 Detected that this is machine Startup
    07:26:31:175 Waiting for NETLOGON failed with timeout 1068
    07:26:31:175 Wait for network connectivity timed out... proceeding to apply policy
    07:26:31:394 Application complete with bConnectivityFailure = 1

    Why would it timeout so fast?  I have the "always wait for the network at computer startup and logon" setting enabled and verified with rsop.


    Hutch


    Wednesday, March 1, 2017 5:26 PM
  • I enabled the logging and it looks like Windows gives up on waiting for the network in about a second.   Here are the pertinent lines:

    07:26:29:847 Detected that this is machine Startup
    07:26:31:175 Waiting for NETLOGON failed with timeout 1068
    07:26:31:175 Wait for network connectivity timed out... proceeding to apply policy
    07:26:31:394 Application complete with bConnectivityFailure = 1

    Why would it timeout so fast?  I have the "always wait for the network at computer startup and logon" setting enabled and verified with rsop.

    1068 = the dependency service or group, failed to start

    you might need to dig into why NETLOGON is taking so long to start?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Wednesday, March 1, 2017 8:28 PM
  • I guess that was a bad log sample to post.  I've rebooted a few times and I don't get those errors.  It must have been a one off.  This is typical of what I've seen in the last four reboots:

    06:07:53:551 Detected that this is machine Startup
    06:08:02:536 Wait For Connectivity: Succeeded
    06:08:04:364 Application complete with bConnectivityFailure = 0
    06:08:13:613 GetGPOInfo:  Entering...
    06:08:13:613 SearchDSObject:  Found GPO(s):  <[LDAP:/...
    06:08:13:613 ProcessGPO(User):  Deferring search for <LDAP://...
    06:08:14:330 ProcessGPO(User):  Searching <cn={7F311607-05AC-49F1-A875-0985BEBB61D1}...
    06:08:14:330 ProcessGPO(User):  User has access to this GPO
    06:08:14:330 ProcessGPO(User):  GPO passes the filter check
    06:08:14:346 ProcessGPO(User):  Found display name of:  <Mapped Drives>
    06:08:14:346 ProcessGPO(User):  Found flags of:  0
    06:08:14:346 ProcessGPO(User):  Found extensions: ...

    And from the Event Log at 06:08:15:

    The user 'X:' preference item in the 'Mapped Drives {7F311607-05AC-49F1-A875-0985BEBB61D1}' Group Policy Object did not apply because it failed with error code '0x80070035 The network path was not found.' This error was suppressed

    So it finds the GPO but does not apply the preferences in it.  If I wait until the next GP refresh, one to two hours later, or if I manually do a GPupdate, all the preferences will be there.


    Hutch





    Thursday, March 2, 2017 4:09 PM
  • I have to make a correction.  I do not get any timeout errors when I have the GpNetworkStartTimeoutPolicyValue reg key set to 60 seconds.  I do get them when that registry setting is missing,  which doesn't make sense because I have the "always wait for the network at computer startup and logon" setting enabled, so it should always wait.

    It doesn't really matter because even when I do get the timeout errors, the connection is always established before the GPO processing begins.  Either way the GPOs are found and applied but the preferences do not take hold until the next GP refresh or manual gpupdate.

    If I wait for a minute after the logon screen is presented, I get everything.


    Hutch


    Thursday, March 2, 2017 6:39 PM
  • I have to make a correction.  I do not get any timeout errors when I have the GpNetworkStartTimeoutPolicyValue reg key set to 60 seconds.  I do get them when that registry setting is missing,  which doesn't make sense because I have the "always wait for the network at computer startup and logon" setting enabled, so it should always wait.

    It doesn't really matter because even when I do get the timeout errors, the connection is always established before the GPO processing begins.  Either way the GPOs are found and applied but the preferences do not take hold until the next GP refresh or manual gpupdate.

    If I wait for a minute after the logon screen is presented, I get everything.

    The symptom sure does seem to be timing-related. Is there anything different/unusual about your network environment? Like, are you using 802.1X or WiFi or anything which isn't normal/everyday wired Ethernet?

    No funky switch configurations or things which might cause Windows to get confused about the network being up/available/viable ?

    Did this all previously work fine, until some networking changes?
    Or, has it never really worked correctly?


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, March 2, 2017 8:22 PM
  • Nothing unusual.  Portfast is enabled on all workstation ports and I've disabled STP altogether on the computer I'm testing on.

    I've always had problems with mapping drives but the issue is most prevalent on the newer faster computers with SSDs.  100% failure on those ones.  Over the last couple of days I've tried logging into some of our slower computers right after a reboot and the drives are there.



    Hutch

    Thursday, March 2, 2017 8:54 PM
  • ok so seems like you've already explored this: https://support.microsoft.com/en-au/help/2421599/windows-7-clients-intermittently-fail-to-apply-group-policy-at-startup

    some thoughts here (from a web search for 'computer too fast group policy' :)

    https://social.technet.microsoft.com/Forums/en-US/d571bb7a-2e28-4b69-be74-cfac5ccd6383/ssd-drives-and-gpos?forum=winserverGP&prof=required

    https://community.spiceworks.com/topic/827830-solid-state-drive-breaks-authentication-seriously

    EDIT: I'm also reminded of 'improvements' made in modern versions of Windows to 'optimise' GP processing. Which I think was MSFT's way of saying 'we won't check/process every time like we used to do'. I can't recall which OS that landed with, perhaps it was Win8.

    Are you seeing the issue across older and also newer OS versions?

    I haven't faced the same issue myself so far, but, it may well be happening but nobody throwing rocks at me about it in my org so far. At this point, if it were me, I'd be thinking about logging a premier support case. I have given up on the dignity thing of late, and just burn a ticket :S


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    Friday, March 3, 2017 9:43 AM
  • Hey Don

    Your Technet link refers to this Spiceworks article that suggests adding the Netbios domain name as a host entry in DNS, mapping it to the IP of a DC.  

    I would be unable to do that because I use DFS and map my network drives to the Netbios domain name, which would be a conflict.  That's when the lighbulb turned on.  I changed the drive maps from \\domain\share (which works fine except for immediately after reboot) to \\domain.com\share and now everything works as expected. 

    All of my missing shortcuts and files were also using the netbios domain name so this solves all issues


    Thanks for pointing me in the right direction.


    Hutch


    Friday, March 3, 2017 3:45 PM
  • oh, cool. glad that had a hint which got you sorted. I was pretty much out of suggestions.

    oh, that old NetBIOS domain name stuff, it just keeps hanging in there in our heads, can't get away from the old ways somehow ;)

    [fqdn's and upn's and OAuth...oh my...]


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Friday, March 3, 2017 11:09 PM