[BUG] XCOPY can fail with `\\` locations, causing update.bat to loop
FauxPrada opened this issue · comments
Description
Depending on the client environment, XCOPY can soft error when trying to copy from a network location using \\ and this causes the update.bat batch script to run in a loop until manually stopped. Directly replacing "XCOPY" with "COPY" solves this issue.
To Reproduce
This only happens on one of our Windows 10 networks whereas another of them is absolutely fine with XCOPY. Perhaps it's an environment nuance with our our EUD policies, but other people might be in a similar position in future.
- Run XCOPY with any \\ path source
- Output shows no files available to copy, or file not found
Environment
- Win10 1909 EUDs
- update.bat ver 0.3 #68
- Sysmon stuff hosted at \\%FQDN%\SYSVOL\%FQDN%\Sysmon\
Fix
Find and replace "XCOPY" to "COPY". Don't know of any ill affects from doing this, but personally can't be certain. ::)
Looking at update.bat I can see that xcopy is only used to copy a single file at a time so I cannot see a benefit of xcopy over copy. Both support the suppression of the confirmation prompt to automatically overwrite files.
It's worth noting that robocopy has superceded xcopy, the latter considered deprecated in Windows 10.
How would people feel about update.bat checking for the presence of robocopy and using it if found. Otherwise use copy? (Equally robocopy may be overdoing it, as copy doesn't seem to be going anywhere soon.)
Is there a tageable benefit for using robocopy over copy in this scenario? I see it has a few nice features to possibly make use of such as network compression, though not all versions of robo have that and may fail.
Either option is a benefit over xcopy as long as the robocopy check and useage is robust enough (pun intended). I can test any changes on our systems as we have a few different versions of robocopy available on our EUDs.
Anybody else having any issues with SYSMON role out, it caused a lot of our machines to lockup and crash, some were ok, but a lot crashed, we had to remove the install of sysmon - it also asked for a reboot, this was with setting this up the NCSC provided way, currenlty we have no sysmon GPO 👯
I have seen the same issue using GPO deployment where some machines locked up and then crashed, I am guessing its related to "xcopy" too as it worked on other machines with the same GPO. I see on the official documentation that "xcopy" has error checking like below:
xcopy %1 %2 /s /e
if errorlevel 4 goto lowmemory
if errorlevel 2 goto abort
if errorlevel 0 goto exit
@joncojonathan , can this be utilized?