We have a cmd script on a server which we access through a UNC path like \\machine\some_path\x.cmd. (Specifically, it is a wrapper around a customized cygwin installation with the goal to have identical installations on all clients. The installation destination needs admin rights.)

It has worked as intended for a number of users, but today several attempts on one machine failed (even though the prerequisites, like the destination folder, exist). This was during a remote session, which I cannot immediately replicate, which is why I'm asking here: Only after the fact did we realize that we probably started it differently than the other users.

Procedure 1: Open a console as administrator and execute \\machine\some_path\x.cmd. This has worked in the past.

Procedure 1: Open an explorer, change to \\machine\some_path, and right-click x.cmd. Choose "Run as administrator". A console opens, the installation starts, and then fails with failures to create files.

The errors could obviously be permission issues, but I would find that surprising: I started the "root process" as administrator and would expect child processes to inherit the privilege. Is that not so?

  • Are both procedures done from the same computer and by the same user, one successful and the other not?
    – harrymc
    Aug 6, 2020 at 15:35
  • @harrymc No, and I cannot try it now. I thought maybe it's a well-known fact "yes, of course, everybody knows that the right-click only elevates the immediate process" or something. But the machines are fairly similar (in fact, they are some near-identical virtual machines somewhere). Aug 6, 2020 at 15:36
  • The difference must be in the network. All "Run as administrator" processes run with the same permissions no matter the method of elevation, but an admin on one computer isn't automatically also admin on another.
    – harrymc
    Aug 6, 2020 at 15:39

1 Answer 1


Yes, there is a difference, but the difference is really tiny.

When you type in the script name from a cmd run as Administrator, the cmd window will remain active once the script finishes, whereas when you right-click a script and choose run as admin, a new cmd as admin is started, the script is executed, and at the end of the script, the cmd window is closed.

For the rest, everything is the same.

Because the cmd window is open before the script starts, every change to that cmd window prior to executing the script, such as making network connections, setting environmental variables, etc... will of course be available to the script. But if you first start a cmd window as admin, and directly after that run your script, the first paragraph of this answer is entirely what happens.

There is one additional thing here that is in play. When you start a cmd file from a UNC path, the cmd window will state that it does not support starting files from a UNC path and defaults to c:\windows\system32 and attempts to run the script from there. This may cause the behavior of not being able to find files etc.

The reason is that cmd cannot START on a UNC path, but it can start programs after it started by temporarily creating a network drive (PUSHD and POPD commands are used but not shown to the user)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.