Write a commentUsing group policy is getting more common instead of long and complicated login scripts. I often eliminate customer's login scripts into group policy and has many advantages. Nevertheless, group policy can slow down login time for different reasons. I recently showed a customer a simple way to troubleshoot login delays caused by group policy.
How do you know that you are spending too much time on applying GPO's? Therefore, I will give you my rule of thumb of GPO login time.
- Minimum GPO sets should take 1-3 seconds
- Average GPO sets should take 4-6 seconds
- Max GPO sets should take not more than 7-9 seconds
When checking the customer login duration in Citrix Director, I immediately noticed several locations that are causing issues and one I could guess right away. There were interactive session times with 100 seconds plus! and GPO times of 15 to 18 seconds. My guess for the interactive session was a login script and I was right. At the end of the script they were cleaning up printer driver and got stuck for whatever reason. Once we skipped the script, the interactive session dropped to normal values.
Now, what's with the GPO times and what is causing the long duration? There is a simple way to find out by just using what the system has to offer, no special tools what so ever. First, find the login time for the user and the target system the user is working on. Open the eventlog on that server and go to Application and Services Logs | Microsoft | Windows | GroupPolicy and scroll down to the login time of the user in question. You will find a logon notification for the user session ID that you should check (quser etc.) is the right one you are looking for.
Next, be patient and scroll slowly upwards and you should find the system connecting to the DC pulling the GPO's in question. Afterward, the GPO's are processed for the user and time used for each part is shown in ms. That means everything with more than 1.000ms time spent might be interesting to further investigate. For the customer, I found two different users with two different issues. First one spend around 8.000 ms on one GPO and meant more than half of the total time! I checked out the GPO and found a hand full of registry keys and one mapping of a network drive over WAN. The WAN wasn't the problem, it was that the share wasn't reachable because the FQDN wasn't used. The timeout or failure was causing 8 seconds of the login duration.
For the second issue, I found an 11-second delay out of 18 seconds spent on a GPO processing. This time it was mapping a network printer over WAN using RPC and is the worst thing you can do. We switched to client side printer mapping with indirect print for network printer and the 11-seconds were eliminated.
This is just an example event that spent 2,6 seconds on processing printers
Finding those three issues took me several minutes including fixing them. I hope this shows how simple but yet effective troubleshooting of GPO processing can be.
