Jump to content

Recommended Posts

Posted
Well at the moment we have two OUs - the whole school OU - which is where the latest (above) log file comes from. You can see how long that takes to log on.

 

The second OU is my test OU. Here we have been adding GPOs one at a time. I've recreated my IE GPO based on a new .adm file. Seems I was using an old one (IE7 .adm file) - so that's been updated. The logon time was around 9 seconds. However, I've just added a GPO that contains a script to map a drive - whoosh - logon time suddenly increases. Yet this script has to be there. We will be looking at it again on Monday.

 

Did you see anything of interest in the log file?

 

Gareth

 

What version of server are your DC's running? Whats the script like? VBS or batch?

  • Thanks 1
Posted
What version of server are your DC's running? Whats the script like? VBS or batch?

 

Hi - the central LEA DCs are running Windows 2003r2 but do have a central store for .admx files which can be edited with Windows 7 machines. There are plans to upgrade them soon to 2008r2 - everything is in place and the testing done (from what I have been told).

 

The scripts are vbs.

 

Gareth

Posted

Try changing the script for a simple .bat file and see if that helps.

 

Do you have any problems running to the folder where the script is located?

Posted
Try changing the script for a simple .bat file and see if that helps.

 

Do you have any problems running to the folder where the script is located?

 

Not that I am aware of. All the script does is the following:

 

1. Check to see of the machine is in the SuccessMaker security group.

2. If Yes - unmap the LEA M drive and remap it to the SuccessMaker server.

 

I'm sure the script does more than that but cannot get access to it at the moment.

 

If the script does not run SuccessMaker does not work. However we know the script is running and M is being remapped.

 

Gareth

Posted

Today we started tidying up our GPOs and managed to consolidate a couple into one larger one. We knew the settings worked so slapped them all together. Also created a GPO to install Base software for when a machine is built. When looking at the logs from Policy Reporter we can see each policy being loaded and read - now this must take a little bit of time (even if it is milliseconds) - so are working on the assumption that less policies is better than more policies.

 

Gareth

Posted

So this tale is getting better. The LEA have been looking at some stuff and so far we have managed to get the logon time down for a cached profile to around 35-40 seconds depending on the machine. At the LEA centre the logon is around 15 seconds which they say is right as they map drives across domains.

 

Now this is our issue - the LEA have discovered an issue with mapping drives across domains. The LEA SIMS server is on a different network to the LEA Curriculum Domain. For some reason the drive mapping they have in place with a script is taking 15 seconds to connect. Thus adding this time to the logon - increasing it to the 30 or so seconds.

 

This weekend the LEA restarted their domain servers in the early hours of the morning as they had identified a couple of authentication issues during Friday. So hopefully this may solve something or other.

 

SO it's getting better. Myself and Richard (techie) are working on consolidating GPOs and cutting down the amount of individual/little GPOs we have on the network.

 

Gareth

Posted

We have loads of GPO's and some did cause problems with slowing logon times.

 

The things we did that helped

1) Disable User/Computer configuration - If a GPO only has user settings then disable to computer settings(and vice versa), this is especially important for GPO's linked high up the tree.

2) Reduce Security filtering, ensure that GPO's are applied to the best OU's and don't use security filtering where possible. This can depend strongly on your OU structure

3) Don't duplicate settings between GP's that all apply to the same set of Objects, there is no need to set Hide the control panel 4 times in user policies

4) Remove ADM templates that aren't in use from each GPO, this took a while, but really made a difference, the ADM's get included in the GPO which increases the size and therefore the download time. we reduced our average GP folder from 2mb to under 500k. By default there are a bout 4 ADM's in each policy. if it is a software installation policy it doesn't need any of them.

5) WMI filtering really affects the processing speed of GPO, don't use it unless you really have to. Security filtering is OK and OU Targeting is best.

 

Hope this helps you out.

 

Skr

Posted
Here is the latest file taken from a machine today that is not my test machine.

 

Here is what stands out to me - even though I do not understand everything..

  • 22 second gap between rows 614 and 621
  • Row 1877 - 59 seconds to reach logon box
  • Between 1878 - 1918 - no DNS
  • When the user logs on it takes 21 seconds between 3016 and 3020 - to do what?
  • No idea what is going on between 3385 - 3400

Feel free to disect :-)

 

Thanks everyone,

 

Gareth

 

* In my opinion you have 2 processes that slow down the startup procedure : the symantec AV (C:\Program Files\Symantec\Symantec Endpoint Protection\Rtvscan.exe) and the Imperoclient (c:\Program Files\Impero Solutions Ltd\Impero Client\imperoclient.exe)....

For testing purposes disable them and check how long it takes...

* The DNS errors can be skipped and should not be a problem. Normally they are generated by secondary programs that are not related to the login procedure (can't see for sure cause the excel sheet does not contain process id's)

* between 3016-3020 probably caused by enabling GPO logging

3385 - 3400 same as the DNS errors

 

bio...

Posted

The IE branding policy can really slow things down, there was a bug that MS fixed, broke and kinda fixed again that can add 20 seconds to your logon times :-O

 

Put verbose mode on to watch the policies applying then the logging methods above would be a good place to start.

 

We currently split the policies out for Users and Computers but when I rebuild the teaching machine GPOs in summer I'm going to split them out slightly for ease of management e.g.

 

Shutdown Policy

Microsoft Office Policy

Netsupport Policy

Posted
* In my opinion you have 2 processes that slow down the startup procedure : the symantec AV (C:\Program Files\Symantec\Symantec Endpoint Protection\Rtvscan.exe) and the Imperoclient (c:\Program Files\Impero Solutions Ltd\Impero Client\imperoclient.exe)....

For testing purposes disable them and check how long it takes...

* The DNS errors can be skipped and should not be a problem. Normally they are generated by secondary programs that are not related to the login procedure (can't see for sure cause the excel sheet does not contain process id's)

* between 3016-3020 probably caused by enabling GPO logging

3385 - 3400 same as the DNS errors

 

bio...

 

I doubt it is Impero service as that starts very quickly and also Impero is running at the login screen? However if is give us a call Gareth and will gladly help you through it.

 

Russell

Posted

Just looking at file Gareth what version of client was on that machine out of interest I think I remember conversation with dev team and they have changed few of start up things will have a word them tomorrow as if we can give you a even faster start up then heck see what can do... (even I wouldn't say impero is adding that much time to your login script). Would like to know why got two imperoclients running through will run tool over my test network to double check not normal behaviour through..

 

Russell

Posted

Hi Russ,

 

There is only one client on each workstation although it could be remnants of a broken 3036 many moons ago. We are waiting for the 310x version to arrive - thought it would have been there by now. We did log a call with you guys today - you may have seen it on your forums

 

Gareth

Posted

Hi Gareth

 

Did see your call come through see Mike is dealing with it let me know if anything I can do. As for 310x going through final testing we did test document on Monday. Beta sites testing it at moment... Don't worry it is coming :)

 

Russell

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...