Weird login script problem with NT4 server
Come on you intelligent lot, help me out here Was at one of my sites this morning, investigating a few users complaining about really long login times. Had a look, lo and behold, the users are correct Anyway, the cause turns out to be a line in the script which performs an xcopy from a hidden share on the server to ...
Come on you intelligent lot, help me out here
Was at one of my sites this morning, investigating a few users complaining about really long login times.
Had a look, lo and behold, the users are correct
Anyway, the cause turns out to be a line in the script which performs an xcopy from a hidden share on the server to the local c: on the PC(and I should mention this wasn't setup by me). *Why* this line is causing the problem I can't figure out.
Login, the script will run through and execute as per normal, the DOS box disappears when its finished, and then you are left with the NT "please wait while your login script executes" dialog just sitting there, the computer seemingly at a halt. One user said she logged in and went to do something else, came back an hour and a half later and it was still at that dialog. If I REM the line out of the script, login is normal. You can also, of course, hit the cancel button and continue like that, but that isn't a great solution.
Now why on earth would this simple copy function be causing these delays? The MS knowledge base unfortunately has nothing on this... the copy operation needs to be there as it updates some important files locally.
Off the top of my head the script looks something like this, nothing fancy:
@echo off
net use g: etc
net use h: etc
net use p: etc
net time etc
c:
cd\
cd somefolder
xcopy p:\*.* c:\somefolder /v
If I use copy instead of xcopy, the same thing happens. The files aren't exactly huge either, there are about 10-15 of them, about 50kb each. They do copy over fine, the script itself finishes, but the computer won't "finish" logging in unless you hit the cancel button.
The site in question is a small finance company (specifically property), a single NT4 Server SP6a domain controller, Pentium III with 256mb RAM, sits mostly idle. It does have WAN connectivity but this should be irrelevant, its only used for mail and occasionally pcAnywhere. Network is 10/100, most, if not all network cards are D-Link DFE-530TX. 10 client PCs, Win98SE.
Anyone have any ideas? This has got me stumped.
Was at one of my sites this morning, investigating a few users complaining about really long login times.
Had a look, lo and behold, the users are correct
Anyway, the cause turns out to be a line in the script which performs an xcopy from a hidden share on the server to the local c: on the PC(and I should mention this wasn't setup by me). *Why* this line is causing the problem I can't figure out.
Login, the script will run through and execute as per normal, the DOS box disappears when its finished, and then you are left with the NT "please wait while your login script executes" dialog just sitting there, the computer seemingly at a halt. One user said she logged in and went to do something else, came back an hour and a half later and it was still at that dialog. If I REM the line out of the script, login is normal. You can also, of course, hit the cancel button and continue like that, but that isn't a great solution.
Now why on earth would this simple copy function be causing these delays? The MS knowledge base unfortunately has nothing on this... the copy operation needs to be there as it updates some important files locally.
Off the top of my head the script looks something like this, nothing fancy:
@echo off
net use g: etc
net use h: etc
net use p: etc
net time etc
c:
cd\
cd somefolder
xcopy p:\*.* c:\somefolder /v
If I use copy instead of xcopy, the same thing happens. The files aren't exactly huge either, there are about 10-15 of them, about 50kb each. They do copy over fine, the script itself finishes, but the computer won't "finish" logging in unless you hit the cancel button.
The site in question is a small finance company (specifically property), a single NT4 Server SP6a domain controller, Pentium III with 256mb RAM, sits mostly idle. It does have WAN connectivity but this should be irrelevant, its only used for mail and occasionally pcAnywhere. Network is 10/100, most, if not all network cards are D-Link DFE-530TX. 10 client PCs, Win98SE.
Anyone have any ideas? This has got me stumped.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Do they have to copy these files over and over again at logon? Is there a need to keep that line in the script? Are these files ever in use by other users/programs besides at logon? Does it go faster if you use the UNC to the share rather than the newly made drive map from the script (just use \\server\share\*.* rather than p:\*.*)? One more thing, try putting the files in question in a folder, so the line in your script would read something like p:\somedirectory\*.* instead of copying from root. I have some programs that hate copying from the root of a drive as you are doing in that script.
I'm not sure why they put that line there in the first place, and its only been there for a few days. (I'm an outside contractor, the company outsources to a small IT business, but the site I work at is very far away so rather than fly down everytime something happens they call me.)
The files that are updated are financial files in relation to the "sites" they manage. I would assume they need to be copied at login in case headoffice makes a change, the change needs to trickle down to the PCs.
It was originally set up using UNC... I thought using drive mappings could be better so I changed it, and of course it made no difference.
I'll try putting everything in a folder like you suggested next time I go there, or I might try mapping a drive one folder before it. Thanks for the suggestion.
The files that are updated are financial files in relation to the "sites" they manage. I would assume they need to be copied at login in case headoffice makes a change, the change needs to trickle down to the PCs.
It was originally set up using UNC... I thought using drive mappings could be better so I changed it, and of course it made no difference.
I'll try putting everything in a folder like you suggested next time I go there, or I might try mapping a drive one folder before it. Thanks for the suggestion.
