none
GPP Drive maps cause eventid: 1112

    Question

  • We are finding on Server 2012 that using GPP Drive mappings cause eventid: 1112:
    "Group Policy Drive Maps was unable to apply one or more settings because the changes must be processed before system startup or user logon."

    "Always wait for network at computer startup and logon" has been enabled but event warning still remains.

    The drives appear to get mapped correctly but we just don't seem to be able to get rid of this warning event.

    Rgds,
      Nick


    • Edited by NickC_UK Friday, November 30, 2012 3:13 PM
    Friday, November 30, 2012 3:10 PM

Answers

All replies

  • Hello Nick,

    "Group Policy Drive Maps was unable to apply one or more settings because the changes must be processed before system startup or user logon."

    Please try to blow aways the history files:

    %allusersprofile%\Microsoft\Group Policy\History\{GUID}\SID\Preferences

    If the problem persists, please enable GPP Tracing.

    http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat.aspx


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Friday, November 30, 2012 8:19 PM
  • Hello Matthias,

    Tried deleting History but that didn't make any difference.  Then switched on tracing and I now have a nice user.log.  Unfortunately I can't see any problems in there, what should I be looking for?

    Thanks,
      Nick

    Saturday, December 01, 2012 1:55 PM
  • Hi,

    This 1112 is a warning but not an error.

     

    As we can see in the article below, the specific CSEs request synchronous processing from the Group Policy service and apply their policy settings on the next restart. That’s why the warning message is received. However, this is not an error and won’t affect the applying of the GPP.

     

    Event ID 1112 — Application of Group Policy

     

    http://technet.microsoft.com/en-us/library/cc727266(v=ws.10).aspx

     

    We can follow the method in the article to run “gpupdate” and confirm whether Group Policy is actually working properly. Considering the users can get their drive mapping properly, we can just ignore the warning.

     

    For The group policy framework should call the extension in the synchronous foreground policy refresh, Refer below link which discuss the same behaviour.

    http://www.pcreview.co.uk/forums/gp-software-install-problem-t1544362.html

     

    Regards

     

    Yan Li

    If you have any feedback on our support, please click here .


    Cataleya Li
    TechNet Community Support

    Monday, December 03, 2012 6:31 AM
  • Hello Yan,

    So it looks like the GPP Drive mappings cause this due to the Logon Optimization causing it to run asynchronous.  Question is what can be done to turn off Logon Optimization and force the GPO to run in synchronous mode?

    Thanks,
      Nick

    Monday, December 03, 2012 3:06 PM
  • Hello,

    Question is what can be done to turn off Logon Optimization and force the GPO to run in synchronous mode?

    Please enable this setting:

    http://gps.cloudapp.net/#1839

    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Monday, December 03, 2012 8:39 PM
  •  
    > So it looks like the GPP Drive mappings cause this due to the Logon
    > Optimization causing it to run asynchronous. Question is what can be
    > done to turn off Logon Optimization and force the GPO to run in
    > synchronous mode?
     
    Just take it as it is. There's a few GPP Settings that have special
    processing: Although not background aware, the CSE gets invoked anyway
    to store its settings locally and be able to execute properly at next
    foreground refresh. And of these, some log warnings although this is
    usually only information.
     
    This applies to folder redirection (logs a warning), scripts (does not
    log a warning), software installation (logs a warning), and now we see
    GPP mapped drives to be affected, too.
     
    The above is not information from Microsoft, it is derived from what
    I've seen and experienced. If there's someone around here who can prove
    (or knows full details), he/she is welcome ;-))
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Tuesday, December 04, 2012 9:02 PM
  • The above is not information from Microsoft, it is derived from what
    I've seen and experienced. If there's someone around here who can prove

    (or knows full details), he/she is welcome ;-))

    Well you know, there are many switches that you can turn on / off to manipulate the
    forground / background behavior of each CSE.
    Some CSE's are quite dump an just writing their settings to the registry without really taking care of
    if the content of the settings really takes effect on this logon or on the next logon.

    Another thing is, most people think "Always wait for the network at computer startup and logon" is the ultimate
    coverage to make sure that all settings are processed as soon as the network is ready.
    Which it is not.
    If you are not increasing GpNetworkStartTimeoutPolicyValue it may also be useless.
    There is also a new setting called CorpConnStartTimeoutPolicyValue which none really nows what it does
    (I did not research this so far).

    Just take it as it is.

    IT-rule #1:
    no support for non-rebootet systems :-)


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!


    Tuesday, December 04, 2012 9:57 PM
  •  
    > Some CSE's are quite dump an just writing their settings to the
    > registry without really taking care of
    >
    > if the content of the settings really takes effect on this logon or on
    > the next logon.
    >
     
    Objection, Matthias. The only CSE that is really writing to the registry
    is "Registry"... (and gpreg of course)
    Others (like scripts, SRP or certificates) are just pulling their
    settings from the registry. That's one of the reasons why registry MUST
    be processed #1. And it's the reason for a gPCUserExtensionNames
    attribute containting something like
    [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}{B3408A2F-8DDA-1197-FBD5-2CE69A2DEFC1}{D02B1F73-3407-48AE-BA88-E8213C6761F1}]
    FDeploy and AppMgmt do not rely on the Registry CSE, they have their own
    caching mechanism.
     
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Wednesday, December 05, 2012 1:10 PM
  • Hello Martin,

    Objection, Matthias. The only CSE that is really writing to the registry

    is "Registry"... (and gpreg of course)

    I know that you like technical discussions :-)

    Unfortunately this time I can't agree.

    I did not look at every CSEs detailed registry behavior, but have a look at the Scripts CSE for example.
    Scripts CSE will write its script settings to the registry.

    The Scripts CSE is the component that is called by the Group Policy engine, and that applies the scripts setting. The Scripts CSE writes the relevant script information into the registry. It does not run the scripts.

    http://technet.microsoft.com/en-us/library/cc736967%28v=ws.10%29.aspx#w2k3tr_gpscr_how_alxp

    You can also see this, when you track the registry changes:

    There is no Registry CSE that will write the settings into registry at this time.

    But you are right, gpscript will pull the settings from the registry.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Wednesday, December 05, 2012 2:19 PM
  •  
    > Unfortunately this time I can't agree.
     
    You're right... My mistake :-D
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Wednesday, December 05, 2012 4:17 PM
  • Hello,

    Question is what can be done to turn off Logon Optimization and force the GPO to run in synchronous mode?

    Please enable this setting:

    http://gps.cloudapp.net/#1839

    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!


    Thanks for the suggestion Matthias but as I mentioned in my first post "Always wait for network at computer startup and logon" has already been enabled.  That doesn't seem to enable synchronous mode in Win 8.
    Wednesday, December 05, 2012 8:03 PM
  • So what is the conclusion here, just ignore this warning error for the moment then?
    Wednesday, December 05, 2012 8:21 PM
  • That doesn't seem to enable synchronous mode in Win 8.

    It does.
    Like I said, sometime you also have to increase the GpNetworkStartTimeoutPolicyValue which is
    30 seconds by default.

    Try to increase it to 60 seconds.
    http://gps.cloudapp.net/#319

    You should also make sure that HKLM\Software\Policies\Microsoft\Windows\Group Policy\{5794DAFD-BE60-433f-88A2-1A31939AC01F}\NoBackgroundPolicy

    is set to 1.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!

    Wednesday, December 05, 2012 9:42 PM
  • Matthias,

    I believe I have already done that by Group Policy:

    "Always wait for network at computer startup and logon"
    and
    "Specify startup policy processing wait time" = 120secs

    Can't check the NoBackgroundPolicy though because I don't have the following registry key present:
    HKLM\Software\Policies\Microsoft\Windows\Group Policy

    Rgds,
      Nick

    Thursday, December 06, 2012 9:42 PM
  •  
    > HKLM\Software\Policies\Microsoft\Windows\Group Policy
     
    Try HKLM\Software\Microsoft\Windows
    NT\CurrentVersion\Winlogon\GPExtensions instead.
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Friday, December 07, 2012 10:48 AM
  • Just checked and

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{5794DAFD-BE60-433f-88A2-1A31939AC01F}\NoBackgroundPolicy
    is already set to 1

    Yet still the eventId 1112 is listed.

    Friday, December 07, 2012 1:02 PM
  • Hello,

    Did you also enable the "Reconnect" option?
    Maybe you should think about that.

    You should also have a look at this nice article:

    http://social.technet.microsoft.com/wiki/contents/articles/12221.troubleshooting-the-drive-maps-preference-extension-in-group-policy-replace-mode-only-maps-the-drive-every-other-logon.aspx

    But there is a mistake in this article:

    This solution has been suggested in several blog posts on the Internet. Looking back at figure 1, it seems that if the NoBackgroundPolicy registry value is set to ‘1’ (one),  then the Drive Maps preference extension should be called during both foreground and background Group Policy processing.

    Should be:

    This solution has been suggested in several blog posts on the Internet. Looking back at figure 1, it seems that if the NoBackgroundPolicy registry value is set to ‘0’ (zero),  then the Drive Maps preference extension should be called during both foreground and background Group Policy processing.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!


    • Edited by Matthias WolfMVP Friday, December 07, 2012 1:33 PM
    • Marked as answer by NickC_UK Friday, December 14, 2012 2:36 PM
    Friday, December 07, 2012 1:32 PM
  • Hi,

    Just checking in to see if the suggestions were helpful. Please let us know if you would like further assistance.

    If you have any feedback on our support, please click here .


    Cataleya Li
    TechNet Community Support

    Monday, December 10, 2012 1:42 AM
  • Yes thanks Matthias, that Reconnect option worked in the end.  It seems that every Drive Map GPP needs to have this "Reconnect" option enabled to avoid the eventid: 1112 warning.

    I have to admit that even after much reading on the subject I still cannot see why this option needs to be set to get rid of this event warning, I can't see how setting Reconnect would force the drive maps GPO into foreground processing as opposed to background processing which is causing the warning.

    Cheers,
      Nick

    Friday, December 14, 2012 2:41 PM