Out of the box, ControlUp offers some amazing technology for reporting on logon durations for users. Overall Logon Duration, Profile Load Time, Group Policy Load Time, Desktop Load Time and a column for unknown logon duration contributors are all calculated and displayed—in real time—right after a user has logged on.
This is extraordinarily helpful for identifying low-hanging fruit optimization opportunities.
Originally introduced in 2015, ControlUp (along with help from our community members—particularly Guy Leech) has been continually improving and increasing the functionality of the Analyze Logon Duration script, which can break logons down into granular phases, based on technology or logon processes.
But ALD can only report back on the things it understands.
See those two large gaps of time on the far right of the image? 33.9 seconds and 20.9 seconds?
When ControlUp customers have unexplained logon duration gaps, they can reach out to us to help them assist in troubleshooting the root cause of these gaps. From here, ControlUp Professional Services can assist in identifying the technology or reason for the gaps. This article will go into the technical details of the gap in this screenshot, what it is we discovered, and how ALD reports it after we added this technology into the script.
Resultant Set of Policies (RSoP) logging is a feature available in Windows that shows you what Group Policy settings the Group Policy Engine decided to apply against a user or computer.
The most common view of RSoP is the “rsop.msc” to view the applied settings:
This is great for troubleshooting!
But what’s the catch (side note: there is always a catch)?
Resultant Set of Policies is a cool feature! You can see the end state of a user’s or machine’s group policy. And with security filtering, WMI filtering, OU nesting, blocking of inheritance, different loopback processing modes, and other ways of manipulating the settings that get applied, RSoP is a powerful tool in understanding what’s happening in your environment.
So, what’s the problem?
RSoP can slow your logons down… substantially.
But how does it slow down your logons?
To answer that, we need to examine how RSoP works. There are numerous articles that touch on the ways RSoP operates, but they are usually limited in context. Here’s the “RSoP Architecture” from Microsoft. Another article, this one by Ned Pyle, dives into some nuggets while talking about how to script RSoP. I’ll summarize my findings as best as I can.
RSoP stores information in the WMI repository. It has interfaces you can implement for writing and querying data. This doesn’t sound too bad. So, what’s bad about this?
Windows Management Instrumentation (WMI)
WMI has some well-known performance issues. The worst is a O(n^2) performance bug related to the size of the repository.
Next: you can lock WMI, thereby preventing it from being written to or read from until the lock is released. This can stall operations in a major way. This impact was quantified, back in 2019, by Bruce Dawson in his blog post, “O(n^2), again, now in WMI.”.
Last, each CSE can store its RSoP to WMI as it sees fit. They can record each value as it’s evaluated, or as a whole in the end. Recording each as it’s evaluated is bad because writing to WMI isn’t fast. It’s up to the CSE makers and not all CSEs do this in an optimal fashion.
Here’s where things start to get a bit crazy.
RSoP stores its group policy evaluation results in the WMI repository. The results can be viewed with WMI Explorer.
Each time it stores a RSoP result, the WMI repository gets a little bigger (and also makes it that much slower). Now, imagine a multi-session system with users constantly logging on and off. As more users log on and off, it adds more and more bloat. Also, when group policy refreshes for the user it deletes the current results and stores the results of the refresh! If you have 50 users, this operation will execute 50 times. To make matters worse, as each user re-runs their RSoP in turn, they consume increasingly more CPU, making the machine slower for everyone. Imagine those 50 users spawning WMI tasks at the same time because the Group Policy refresh interval triggered. It’s not a good thing.
“The server grinds to a halt for a minute or so every couple hours.” Ever heard that before? It might be WMI…
But what if you have a small number of users? No biggie, right?
There is a difference between concurrent users and total users. For RSoP and WMI, each plays a factor. One of the biggest challenges of RSoP, as it exists today, is that it stores data for all users that have logged onto the machine. I’m not aware of any purging of data (I’ve never observed RSoP data getting purged), so this is just a cumulative process. The more users that cycle through a machine, the more that data is stored, the larger the WMI Repository grows, the slower it operates. Good times.
Only one user is logged on, but RSoP data from another user persists in the repository.
You can kind of observe WMI in action using the event viewer, but the event viewer is cumbersome if you’re trying to see events as they are generated. You may need to check the WMI Analytic and Debug logs to see them, but they are there.
Microsoft has some interesting notes and guidance for RSoP.
In short, turn off RSoP!
Since the Group Policy setting is a negative with a positive application, you need to enable the “Turn Off RSoP” setting. If you Disable “Turn off RSoP” then it will be Enabled. So be careful out there! ALD will report on the current state of RSoP on your machines:
The answer to this question is, “it depends.” It can impact a little, not at all, or significantly. This is pretty much the same answer for every technology that touches the logon process. 😊
ControlUp and ALD makes it incredibly easy to analyze it, though, and determine the impact and its impactor. To analyze sessions in your environment, right-click on a session, select “Script Actions,” “Analyze Logon Duration” and then “OK.”
Or use the ControlUp Virtual Expert™️, click on the “menu” icon next to “Logon Duration,” then select “Analyze Logon Duration.”
Resultant Set of Policies—or users—can be turned on and off, on demand. Just set Turn Off Resultant Set of Policies to “Enabled” and RSoP won’t be collected. But if you need someone’s RSoP results, you can disable “Turn Off Resultant Set of Policies” and either have them log back onto that box or have the user do a gpupdate.
To get insights like these in your environment, start a trial of ControlUp today (it’s FREE; there’s no sales call required)! Just to one of your machines and analyze one of your recent logons. If you need further assistance getting the proper data, reach out to firstname.lastname@example.org and one of our pre-sales engineers can help get your environment set up.