Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have just started work on an existing 2003/AD domain where users are complaining about the amount of time it takes for an XP client to reach the logon prompt after boot (around 4 minutes).

I haven't looked into this too much so far, but one thing I did notice is that there are ~150 GPOs. Most of these could be reduced by manually going through and merging several into one. It looks so far like I could achieve the same outcome with about 30 GPOs. Luckily, the GPOs are well documented.

Some wireshark traces I have done seem to show each client checking the timestamp on each file in each gpo in the sysvol share when they boot (or on a group policy refresh). This takes about 25 seconds.

I am fairly certain there are other factors that are contributing to the long boot time of the clients, but in general, is it worth keeping the number of GPOs to a minimum?

share|improve this question
    
Some great answers guys, wish I could accept all three! –  simon Jun 30 '11 at 15:45

3 Answers 3

up vote 4 down vote accepted

Group Policy and the application thereof is a complicated topic. My suggestion before making an assumption that Group Policy is the cause of the slow startup/logon times would be to verify that your infrastructure is configured and working correctly before diving in to make Group Policy changes. You're probably on the right track but never make any assumptions about the cause of the problem until you have the evidence to prove it.

Is DNS functioning properly? Are the client computers configured correctly in relation to their DNS settings.

Are the domain controllers located correctly? Do you have more than one AD site and if so, are the appropriate subnets set up in ADS&S? Are the domain comtrollers in the proper site?

Have you run gpresults against a computer/user to verify the scope of management of GPO's that are being applied?

I would enable user environment debug logging on one of the client computers and look at the log. At the very least this will show you when GP processing began and ended for that computer/user.

Here are two articles that might help:

http://blogs.technet.com/b/ad/archive/2007/08/20/tracking-user-environment-creation.aspx

http://technet.microsoft.com/en-us/library/cc784268(WS.10).aspx

share|improve this answer
    
Thanks, those links were very useful. –  simon Jun 30 '11 at 15:56
    
Glad to help... –  joeqwerty Jun 30 '11 at 16:00

Yes, the more GPOs, the longer the startup and/or login process will take. You're on the right track. Minimize that, and then figure out the next contributing factor and fix it, until you and your users are happy.

share|improve this answer
    
+1 Security filtering on GPOs also seems to add a non-trivial amount of time in my testing. Blocking inheritance and enabling enforcement adds complexity if not documented. –  jscott Jun 30 '11 at 11:21

As a good practice, you would have an own policy with a descriptive name for each coherent preference set. This way you retain better maintainability (e.g. you can granularily disable and re-enable single policies without having a whole bunch of settings not related to each other suddenly changed) and make your documentation work easier. If your clients are checking every single group policy object, you might have a rather flat OU structure with most of your clients residing in a single OU and all GPOs connected or inherited into this OU.

You might look into segmenting this into a more hierarchical structure so less policies would need to be processed by the clients.

There is also a generic performance optimization article posted as KB 315418 on the Microsoft site.

share|improve this answer
1  
+1 But approach your granularity "within reason". I inherited a configuration in which nearly each individual setting earned its own GPO. A user/computer logon could be processing upwards of 50 GPOs depending where they are in the domain. The next step was to organize the settings and consolidate the policy objects which were related. –  jscott Jun 30 '11 at 11:18
    
That's right it is a very flat OU structure. Making more of a hierarchy is something I want to do in combination with this. –  simon Jun 30 '11 at 15:52
    
@jscott That is EXACTLY what I have got! –  simon Jun 30 '11 at 15:52
    
@simon. I feel your pain then. Plan your domain OU structure before just throwing it together. Dig out RSOP, gpresult and determine who needs which GP settings. Build new structure, draft new GPOs, link only the required GPOs, populate with users/computers. It's not glamorous work, but it feels good once sorted. –  jscott Jun 30 '11 at 15:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.