"Running scripts" takes forever! 2

[NFI]

Hiya,

this is a problem that seems to have crept up on me over the past week or so - when users log onto my network, they have to wait up to two minutes for "Running Scripts" and "Applying Settings" to finish at the local machine. I know the first question you should ask yourself is "what have you changed recently?" but I've changed nothing, I swear!

So...what exactly is happening during these two events and why is it taking so long?

My network is 15 XP SP2 clients with a single 2003 server, so nothing complicated...


Any thoughts will be much appreciated,

Thanks,

Paul

 

[FaiTHLeSS]

Do you run WUS or SUS on your network? Could it be trying to apply some update/patch on to your client machines?

Could be something on one of your scripts is timing out but its taking a while to time out, might want to check through the scripts and check that things can be accessed.

Is there anything coming up in the event logs during the logon times?

Are the users using local or roaming profiles?

 

[NFI]

Hi FaiTHLeSS,

thanks for your reply; to answer your questions...

I run WSUS on my network, version 3.0 beta. It seems pretty reliable, except I seem to have a few failed updates, all related to Office 2003.

The only script I run at logon is the domain user logon script and that runs after all these startup scripts (which I'm not entirely sure what they are, to be honest) have finished and the desktop becomes available.

The even logs on the client machines are complaining about my profile directory allowing offline file caching which may cause profile corruption (I fixed that today, I think), some are complaining about something horrendous about .NET failing and some are complaining about webfldrs not working properly due to file protection...

My users are sort of semi-roaming, as they copy their profiles down at logon, but redirect their my documents and their desktop to a network share.

Is there any way of making XP more forthcoming about what exactly it's doing at logon? I've tried the old verbose registry key, but it doesn't really make an awful lot of difference.


Thanks,

Paul

 

[FaiTHLeSS]

To me it sounds like it might be trying to install something during the logon process and maybe getting stuck a bit.

Does this happen to all users or just some? Check profiles sizes etc to see if its just slow at pulling down their profile to the local PC.

What happens if you create a new user but dont include that user within current policy that ohter users are using?

If you want to troubleshoot the logon script to see if that is causing the problem you can edit the GPO to make logon scripts visable during logon, user configuration > Administrative Templates > System > Scripts, but remember if you do this all users will under that GPO will see the script when logging on.

For errors showing up in the event log you can check eventid.net to match event id there to see if they have any similar errors that match yours.

 

[downloadkid]

Do you have in the GPOs software to be installed, ie MSIs?
do they require .net, if so are you using the right version.....stupid question i know but i had a similar problem, turned out the particular software I was installing required a particular verision of .net. that said, though it holds things up, it's not usually that bad. If you check the event logs on the local machine it will point you in the right direction.
I suspect it's more profile related, if as you say you haven't changed anything.
2003 is a great system but it has its flaws, one such flaw is that for reasons of its own, sometimes GPOs don't work. A prime example to check is the user profile. By default when a user logs off it shouldn't copy back to the server profile copies of things like temp, temp internet files etc, well in some cases it does. so when a user logs back on it has to copy everything back, the more time taht passes the longer it takes because the bigger the profile...
A few days of surfing will clog up any profile....might want to start there.

 

[NFI]

Thanks for your help chaps.

I'll have a go at all these things and see where that gets me - I suspect it maybe a GPO problem based on what you've said, as the administrator (who's under a different policy) can log on fine...

Thanks again,

Paul