Ever have users complain about slow startup or login times? Do you suspect Group Policy is the culprit? Well, read on! In this guide, we are going to cover common login delays caused by Group Policy along with some specific ways to improve your login and startup times. Let’s start by making our troubleshooting a bit easier.

Displaying Highly Detailed Status Messages

Group Policy is comprised of many client side extensions  (CSEs). A few examples include Group Policy Software Installation,Folder Redirection, and Security Settings. When a machine is starting or being logged in, the Group Policy service has to process all of the settings for each CSE. By default, Windows does not show you which CSE or GPO is currently being processed. When a user reports that her machine is stuck at Please Wait or Applying Personal settings, you almost want to curse Windows for being so vague.

Your first troubleshooting step should be to enable Verbose Mode. On 2008 R2 and higher, the setting is named Display Highly Detailed Status Messages. This setting can be found in:

Computer Configuration/Administrative Templates/System/

Once enable, reboot the machine to see the detailed startup/login messages. Now, you will see messages like Installing Managed Software: Microsoft Office instead of Please Wait. Personally, I find this setting so helpful that I keep it enabled across my domain. You can read more about Verbose Mode here.

Using the Group Policy Event Log to Troubleshoot Slow Login and Startup Times

On Vista+ machines, you can take advantage of the Group Policy Event log. Launch Event Viewer, expand Applications and Services/Microsoft/Windows/GroupPolicy/Operational. In this log, you can see each CSE that applies, the order that they process, and the time it took to process.  Let’s look at some common troublesome CSEs and how to fix them.

Slow Group Policy Scripts (Logon/Startup Scripts)

Start by timing your script when it is executed in a normal windows environment. The time should be very close to the timestamp on the Group Policy Scripts event log. If your script seems to hang for 10 minutes and then fails, one of two things are occurring:

Your script really is taking longer than 10 minutes to process (ex: an Office 2013 startup script install). If this is the case, navigate to Computer Configuration/Policies/Administrative Templates/System/Scripts and enable Specify maximum wait time for Group Policy scripts. Configure the setting to be greater than 600 seconds (10 minutes).

The second issue could be your script failing to access a network resource or doesn’t have the permissions needed. Try to move any resource locally, move the logon script to a startup script, etc.

Slow Group Policy Printer Preferences

This CSE normally slows user logins down and is typically linked to too many printer preferences targeted to a single user. When possible, move printer deployments under Computer Configuration as they will process before the user logs in. If you make use of auto wake up times, your computers can process these settings before users arrive at work for the day.

Slow Group Policy Software Installation

Slow downs 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.

Common Group Policy Misconfigurations

Along with the specific problems above, your startup/logon times can be slowed by domain wide Group Policy settings and configurations. A common issue is the overuse of WMI filters (or time consuming WMI filters). WMI filters are extremely powerful because they allow your GPOs to process dynamically. Their downside is they have to be re-evaluated constantly. When you are able, avoid WMI filters.

A second widespread issue is the use of Loopback policy processing where it is not needed. Loopback allows you to apply user side settings, like a home page, to a group of computers. If you use Loopback Policy Processing in Merge mode, clients have to evaluate Group Policy twice. This can essentially double your processing time. A better solution, where possible, is to examine why you need loopback and if Active Directory can be reorganized to meet your need. For example, all of your users might be in a single OU. You might use loopback to set user homepages. The better solution is to divide your users into sub OUs and configure the homepage that way.

Our final issue is the abundant use of expensive Item Level Targetings. For example, an ILT that queries for multiple group memberships. These type of queries can slow processing because the computer has to query over the network to retrieve this information. If you absolutely must use security group memberships for Group Policy Preferences, read this Hotfix article from Microsoft.

A Final Test Method

With all of these problems, performance comes at the expense of complexity. The fastest GPO to evaluate will be the simplest. If you have followed these tips but are still experiencing slow downs, take a look at the Windows Performance Toolkit and run a trace.