Solved Copy file from server share to domain comps

Microsoft windows Server 2003 standard e...
August 1, 2011 at 23:18:35
Specs: Windows Server 2003
Hello,

I'm hoping someone can point me in the right direction here. I'm at about my wits end with commands and formatting and unfortunately none of my efforts are paying off. I'd like to be able to copy a file from a server share to a Domain computer at startup time, overwriting the file if it already exists. Ideally I'd like to implement this within Group Policy. Therefore it'd be a Startup script. The problem is no matter what command-line tool I use (I've used COPY, XCOPY and ROBOCOPY) the net result is always the same, that CMD.EXE cannot be executed from a UNC path.

I've read elsewhere that I have to change a Registry key in order for CMD.EXE to be able to use UNC pathways, however doing this may present a security issue for my company and I'd instead prefer to use native commands/programs to get this done. I've also read about PSEXEC but am unsure if this will solve my problem either. A VBscript or WSH script may solve my issue, but again I don't know if I'm limited to the CMD.EXE window, which doesn't allow execution from UNC paths.

I'm hoping someone's done something similar, or has a better idea on how to implement this across the Domain. This Domain currently has 223 computers that will be affected. The server is Windows 2003 and crosses 4 subnets to touch each computer.

Thank you in advance!

If it's worth doing, it's worth doing right.


See More: Copy file from server share to domain comps

Report •


✔ Best Answer
August 6, 2011 at 11:30:28
If I set the target to "C:\folder" will this process work the same?
It's the workstations that run the startup scripts, not the file server. From a script writing standpoint, write it as if you were going to copy it to every workstation, and then run the script locally, because that's what Windows is doing. The script just happens to be on a network share, and it just happens to run from the workstation's System account.

what of the error message above?
You don't care. Network UNC paths do not have a drive name, and CMD's current directory requires one. If you left echo on, you'd see the current directory was %systemroot%. That's all it's telling you, and you don't care because your script doesn't make any assumptions about its current directory.

If you want to see for yourself, make a one line script:

pause

Run it from a network share (and not from a network drive). You'll see the same error, and were it a more complicated script, you'd see it run without issue.

How To Ask Questions The Smart Way



#1
August 2, 2011 at 00:35:35
I've just tried this on my Windows 7 system and have no problem running a batch file from a UNC path that uses robocopy to copy from a UNC path. So I'm not quite sure what your problem is. One thing that you cannot do in cmd.exe is to change the current directory to a UNC path (but there's an obvious workaround for that by mapping to a drive letter).

Perhaps if you list the batch file that you are trying to run the reason may be clearer.


Report •

#2
August 3, 2011 at 00:12:37
Thanks for the help, ijack.
Is yours a Win7 machine having the file written to it by a DC via a GP startup script? That's the exact problem I'm having. Yes, I too can key in the command line directly and copy the file across the network, but that's not the problem. It seems running the startup script from a command box from the server may be the issue?

Here are more details:
1. The batch file (Copy_File.bat) should run from a startup script in GP, which the target computer is a member of.

2. Because the batch file running from the server didn't do it's job (copy the file over,) I attempt to run the file myself on the target computer by viewing it and executing through Windows Explorer.

3. Upon execution of the file from the local computer I receive the following message:

'\\server\share$\folder'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.

C:\WINDOWS>xcopy "\\server\sharedfolder\file.xxx" "\\localcomputername\folder\folder"
Invalid drive specification
0 File(s) copied

* * *
The batch file contains only 1 command line:
xcopy "\\server\sharedfolder\file.xxx" "\\%computername%\folder\folder"
* * *

I've tried changing the format of the command to see if this would affect anything, but it had the same results:
(xcopy "file.xxx" "\\%computername%\folder\folder") <-- file.xxx is in the same folder as the batch file on the server
(xcopy "c:\folder\folder\file.xxx" "\\%computername%\folder\folder") <-- Using a proper path instead of UNC

Does this help?

If it's worth doing, it's worth doing right.


Report •

#3
August 3, 2011 at 04:56:45
Obvious question: Does the local computer have a share called "folder"?

How To Ask Questions The Smart Way


Report •

Related Solutions

#4
August 3, 2011 at 07:08:45
I'm using an ambiguous term. The local computer's folders are not shared.

If it's worth doing, it's worth doing right.


Report •

#5
August 3, 2011 at 07:33:54
Then why didn't you say "C:\folder" instead of "\\localcomputer\folder"?

Check the common security issues; make sure those computer's System accounts have read access to the share, the directories, and the files. I'm not at work and I don't have an AD going, so I can't check to see if "Domain Users" includes computers' accounts or not. Sorry.

How To Ask Questions The Smart Way


Report •

#6
August 6, 2011 at 10:11:13
I said "\\%computername%\folder\folder" as the target so that when the batch file runs from the server the variable %computername% will be replaced by the domain computer starting up and hence the one accessing the batch file. If I set the target to "C:\folder" will this process work the same?

In either method, how do I mitigate the below error message which would seem to come up regardless of target method implemented?

* * *
'\\server\share$\folder'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
* * *

As far as COMPUTERS having permissions for the files and folders in the path, that's a great point. I will check this out on Monday and reply to the thread with the results of that. I'm thinking even if the computers would have the permissions, what of the error message above? It seems the error overall may be with how the command is being executed rather than anything else. I'll post Monday with more info on the Computer permissions testing.

If it's worth doing, it's worth doing right.


Report •

#7
August 6, 2011 at 11:30:28
✔ Best Answer
If I set the target to "C:\folder" will this process work the same?
It's the workstations that run the startup scripts, not the file server. From a script writing standpoint, write it as if you were going to copy it to every workstation, and then run the script locally, because that's what Windows is doing. The script just happens to be on a network share, and it just happens to run from the workstation's System account.

what of the error message above?
You don't care. Network UNC paths do not have a drive name, and CMD's current directory requires one. If you left echo on, you'd see the current directory was %systemroot%. That's all it's telling you, and you don't care because your script doesn't make any assumptions about its current directory.

If you want to see for yourself, make a one line script:

pause

Run it from a network share (and not from a network drive). You'll see the same error, and were it a more complicated script, you'd see it run without issue.

How To Ask Questions The Smart Way


Report •

#8
August 10, 2011 at 01:06:42
OK, I think we've nailed it now.
I did try adding the computer object and allowed the computer to have identical permissions as the domain user, but this made no difference; the file still did not copy over. What made the difference is when you said, "Run it from a network share (and not from a network drive)." I thought since the server was already up and running with mapped drives in place, what difference would this make? If a domain computer were to call the batch file upon startup the UNC path I laid out within the file should work fine (since the mapped drive was only referenced in GP on the server.) Because this can get confusing fast, here's the synopsis of what I did (with your help) that made this work!

Changed the path of the Startup batch file within GP on the server (was previously L:\sharedfolder\batchfile.bat) to (\\server\sharedfolder\batchfile.bat)
* This one little change brought the batch to life on the local machine! *

Note for clarity: I did not change anything within the script itself. The only change that was made was telling GP where to find the Startup script.

Thank you very, very much Razor2.3! You've saved me some needed hair follicles and I can finally move on with this project.

:-)

If it's worth doing, it's worth doing right.


Report •


Ask Question