1

Ok so here's the problem :

I've got users using logon script in the domain (username.bat). The script simply lists 4 or 5 (net use letter: \\SERVER\directory\). However, when they open their session, the logon script doesnt work and returns system error 53 or 67 for all of them. I tried running the script after the profile has loaded and evrything is running, and it still gives me the error.

I've then tried to run the same command in the cmd.exe. Everything mapped correctly. It also works fine if I map the drives using the "Tools > Map network drives" utility.

Is there anything that can prevent a command to work when ran in a batch-file but works correctly when typed in manually?

EEAA
  • 108,414
  • 18
  • 172
  • 242
Philippe
  • 97
  • 2
  • 2
  • 13

4 Answers4

1

Two options:

1) Use Process Monitor (SysInternals) with its boot logging option, filtering on CMD.EXE and System. Monitor the logon process and script execution.

2) Add a small test to the user's logon script, which uses ROBOCOPY's TBD switch to wait for the server/share to be available, i.e.:

setlocal
set LOG_FILE=c:\temp\foo.log
echo %DATE% %TIME% >%LOG_FILE%
%SystemRoot%\System32\robocopy.exe \\server\directory c:\temp\test /tbd /eta /log+:%LOG_FILE%
echo %DATE% %TIME% >>%LOG_FILE%
endlocal

Check the log file to see if ROBOCOPY does have to wait for the server/share to be available.

Simon Catlin
  • 5,222
  • 3
  • 16
  • 20
1

I ran into the same problem. For me, the solution was this:

  • I couldn't map a the root directory of a network share to a letter.
  • I couldn't use a trailing backslash in the mapped path.

So:

net use B: \\MYSERVER didn't work and resulted in error 53 right away.

net use B: \\MYSERVER\Components\ didn't work and resulted in error 53 after a pause.

net use B: \\MYSERVER\Components did work.

tangopianist
  • 11
  • 2
  • +1 and thanks! This should be the accepted solution. I have lost many hours searching for the reason why I couldn't map a network drive from within a batch script, and your answer definitely was the solution. The problem even still exists in Windows 10 (version 1809). I am a bit late to the party, though ... – Binarus May 20 '19 at 18:05
0

A few things you might try.

  1. Try using the fqdn for the server name see if you get better results that way.

  2. You might also try disabling any anti virus software on the server for testing it. I've seen McAfee take 1-3 minutes to load before it will let any kind of network connection to occure. When asking McAfee about that, they said it's setup to make sure McAfee is fully loaded before it will let any tcp/ip connection connect.

Nixphoe
  • 4,524
  • 7
  • 32
  • 51
  • I've tried out the fqdn to no avail. I haven't been able to disable the firewall yet, because my customer is really picky about his security, I will have to load a client VM just to try it out later. I've also found out a lot of people say I should try by simply replacing the server name with it's IP address, although I don't see the difference since it resolves the name correctly when I type the command out manually. I'll still try it and let you know the results later on. – Philippe Apr 04 '11 at 18:11
  • A quick test you could also do is to put in the login script to ping that server, both as the IP and the fqdn and pipe it somewhere local. That would tell you if the AV is blocking any network connections. Might also give the event viewer a once over see if there are any errors with drive mapping in there. – Nixphoe Apr 04 '11 at 18:36
0

Without the script - If your batch file contains ifmember statements on for Windows 7 you could run into an issue. I have been using Group Policy to map drives as I find it a lot easier and flexible with security groups if that is something needed.

Mark
  • 169
  • 2
  • 13