Staff logins taking far to long caused by bad Group Policy design?

[kenrick]

I have a school network of over 2000 students and around 200 teaching staff. The current time it takes for students /staff to authenticate is far too long and I am wondering if some of the issues are caused by the way our Group Policy is setup. We have an OU called User Accounts and within that a sub-OU called Staff. Within the Staff OU there is just a list of all the members of staff throughout the college and they are not split up into departments at all.

 

The Group Policy for printing is linked directly to the Staff OU, therefore when a member of staff logs on to a PC, Group Policy runs through a list of a 102 different printers to find the correct printer to install and make available. The other problem is of course that staff keep setting their default printers and then ever 15 minutes or so GP updates and their default printer has been changed again.

 

Can anyone please advise on what would be the best way forward?

 

Many thanks

 

Paul

[reggiep]

Group policy should not change something after the user has logged on? It only applies settings at the time of log on. Any changes from that point will take a log off and on again.

Have you tried disabling the group policy that is applied to that OU to see if log on times change?

Could it be a log on script rather than Group policy?

[kenrick]

I haven't had a chance to disable the Group Policy as this would stop the whole school from printing. I thought that some Group Policy settings updated without the need for a logon? Apologies if I misunderstood. Pretty sure there isn't a script involved in the printing process, I have only been here a week though so still trying to find my away around.

 

Paul

[reggiep]

Your script may not set the printers, it doesn't have to, but as your original problem was log on times I just thought you could at least problem shoot to see if it application of group policy that is the issue.

[FN-GM]

What screen do the machines get stuck on during login?

 

What client os?

[plexer]

@reggiep gp does update while a computer is in use.

 

Group Policy refresh interval for computers

 

Thing such as login/logoff scripts will only run at those times though.

 

Ben

[mtdmitchell]

First enable Verbose logging mode to see where the logon is slowest, this will help identify the problem area

Enable Verbose Global Policy Logging

 

check event logs on the devices for errors when logging on - failed redirections etc ...any gpos that fail to apply will be logged.

 

run rsop.msc on a computer and check that for errors as well.

 

also dont forget to check for dns issues, a simple nslookup on the computer will point out any dns issues

 

lastley dont overlook a simpel ping test, ping the dc (s) and check the response time.

[chazzy2501]

What are the users profile sizes? This is always causes headaches. Create a user with no roaming profile and see how long it takes. Also check your default user profile size, maybe it's been altered.

[FN-GM]

Also check your default user profile size, maybe it's been altered.

 

That would only count on the first ever logon of a computer, not every logon.

[kenrick]

All clients are running Windows 7.

[reggiep]

@reggiep gp does update while a computer is in use.

 

Group Policy refresh interval for computers

 

Thing such as login/logoff scripts will only run at those times though.

 

Ben

 

Sorry, I stand corrected! In my defence I did know they do but there is a decent enough gap before they do update, is it 90 minutes for some and up to 16 hours for others?

 

[kenrick]

I believe you can alter the refresh rates within Group Policy. I have just been running a test and added two additional networked printers. Went back to check on them 30 minutes later and they had been uninstalled.

[witch]

If you enable verbose logging I bet it is the printers that are the issue