- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
I commonly see complaints about how Group Policy processing is so slow! Most of the time, the issue isn’t with Group Policy itself but rather rests with the way an administrator configured it. At one point in our environment, some startup times approached 11 minutes! By using the Windows Performance Toolkit (WPT), we were able to get these machines to a 90 second startup time.
WinLogon
To start off, we will take a Reboot Cycle trace of a problem machine and load it into Windows Performance Analyzer.
Reboot Cycle trace
Right away, it should be clear that this machine has some serious issues. On startup, it runs through the first two phases in seconds. At the WinLogon Phase, things slow to a crawl – to be exact, a 10 Minute crawl. After finishing the startup, the user is able to log in very quickly.
We will stay in the System Activity node. To dive deeper, we will add the Windows Logon graph to granularly look at our session IDs.
GPClient seems to be our culprit
Out of the entire 10 minute WinLogon phase, GPClient used 9.5 minutes! Because our user was able to log in so quickly, we can be pretty sure that the issue isn’t with Group Policy itself. Because the total time didn’t exceed 10 minutes, we can also be sure that a script or application isn’t timing out. These two CSEs can still be our issue as they may be taking a long time to process.
Resources and processes
Now that we’ve ruled out obvious issues, what are we left with? Maybe our resource utilization is maxed out? We can test this theory by loading the CPU, Disk, and Memory usage graphs.
CPU, Disk, and Memory usage of our troublesome machine
Looking at the graphs above, we can easily see that a resource bottleneck isn’t an issue. We can now start looking at processes.
Comparing processes to GPClient
Graph selection in WPA is incredibly intuitive. By selecting the GPClient subscriber in the top graph, dividers are automatically created in the bottom (Processes) graph. You will also notice that the process list filters out processes that ended before or start after the GPClient subscriber timeframe. The applicable processes left are highlighted to ease troubleshooting.
GPScript and MSIs
I have had issues with Group Policy Scripts and Applications in the past. I have a hunch that one of these could be my issue. To make searching for the GPScript process easier, I changed my view from Graph Only to Text Only. This is a per graph setting and can be configured through the four buttons in the top right corner of the graph. It took me forever to find these buttons!
Scrolling through the list, I find GPScript.exe. Unfortunately for me, the process duration is 2.7 seconds.
The duration column can be added by right clicking on any existing column.
If software installation is slowing my startup, we would see a MSIEXEC process. Sure enough, we do, and it has a duration of 363 seconds!
This isn’t our problem though. MSIEXEC doesn’t start toward the end of our GPClient timeframe.
Group Policy processing and Event Viewer
Time to launch our old ally, Event Viewer. We are going to look in the Group Policy log and are looking for any events with a large time span between them.
Event Viewer
Wow! Group Policy took 8.5 minutes between these two events. Looking at the older event, we can see that Group Policy Files is processing a few GPOs. Looking through the GPOs, one immediately catches my eye! Not only does it have a ton of file preferences, but every preference was not set to create or to run once.
After changing this policy, running a GPUpdate, and rebooting, our Group Policy processing time went down to 88 seconds!
Group Policy processing time
