D
David Trimboli
I make heavy use of the Elevation Powertoys that have been published on
the Web. Shortcuts on the network leading to installers elsewhere on the
network begin with Elevate.cmd. This works fine for .exe and .msi files,
but it doesn't work with cmd or vbs scripts. Specifically, if your
administrator account doesn't already have access to the server, the
scripts will fail because they cannot access the network location once
they are elevated.
Let me give a simple example. I have \\server\software\shortcut.lnk,
which points to: "\\server\tools\elevate.cmd \\server\apps$\install.exe"
(without the quotation marks). When I run the shortcut in Vista or 7, I
am prompted by User Account Control (and if I am already an
administrator, I am not prompted for a different account to use). The
executable will install correctly. If the elevated executable needs
network access, I am prompted to provide it.
However, if I have another shortcut \\server\software\othershortcut.lnk
that points to "\\server\tools\elevate.cmd cmd /c
\\server\apps$\script.cmd", the elevate script will run, UAC will
prompt, but then cmd will fail to find the script, because it doesn't
have network access under the elevated user account. You can't even
elevate the othershortcut.lnk, because elevate.cmd generates its own
token without network access. The only way you can possibly run the
script is to elevate a Command Prompt, then type the path to the script.
Since my purpose is to maintain a repository of software for my colleges
that is easy to use without worrying about elevation or scripting, I
don't want to rely on them to remember to elevate a Command Prompt and
type the path to the script. But I haven't been able to come up with a
way to get the script to run.
To summarize: I want the technician to go to the network share in
Windows Explorer, double-click on \\server\software\othershortcut.lnk,
which prompts with UAC, then runs \\server\apps$\script.cmd. The
Elevation Powertoys don't seem to be able to do it. Any suggestions?
the Web. Shortcuts on the network leading to installers elsewhere on the
network begin with Elevate.cmd. This works fine for .exe and .msi files,
but it doesn't work with cmd or vbs scripts. Specifically, if your
administrator account doesn't already have access to the server, the
scripts will fail because they cannot access the network location once
they are elevated.
Let me give a simple example. I have \\server\software\shortcut.lnk,
which points to: "\\server\tools\elevate.cmd \\server\apps$\install.exe"
(without the quotation marks). When I run the shortcut in Vista or 7, I
am prompted by User Account Control (and if I am already an
administrator, I am not prompted for a different account to use). The
executable will install correctly. If the elevated executable needs
network access, I am prompted to provide it.
However, if I have another shortcut \\server\software\othershortcut.lnk
that points to "\\server\tools\elevate.cmd cmd /c
\\server\apps$\script.cmd", the elevate script will run, UAC will
prompt, but then cmd will fail to find the script, because it doesn't
have network access under the elevated user account. You can't even
elevate the othershortcut.lnk, because elevate.cmd generates its own
token without network access. The only way you can possibly run the
script is to elevate a Command Prompt, then type the path to the script.
Since my purpose is to maintain a repository of software for my colleges
that is easy to use without worrying about elevation or scripting, I
don't want to rely on them to remember to elevate a Command Prompt and
type the path to the script. But I haven't been able to come up with a
way to get the script to run.
To summarize: I want the technician to go to the network share in
Windows Explorer, double-click on \\server\software\othershortcut.lnk,
which prompts with UAC, then runs \\server\apps$\script.cmd. The
Elevation Powertoys don't seem to be able to do it. Any suggestions?