none
CSE Post Process VERY Slow

    Question

  • Hi,

        We are running windows server 2012R2 on 2 domain controllers, and a terminal server environment. The system has only been up since the beginning of the year. At the start logon times were well under 10 seconds (Never timed it as wasn't an issue). However as of Last Thursday logon times have blown out to between 1 - 1.5 minutes.

    There were no changes to policy that I'm aware of at the time. But there have been plenty since while trying to troubleshoot this. I have denied a user permissions to apply any group policy's that include "preferences" and their logon time drops down to about 2 seconds.

    The group policies are designed in a way that I can apply a single group policy that only includes registry extensions, or drive mappings, or folder options. By doing this I can confirm that it IS the preferences causing the issue, and it doesn't matter if its a drive mapping, registry preference or other. They all suffer the same problem. With logging and tracing enabled for drive mappings, or registry preferences it all runs smoothly up until "Settings update set as user" at which point the processing hangs for between 20 and 40 seconds before continuing on. The drives have all be mapped by this stage and can be access while the process is hung so its not working on mapping the drives. It seems to just hang doing nothing except holding up the logon process.

    Logs from the User.log trace file

    2016-01-29 16:00:37.972 [pid=0x24c,tid=0x1c08] Completed logging of RSoP data.
    2016-01-29 16:00:37.973 [pid=0x24c,tid=0x1c08] Completed commit reporting.
    2016-01-29 16:00:37.973 [pid=0x24c,tid=0x1c08] Completed GPO list post-processing.
    2016-01-29 16:00:37.973 [pid=0x24c,tid=0x1c08] Completed get GPO list. [SUCCEEDED(S_FALSE)]
    2016-01-29 16:00:37.973 [pid=0x24c,tid=0x1c08] Starting csePostProcess
    2016-01-29 16:00:37.973 [pid=0x24c,tid=0x1c08] IsRsopPlanningMode() [SUCCEEDED(S_FALSE)]
    2016-01-29 16:00:37.974 [pid=0x24c,tid=0x1c08] IsWinlogonDesktop() [SUCCEEDED(S_FALSE)]
    2016-01-29 16:00:37.974 [pid=0x24c,tid=0x1c08] Starting settings update (csePostProcess).
    2016-01-29 16:00:37.974 [pid=0x24c,tid=0x1c08] Settings update set as User.
    2016-01-29 16:00:52.801 [pid=0x24c,tid=0x1c08] Completed settings update (csePostProcess).
    2016-01-29 16:00:52.801 [pid=0x24c,tid=0x1c08] Completed csePostProcess
    2016-01-29 16:00:52.801 [pid=0x24c,tid=0x1c08] Completed CSE post-processing.
    2016-01-29 16:00:52.801 [pid=0x24c,tid=0x1c08] User impersonation uninitialized.
    2016-01-29 16:00:52.806 [pid=0x24c,tid=0x1c08] Leaving ProcessGroupPolicyExDrives() returned 0x00000000
    2016-01-29 16:00:52.806 [pid=0x24c,tid=0x1c08]

    Running procmon and monitoring the procID 0x24c shows that it just stops doing anything for that period of time.

    Has anyone seen this, or know where to go from here to continue troubleshooting?

    Friday, January 29, 2016 6:32 AM

All replies

  • > 2016-01-29 16:00:37.974 [pid=0x24c,tid=0x1c08] Starting settings update
    > (csePostProcess).
     
    I'm unaware what exactly happens in this step, but in the past, often
    WMI was the culprit for slow gpo processing - WMI is responsible for the
    RSoP logging...
     
    Friday, January 29, 2016 11:18 AM
  • Hi Martin,

                  What did you do to WMI to resolve the issue of slow logons? I can't see any errors in relation to WMI and our monitoring system (N-Able) uses WMI extensively.

    Sunday, January 31, 2016 10:52 PM
  • Hi,
    Generally speaking, startup/logon times may be slowed by domain wide Group Policy settings and configurations. A common issue is the overuse of WMI filters and loop back.
    Here is an article regarding troubleshooting slow Startup or Login Times Caused by Group Policy, please see more details:
    https://deployhappiness.com/troubleshooting-slow-startup-or-login-times-caused-by-group-policy/
    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.

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

    Monday, February 01, 2016 7:22 AM
    Moderator
  • >                What did you do to WMI to resolve the issue of slow
     
    Reset or delete the repository.
     
    Monday, February 01, 2016 10:49 AM
  • Hi,
    I am checking if you issue is solved or not. Are the replies helpful to you?
    If you have any questions, please let us know.
    Appreciate your update.
    Best regards,

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

    Wednesday, February 03, 2016 7:29 AM
    Moderator
  • Hi,
    Thanks for posting in Microsoft TechNet forums.
    As no further update regarding this issue for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios. If the issue still persists, please feel free to reply this post directly so we will be notified to follow it up. You could also choose to unmark the answer as you wish.

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

    Friday, February 05, 2016 7:31 AM
    Moderator
  • Hi Martin,

                  Sorry about the late reply, I have been progressively resetting WMI. I've gone to the point of completely deleting the WMI repository and rebuilding it.

    But no luck, I had high hopes for this but doesn't seem to fix the issue. Must be some thing else deep in the bowels of windows.

    Any other ideas?

    Wednesday, February 24, 2016 1:04 AM
  • > 2016-01-29 16:00:52.806 [pid=0x24c,tid=0x1c08] Leaving
    > ProcessGroupPolicyExDrives() returned 0x00000000
     
    Oops - missed this line at first glance... Seems it's not a problem with
    GPO processing at all, but with GPP Drives only. So enable GPP Drives
    debug logging and analyze in depth. And grab a copy of SysProSoft Policy
    reporter which can help with analyzing :)
     
    Wednesday, February 24, 2016 10:19 AM
  • Thanks for your help Martin, I logged in this morning to try out your suggestions and logons are now back down to around 4seconds. I have no idea what has changed to fix it though.

    There have been no updates installed on the terminal server, or either domain controller. The terminal server is rebooted nightly, but neither DC has rebooted recently. There are no failed services on any of the systems.

    I'm at a loss as to what caused it, and what fixed it.

    Wednesday, February 24, 2016 10:44 PM
  • > I'm at a loss as to what caused it, and what fixed it.
     
    The lazy admin's daily business :)
     
    Thursday, February 25, 2016 9:18 AM
  • I have been able to track down the cause (No fix as yet).

    Just in case anyone else is suffering from this here is what I have found.

    The problem is caused, at least I my case. By a software packaged provided by MYOB called "Vineyardsoft KnowlegeSync". The customer is using this product to query their MYOB AE database and send daily emails if an SQL query matches. It just so happened that they had a temp license that expired. Once I applied a new temp license and restarted the service logons became very slow again. Stopping the service fixes the problem instantly.

    I at least I now have someone to point the finger at and work with to fix the problem. Its worth noting they ran this same software without issue on a windows 2008, and 2008R2 terminal server.

    Thursday, February 25, 2016 10:31 PM
  • > the service logons became very slow again. Stopping the service fixes
    > the problem instantly.
     
    It might be a workaround to set this service to delayed auto start?
     
    Friday, February 26, 2016 10:42 AM