none
How to optimize network for fast application of group policy?

    Question

  • We have issues with software installation group policies not working unless Always wait for network is enabled and startup processing wait time GPOs is set for very delayed boots.

    How do we troubleshoot why we can't get GPO software installation to work with default boot speed settings or optimize the network or domain controllers so that the group policies that kick in during reboots or user logins are quick-acting?

    Wednesday, January 13, 2016 2:05 AM

All replies

  • Hi ,

    Based on my experience, the issue seems to be caused by a delay in initializing network and locating domain controllers. Enabling "Always wait for the network at computer startup and logon" via group policy should resolve it as we need to give system more time to initiate network before proceeding with the logon process.

    We could also enable "Startup Policy Processing Wait Time" and setting wait time to an appropriate value to let the software installation GPOs working with minimal boot delays. We could know the accurate policy processing time via the Group Policy Operational Log Event. Please refer to the following article to get more details:

    Optimizing Group Policy Performance

    https://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx


    There are two ways to enable this option:

    Group Policy
    Computer Configuration > [Policies] > Administrative Templates > System >Group Policy > Startup Policy Processing Wait Time – Enable the option and set wait time to 10 - 60 seconds
    Note : This option is only supported by Windows Vista and later clients and may be not present on Server 2003 domain controllers

    Registry
    On Client Computer:

    1. Start > Regedit.exe

    2. Navigate to  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

    3. Create New DWORD value with name GpNetworkStartTimeoutPolicyValue and set Value data (decimal) to the required timeout interval in seconds

    4. Restart the computer

    Hope the above information is helpful to you.

    Best Regards,

    Alvin Wang


    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, January 13, 2016 7:45 AM
    Moderator
  • We already have those settings, but it makes the boot process much too slow.  Users have to wait 90 seconds before the login prompt appears or the software installation GPOs don't work.

    Adding these settings are a workaround for the issue.  

    What can we do so that we don't need these workarounds?  We need the computers to boot up at normal speeds and also apply group policies.

    There is clearly something wrong causing group policies to not work without extended boot delays being added.  

    Sometimes when we run the command gpupdate /force it fails and we have repeat the command a second time before the command completes successfully.  

    Maybe there is either a domain controller issue or a network issue making group polices run less reliably than they should. 

    It always eventually works, but it shouldn't be this difficult or unreliable.

    What troubleshooting steps can we take to find and fix these issues?

    Wednesday, January 13, 2016 1:21 PM
  • Hi,

    Slowdowns related to GPSI are generally one of three things: a large MSI that is being deployed, a MSI that is waiting on a prompt/user action, a network bottleneck. To fix the first and third issue, stagger your deployments or use SCCM. You can test the second issue by running your MSI through PSEXEC (part of the PSTools toolset). Download PSTools and install your MSI by using the PSEXEC -S command.

    In generally, during processing on the App Deployment CSE it makes a number of ldap calls into AD to query various aspects of each GPO policy containing deployed applications. These ldap queries are executed by calling ADSI to retrieve the data required by the CSE.

    When called with a server-less bind by default ADSI always asks for a writeable domain controller. In the scenario where the local DC is a Read-Only DC this triggers ADSI to make a call into DcLocator (netlogon) to find a writeable DC. In the course of processing APP Deployment multiple calls are made to DClocator.

    For each call to locator it is likely that multiple LDAP pings will be performed - each to a different writeable DC . It is this activity which causes the logon delay so the total delay is influenced by the number of DC's registering generic LDAP SRV records and the number of Application deployed in each GPO.”

    According to the background process of applying Group Policy Software Installation, you could try the workarounds below:

    Note that the workarounds are just for your reference.

    1. Configure a Writable DC in each site

    2. Disable password caching (possible user impact in case of wan communication disruption + slow logon)

    Hope the above information is helpful to you.

    Best Regards,

    Alvin Wang


    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.

    Thursday, January 14, 2016 9:41 AM
    Moderator
  • What troubleshooting steps can we take to find and fix these issues?

    It could be your Domain topology/design, or, the underlying network (WAN latency, DNS, switch/router settings relating to STP/PortFast etc).

    What happens if you set the wait times back to defaults?
    You said that GPSI doesn't execute in that scenario?
    In that scenario, does a gpresult (or GP logs) show that a slow link was detected?
    [slow link detection causes GP processing to behave differently, particularly GPSI]

    Does this symptom occur at remote/branch sites?
    Is there a DC on that site?
    Is DCLocator showing the correct/expected DC for an affected client computer?
    Do you have issues logged to your DCs showing subnet mismatches, suggesting your AD Sites/Services/Subnets are misconfigured?


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

    Thursday, January 14, 2016 10:46 AM
  • We have no read only domain controllers and the domain controllers are VMs on the local LAN.

    If we set wait times back to defaults, everyone is happy about how fast the computers restart, but any GPSI pending on the workstation gets skipped and wireless laptops don't reconnect to the company wifi after a reboot.

    In the past, we were able to have default settings and everything would still work.  At worst, you would need to run gpupdate before the reboot or reboot twice if group policy hadn't refreshed yet after a newly assigned software installation policy.

    When software installation during reboots stopped working, we increased the wait time as a workaround, and the software installations started working again but everyone hates the very slow reboots.



    • Edited by MyGposts Thursday, January 14, 2016 5:47 PM
    Thursday, January 14, 2016 5:44 PM
  • Hi,

    Due to the complexity of the issue you have described, I would suggest you contact Microsoft Customer Support and Services where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue. In addition, if the issue has been proved as system flaw, the consulting fee would be refund. You may find phone number for your region accordingly from the link below:

    Global Customer Service phone numbers 

    https://support.microsoft.com/en-us/gp/customer-service-phone-numbers/en-au?wa=wsignin1.0

    Best Regards,

    Alvin Wang


    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, January 20, 2016 5:49 AM
    Moderator