DOS cannot read network share on Win2K server

[zephyran]

We use Symantec Ghost 7.5 to image our client computers. We currently use DOS boot disks (generated by Ghost) to boot the workstations to DOS, map a network drive to the server where the image files are, and then automatically run the Ghost application.

We use a single server for ghost images, and it worked fine when that server was running Windows NT 4 (as a BDC in the domain). I upgraded the server to Win2K this past weekend (now a domain member server), however, and now as the client boots from the DOS disk and tries to start Ghost, it gives a "Bad command or filename" error.

When I try to do the "dir" command against the network drive, I get "File not found". I use a Domain Admin account to connect the DOS client to the server, and the permissions for the Ghost directory have not changed. Does anyone have any ideas what could be causing this issue, and what I can do to resolve it?

 

[vbrocks]

You may have to reinstall the ghost program under win2000..
Can you list the autoexec.bat file on the floppy for us, so we can see what is happening?

 

[zephyran]

The Ghost program accessed by the DOS client isn't installed on the server. It's actually just an executable that Ghost normally places on the boot disk when creating it. It isn't on this particular disk because there's not enough space for it and the rest of the drivers that the DOS client needs.

The disk basically boots the client into a stripped-down PC DOS that logs the client onto the domain and maps a network drive to a share on the server. I then modified Autoexec.bat to automatically launch the Ghost program, which I then use to load the image from the network drive onto the client.

Here are the contents of the Autoexec.bat file on the boot disk:

@ECHO OFF
SET PATH=A:\NET\;a:\;%PATH%;
SET TEMP=A:SET TCPHELP=A:\NET
SET ETCDIR=A:\NET
REM \MOUSE.COM
A:\NET\NET START
A:\NET\NET.EXE USE F: \\server\clients
F:
cd ghost
ghost.exe

During boot, it appears that the execution of Autoexec stops with "Bad command or file name" at the "ghost.exe" line (the drive map and the change directory both work fine).

After ghost.exe fails to start is when I run the dir against the current drive (F:\ghost) and get "File not found". When I go back to the root of F: and do a dir, I also get "File not found" (which is pretty strange, since the cd command worked).

I made no changes to the boot disk after I upgraded the server, so what you see here worked fine when connecting to the NT4 server. Thanks for your help!

 

[vbrocks]

Try this ...



@ECHO OFF
SET PATH=A:\NET\;a:\;%PATH%;
SET TEMP=A:SET TCPHELP=A:\NET
SET ETCDIR=A:\NET
REM \MOUSE.COM
A:\NET\NET START
A:\NET\NET.EXE USE F: \\server\clients password:adminpassword
F:
cd ghost
ghost.exe

Win2k needs authentication ......
Also ...
Make sure you have the path shared out with ntfs permissions correct.

 

[zephyran]

While booting, DOS prompts to be logged into the domain with username and password, but I tried your suggestion. It caused the drive map to fail due to a syntax error.

I doublechecked the NTFS and share permissions for the share and the program directory; both are correct and have not changed since before the upgrade.

 

[vbrocks]

Did you go to the server itself and verify that the path and the files are still intact, and the ghost.exe file is still there...

 

[vbrocks]

After the batch file runs, what does the computer say if you do ....

pwd?

dir/w? Does it list any files?

 

[zephyran]

Yes I did.

 

[karlisi]

Check your domain and DC policies on user rights and security options, especially for LANMAN authentication level.

===
Karlis
ECDL; MCP

 

[zephyran]

pwd returns "Bad command or filename" (it's a very limited installation of DOS).

dir /w returns "File not found".

I checked the server's Local Security Policy, and LM and NTLM authentication is allowed. That setting is not configured in the Domain policy, and the server is not a domain controller (so the Domain Controller Security Policy shouldn't apply, right?). Digital signing and encryption (always) were disabled at the local level and not defined at the domain level, and I didn't see any other settings that would interfere with authentication or communication.

 

[vbrocks]

Maybe you should try a newer version of dos, what version are you using?

 

[zephyran]

It's PC DOS version 7.10. It's the one that ships with Symantec Ghost 7.5.

I did find a workaround on Symantec's website that basically has you set the Share security very low on the drive to be accessed. After doing that I was able to properly access the directory and the executable. However, I don't want to have this directory wide open, nor do I want to have to change the permissions every time I need to image a workstation. Although the client is not a domain member, there should be a way for me, using Domain Admin credentials, to access it without opening it up to "Everyone" or "Authenticated Users".

The share and NTFS permissions are exactly the same as they were before the upgrade, so I'm assuming there's an Active Directory policy or component interfering with the access.