Windows Enterprise Client Boot and Logon Optimization – Part 18, Infrastructure and Settings – Group Policy

  • Article

This post continues the series that started here.

Going forward from this post until the end of the series, I want to discuss the impact that your infrastructure and settings have on Enterprise client boot and logon. I’m going to begin with Group Policy.

Synchronous Group Policy Processing

I outlined the Winlogon phase activities during Part 13 of this series. A key point of this discussion was that if Group Policy is processed synchronously, logon waits for Computer policy processing, which waits for the network to become available (specifically the Network List service), which waits for all auto-start services. The chain of dependency here is quite long.

Starting some years ago, Microsoft IT spent time looking for opportunities to optimize our own user experience. They were able to determine the average user experience across the Enterprise and compare synchronous Group Policy processing to asynchronous Group Policy processing –

image

The same set of tools and analysis is available to Premier customers as an onsite engagement delivered by Microsoft Services. This engagement is known as BootXRay, the datasheet for which is available here

I want to share a slightly deeper view of synchronous Group Policy processing –

SyncPolicy

  1. Wait for the network (the Network List service must be started)
  2. Discover a Domain Controller
  3. Enumerate GPOs that could apply based on organizational unit
  4. Apply Security and WMI filtering to enumerated GPOs
  5. Create the final list of GPOs that apply
  6. For each client side extension (security, administrative templates etc.), list applicable GPOs
  7. If a client side extension has changed in any GPO, apply all the GPOs containing that CSE
  8. Repeat for each CSE that has a change
  9. Finish
  10. Execute scripts

Considering each step, there are several optimizations you can make –

  • Ensure that Active Directory Sites and Services is configured well to provide an in-site or close Domain Controller
    • Proximity to the Domain Controller is critical because each GPO must be read from SYSVOL with a separate SMB conversation
      • For this reason, fewer GPOs with more settings perform better than more GPOs with fewer settings
  • Try to use only the OU hierarchy to determine the policies that apply to the computer/user
    • Security filtering comes with a performance cost
    • WMI filtering comes with a high performance cost
      • Performance depends on the particular query (filtering on Win32_Product is particularly slow)
      • The filter fails to apply if the client side WMI repository is corrupt
  • Apply all configuration for a particular CSE from a single GPO
    • e.g. Folder Redirection
    • This minimises the number of GPOs that will be re-applied when a CSE changes
  • Disable
    • Computer settings in user GPOs
    • User settings in computer GPOs
  • Try to eliminate scripts in favour of Group Policy Preferences
    • GPP item level targeting is more granular than group policy and filtering allows flexibility, without relying upon WMI
    • If you must use a script, PowerShell is not always the best choice because it takes time to load .Net libraries

Ultimately, it’s preferable to avoid synchronous Group Policy processing. Triggers for synchronous Group Policy processing are –

  • Always wait for the network … GPO setting
  • Folder redirection
  • Software installation (from a GPO)
  • GPP mapped drives (prior to Windows 8.1)
  • GPP Printers (using replace mode)
  • Roaming User Profiles
  • Disk Quotas
  • NT style logon scripts (configured against the AD account)
  • First time logon (occurs every time for a mandatory profile)

Features such as Folder Redirection and Roaming User Profiles were developed at a time when Local Area Networks were the limit of your Enterprise. While they continue to work, their impact on larger, more distributed environments can be undesirable. My suggestion would be to move away from these older technologies and embrace new capabilities such as OneDrive for Business, Work Folders, and User Environment Virtualization.

Software installation using Group Policy doesn’t scale well in the Enterprise and should be avoided in favour of other deployment mechanisms such as System Centre Configuration Manager.

The Group Policy setting Always wait for the network at computer startup and logon forces synchronous Group Policy processing every boot. Some organisations use this setting intentionally because asynchronous Group Policy processing means that some policy changes may take up to two reboots before they apply. I’d encourage you to avoid its use as the user productivity impact over time will be significant.

Assessing the Impact of Group Policy

As you benchmark your client image or perform analysis for a production issue, consider gathering boot traces with the computer and user placed in an Organizational Unit with policy blocked. Compare that trace to another taken when the computer and user are in their typical production OU and compare the difference.

Another useful piece of data is a Group Policy Results report captured from an elevated command prompt using

gpresult /user domain\targetusername /h gpreport.html

By using an elevated command prompt and specifying the user account, the report will contain both computer and user Group Policy results.

Starting with Windows 8, this report also contains processing time for each CSE –

image

Conclusion

Today I’ve discussed the impact of synchronous Group Policy processing on the user experience and provided some strategies for optimizing the user experience.

Ultimately it’s better if you can avoid synchronous Group Policy processing which allows settings to be applied in the background after the user logs in.

Next Up

Infrastructure and Settings – User Profiles