I am trying to make a scheduled batch file to run with the volume shadow copy service to copy the outlook.pst file from microsoft outlook.
The commands work properly when i enter them in the command panel but when i setup the same code in a batch file it gives me an invalid number of parameters error in during the second line.
You have to use administrator access on cmd and the batch file for it to even work and i am doing that but i have no clue as to why i get an error only in the batch version but not in cmd?
I found this link helpful.
Its where i found the batch file which simplifies the process incase anyone is wondering.
Heres the code :
CALL MountLatestShadowCopy "C:\MyShadow\"
xcopy /y "C:\MyShadow\Users\%USERNAME%\Documents\Outlookove datoteke\*.pst" "\\hyp\backup"
RMDIR "C:\MyShadow"
pause
Anyone have any ideas as to the cause of my problems? Its supposed to simply copy the .pst file to a server for backup which i will run on a regular schedule.
Outlook is usually the first thing people open when they turn on their computers so i have to use volume shadow copy otherwise getting a copy might be hard on certain computers.
Thanks for the help in advance!
I'm trying to automate process of mounting a particular *.vhdx file to Windows Server 2012r2.
When I'm mounting file manualy by GUI everything works just fine. The problem occure when I'm mounting file using Mount-DiskImage Powershell CmdLet. At first glance mounting ends successfuly but when I trying to create a file inside disk V:\ (which is the mounted VHDX in my case) I got an error about lack of permissions. I was thinking that somehow it' caused by wrong owning of folders, files and the disk itself, so I run :
takeown /f V:\ /a /r /d Y
(...to reset all the permissions and grant them to Administrators.)
And what do you think? Yes. It didn't worked out. Then I checked SDDL string of V:\ in both cases of mounting VHDX (manually and with Powershell CmdLet) and it's turned out that they are absolutly the same (O:BAG:DUD:AI(A;ID;FA;;;WD)(A;ID;FA;;;BA)).
I can't find any reason why two of this methods give me different results. And I also can't find any visible difference in any properties of disk V:\ .
Do you have any suggestions? Any ideas would be helpfull!
Thanks in advance for your time guys.
I am using Windows XP Pro with Service Pack 3.
I have a .bat file that tests if various drives are available, and if they are then the bat file writes a little script that another program, an exe file, uses.
The problem is when the bat file issues the command to test if a disk is in the floppy drive, Windows generates an error and a message box. Windows is doing its own testing and pops up a message box, which halts my bat file. I don't want Windows to do the testing.
Here is a short bat file I wrote to demonstrate the problem:
#ECHO OFF
CLS
REM TEST FOR FLASH DRIVE
IF EXIST G:\NUL (
ECHO Flash Drive found
)
REM TEST FOR FLOPPY DISK IN DRIVE
IF EXIST A:\NUL (
ECHO Floppy in Drive
)
How do I test for a floppy without Windows getting in the way?
you can remove the null operator, and have it just try the A: drive. This works for windows 7 so it might work for windows xp. or you can use a power shell command that list all active drives which is
get-psdrive.
Power shell has the ability to run commands like cmd with some more built in features.
I am trying to run a batch file from a network share, but I keep getting the following message: "UNC path are not supported. Defaulting to Windows directory." The batch file is located on \\Server\Soft\WPX5\install.bat. While logged in as administrator, from my Windows 7 Desktop, I navigate to \\Server\Soft\WP15\ and double click on install.bat, that's when I get the "UNC path are not supported." message. I found some suggestions online stating that mapping drive will not work, but using a symbolic link will solve this issue, but the symbolic link didn't work for me. Below is my batch file content, I would appreciate any assistance that can help me accomplish what I am trying to do. Basically, I want to be able to run the batch file from \\Server\Soft\WP15\install.bat.
Batch file content
mklink /d %userprofile%\Desktop\WP15 \\server\soft\WP15
\\server\soft\WP15\setup.exe
robocopy.exe "\\server\soft\WP15\Custom" /copyall "C:\Program Files (x86)\WP\Custom Templates"
Regedit.exe /s \\server\soft\WPX5\Custom\Migrate.reg
Also, how do I remove the symbolic link after the install is completed?
PUSHD and POPD should help in your case.
#echo off
:: Create a temporary drive letter mapped to your UNC root location
:: and effectively CD to that location
pushd \\server\soft
:: Do your work
WP15\setup.exe
robocopy.exe "WP15\Custom" /copyall "C:\Program Files (x86)\WP\Custom Templates"
Regedit.exe /s WPX5\Custom\Migrate.reg
:: Remove the temporary drive letter and return to your original location
popd
Type PUSHD /? from the command line for more information.
I feel cls is the best answer. It hides the UNC message before anyone can see it. I combined it with a #pushd %~dp0 right after so that it would seem like opening the script and map the location in one step, thus preventing further UNC issues.
cls
#pushd %~dp0
:::::::::::::::::::
:: your script code here
:::::::::::::::::::
#popd
Notes:
pushd will change your working directory to the scripts location in the new mapped drive.
popd at the end, to clean up the mapped drive.
There's a registry setting to avoid this security check (use it at your own risks, though):
Under the registry path
HKEY_CURRENT_USER
\Software
\Microsoft
\Command Processor
add the value DisableUNCCheck REG_DWORD and set the value to 0 x 1
(Hex).
Note:
On Windows 10 version 1803, the setting seems to be located under HKLM:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
Basically, you can't run it from a UNC path without seeing that message.
What I usually do is just put a CLS at the top of the script so I don't have to see that message. Then, specify the full path to files in the network share that you need to use.
I needed to be able to just Windows Explorer browse through the server share, then double-click launch the batch file. #dbenham led me to an easier solution for my scenario (without the popd worries):
:: Capture UNC or mapped-drive path script was launched from
set NetPath=%~dp0
:: Assumes that setup.exe is in the same UNC path
%NetPath%setup.exe
:: Note that NetPath has a trailing backslash ("\")
robocopy.exe "%NetPath%Custom" /copyall "C:\Program Files (x86)\WP\Custom Templates"
Regedit.exe /s %NetPath%..\WPX5\Custom\Migrate.reg
:: I am not sure if WPX5 was typo, so use ".." for parent directory
set NetPath=
pause
Instead of launching the batch directly from explorer - create a shortcut to the batch and set the starting directory in the properties of the shortcut to a local path like %TEMP% or something.
To delete the symbolic link, use the rmdir command.
I ran into the same issue recently working with a batch file on a network share drive in Windows 7.
Another way that worked for me was to map the server to a drive through Windows Explorer: Tools -> Map network drive. Give it a drive letter and folder path to \yourserver. Since I work with the network share often mapping to it makes it more convenient, and it resolved the “UNC path are not supported” error.
My situation is just a little different. I'm running a batch file on startup to distribute the latest version of internal business applications.
In this situation I'm using the Windows Registry Run Key with the following string
cmd /c copy \\serverName\SharedFolder\startup7.bat %USERPROFILE% & %USERPROFILE%\startup7.bat
This runs two commands on startup in the correct sequence. First copying the batch file locally to a directory the user has permission to. Then executing the same batch file. I can create a local directory c:\InternalApps and copy all of the files from the network.
This is probably too late to solve the original poster's question but it may help someone else.
This is the RegKey I used:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
"DisableUNCCheck"=dword:00000001
My env windows10 2019 lts version and I add this two binray data ,fix this error
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor DisableUNCCheck value 1
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Command Processor
DisableUNCCheck value 1
This is a very old thread, but I still use Windows 7. :-)
There is one point that no one seems to have taken into account, which probably would help Windows 10 users also.
If Command Extensions are enabled, the PUSHD command accepts network paths in addition to the normal drive letter and path.
So the obvious - and simplest - answer might be to enable command extensions in the batch script, if you intend to use PUSHD. At the very least, this ought to reduce the problems you might have in using PUSHD wqith a network path.
I stumbled upon this question while searching for a solution to a specific problem. I needed to make a batch script that sits in a network folder (UNC path) with a Python script. The goal was to be able to double click on the batch script and have it run the Python script:
with the network folder containing the script as the working directory,
without modifications to the Python script (no command line parameters or hard-coded paths).
without creating another Python file.
The pushd and popd solutions were unsatisfactory. They work, but if the user were to get in the habit of forcefully terminating the script while it was running, they would end up with a bunch of mapped drives in My Computer since popd wasn't run.
I start by using cls to clear the UNC path error. I then assign the path containing the batch script to a variable. I slice the path to remove the trailing backslash (otherwise, Python throws a SyntaxError). Finally, I run a couple Python commands inside the batch file that change the working directory and execute the target script:
cls
#echo off
set pyfile=myscript.py
set batchdir=%~dp0
set wdir=%batchdir:~0,-1%
python -c "import os; import runpy; os.chdir(r""%wdir%""); runpy.run_path(r""%pyfile%"")"
pause
Editing Windows registries is not worth it and not safe, use Map network drive and load the network share as if it's loaded from one of your local drives.
I am having a problem copying large DB files (~100GB) in an automated script I am trying to write for a Windows Server. I have tried using "copy", "robocopy", and even "eseutil".
My script is running on a Windows 2008 Server (destination of the file) and is pulling from a Windows 2003 Server (source of the file).
I have already tried changing the IRPStackSize registry setting, as well as both of the ones in the HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement hive. This was all done on the 2008 server and rebooted with no effect. Does anyone have a good workaround?
Copy and Robocopy both give me this:
Not enough server storage is available to process this command.
Eseutil.exe gives me this:
H:\TempSQLBackups>eseutil /y \\SRC_SERVER\SQL_BACKUPS\BIG_DB.BAK /d H:\TempSQLBackups\BIG_DB.bak
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating COPY FILE mode...
Source File: \\SRC_SERVER\SQL_BACKUPS\BIG_DB.BAK
Destination File: H:\TempSQLBackups\BIG_DB.bak
Copy Progress (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
........FAILURE: ReadFile: The specified network name is no longer available.
Operation terminated unsuccessfully after 11336.16 seconds.
H:\TempSQLBackups>
I figured out how to fix this!
Use a LINUX machine to samba mount the source and destination directories/drives and copy them via the network. Personally, I use rsync since it will recreate the directory structure and only copy files that aren't there or are different. Thus, you can stop and/or restart at anytime without losing your progress.
I can't believe we're still paying Microsoft for this trash of an OS. I had similar problems and there seems to be no fix other than this one. Its a little slow but not nearly as slow as doing on natively since it will fail EVERY TIME.
At one point I thought robocopy would surely do it using the /IPG:xx option (InterPacketGap in milliseconds). Nope. It just PROLONGS the stack overflow and remote console lockout. I thought, maybe, Microsoft got it right with this OS. So much for Win2K8 being solid. Ugh! Windoze is for workstations. For servers you need a server OS not tinkertoy code.
Use the XCOPY with the /J option to avoid network failures of large files. This will ONLY works in 2008 R2 and Windows 7 though. This solved my timeout issue.
Please check.
Have you tried to copy the files with the old fasion way of drag and drop?
I would do this once, to make sure its not your network failing. Make sure that works, and then try look at other solutions.
1) Make sure your destination drive, is NTFS and NOT Fat32.
2) Check when its failing to copy, is it always at the same point? ( IE if it always failing after 2gb )
Have you tried xcopy? It works better for large files and recursive copy. doc
Also, from my own experience working with network drives and command line is a pain and buggy. It is also a good idea to map the network drive and use drive letter such as z:\
xcopy /K /R /E /I /S /C /H /G /X /Y s:\*.* t:\
/K Copies attributes. Normal Xcopy will reset read-only attributes.
/R Overwrites read-only files.
/E Copies directories and subdirectories, including empty ones.
/I If destination does not exist and copying more than one file, assumes that destination must be a directory.
/S Copies directories and subdirectories except empty ones.
/C Continues copying even if errors occur.
/H Copies hidden and system files also.
/Y Suppresses prompting to confirm you want to overwrite an existing destination file.
/G Allows the copying of encrypted files to destination that does not support encryption.
/X Copies file audit settings (implies /O).
The format for the second part of eseutil should be:
/d\\server\folder\filename
Notice there is no space after the /d