Jump to content
Compatible Support Forums
Sign in to follow this  
LaZZaR

Weird login script problem with NT4 server

Recommended Posts

Come on you intelligent lot, help me out here laugh

 

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 laugh

 

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

Are they also using novell? I have seen problems like this fixed by changing the network access order.

Share this post


Link to post

Try getting rid of the mapped drives ... they should not be needed. Also get rid of the /v (I assume verbose) and replace it with /e which answers yes to all questions)

 

Nothing to lose heh!

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×