Command Prompt as Admin (Elevated)

Phil Pendlebury · Post by **Phil Pendlebury** » Sat Oct 27, 2012 5:26 pm

Hi there,

I have a few scripts that do file copying and over the years I have modified them to use cmd, as it seems to work best in different OSs.

I am now in Win 8 and finding that the copying is not working again.

Creating folder is OK but files are not being copied. If I manually try to copy a file I get the messages from Win 8 trying to "make sure I am OK with it" and I presume this is part of the problem.

There are probably tweaks I can make to my setup but this script will run on others' machines too and I don't want o ask them to change their setup.

Has anyone come across this?

Is it possible to start a cmd.exe elevated suing MSched?

Is there anything else I may have missed.

The script creates folders in a the "program files" folder and that part works fine
But copying files from another folder into the folder I have created just does nothing.

All very odd.

Me_again · Post by **Me_again** » Sat Oct 27, 2012 9:38 pm

Have you tried setting RP_ADMIN?

Phil Pendlebury · Post by **Phil Pendlebury** » Sat Oct 27, 2012 11:17 pm

Me_again wrote:Have you tried setting RP_ADMIN?

Yes it is always there at the beginning of all the scripts I write.

Djek · Post by **Djek** » Sat Oct 27, 2012 11:43 pm

hey Phil,

i noticed that starting a CMD in server enviorments needed de /C with it,
for example:

run>cmd /c net use \\srvr\ipc$ /user:domain\user password

maybe this helps with windows8 ?
Ik do not have a windows 8 so i couldnt test is.
kind regars,
Djek

Phil Pendlebury · Post by **Phil Pendlebury** » Sun Oct 28, 2012 6:42 am

Hi there,

Yes I already have the /c switch on too.

Post by **Marcus Tettmar** » Tue Oct 30, 2012 9:19 am

Hi Phil,

Can you post an example of the code you are using?

You can start an elevated command prompt with RP_ADMIN but then you won't be able to send keystrokes to it unless Macro Scheduler is also running as admin. An ordinary process is not allowed to interact with (e.g. send keystrokes to) an admin process. But this is nothing new - same deal with Vista and Win 7.

But sounds like you're just doing a file copy rather than sending keystrokes. If you can send me code showing what you are doing I can try it here and find out. I'm still learning about the differences in Windows 8 myself!

Phil Pendlebury · Post by **Phil Pendlebury** » Tue Oct 30, 2012 9:36 am

Hi Marcus,

I think one of the problems is that the area I am working is in the Program files folder.

I have done tons of research on this - And it seems to be very well protected (which is fair enough).

I also tried automating creation of an elevated command prompt but as you say no commands.

The script is actually a very popular free utility that takes a list of specific (about 70) files in a folder (c:/program files/VSTPlugins), copies them, backs them up, then splits them into sub folders in a new folder - sub folder are depending on an ini file.

It works for some but some end up with empty folders. the odd thing is that the folders get created but the files don't get put there.

Anyway what I have done is:

Added a small test to the script that tries to copy a file to the folder and checks if it is there or not. If it has failed then the script will suggest creating the folder hierarchy locally at c:/users/downloads/etc and copying the finished result manually.

Code: Select all

WriteLn>%newplugindir%\test.txt,rrr,Test file to see if we have permission to write
Wait>1
IfFileExists>%newplugindir%\test.txt
  Wait>1
  DeleteFile>%newplugindir%\test.txt
ELSE
  MDL>Insufficient permission to copy to folder:%CRLF%%newplugindir%%CRLF%%CRLF%Please change your New Plugins Folder to a local folder%CRLF%(e.g. C:\Users\Phil\Downloads\UAD Powered Plugins)%CRLF%%CRLF%You can then manually nove the newly created folder and remove the original Powered Plugins folder when the operation is complete%CRLF%%CRLF%Alternatively you can change the security permissions for your VST Plugins folder so that UAD Mover can operate automatically. Details about how to do this are in the UAD Mover manual.
  RDA>UADMover
  GOTO>begin
ENDIF

I also added a section in the manual that explains how to change permission on the folder so that the script will work automatically if required.

the commands I am using are here but they may not make too much sense without the context of the script:

Creates the folder

Code: Select all

IfDirExists>%newplugindir%\%location%
        GOTO>Do_Copy
      ELSE
        Run>cmd.exe /c mkdir "%newplugindir%\%location%"
        // CreateDir>%newplugindir%\%location%
        Wait>0.5
      ENDIF
      Label>Do_Copy

Copies the file (includes commented out old method that also failed on many systems):

Code: Select all

 // CopyFile>%DESKTOP_DIR%\Working\%plugin_dll%,%newplugindir%\%location%\%plugin_dll%
      Run>cmd.exe /c copy "%DESKTOP_DIR%\Working\%plugin_dll%" "%newplugindir%\%location%\%plugin_dll%"

So there you go.

If you want to see more please let me know - But don;t spend too much time on this unless you think it may be important to you and other users.

I think the key here is that really we shouldn't be allowed to manipulate files in the "program files" folder but in this case, that is where the files are installed.

Post by **Marcus Tettmar** » Tue Oct 30, 2012 9:39 am

I also tried automating creation of an elevated command prompt but as you say no commands.

You will need to run Macro Scheduler as admin to do this.

In fact to do ANYTHING in program files folders Macro Scheduler must be run as admin.

Have you tried running Macro Scheduler as admin?

Phil Pendlebury · Post by **Phil Pendlebury** » Tue Oct 30, 2012 9:44 am

Sorry Marcus I meant by hitting CTRL+SHIFT+ENTER after typing cmd.

My script is an exe file which includes RP_ADMIN set so I presumed that it was not required to do more.

Maybe I should try setting the exe file to run as admin in the exe properties itself?

I'll give that a go and post back.

Phil Pendlebury · Post by **Phil Pendlebury** » Tue Oct 30, 2012 9:55 am

Nope running the exe as admin does not help. (either by right clicking and selecting run as admin or by setting run as admin in properties).

Also running MSched as admin does not help the initial file copy test still fails.

At least there is a nice simple test already made for you, if you do want to look into this any further:

EDIT: Discovered some more anomalies will post back shortly just testing.

Post by **Marcus Tettmar** » Tue Oct 30, 2012 9:56 am

Here's the deal:

An ordinary process (a process run as a standard user) can NOT interact with or exchange information with an admin process.

Ergo, an ordinary process cannot send keystrokes into an admin process.

Ergo, Macro Scheduler, if run as an ordinary process, i.e. run un-elevated under a standard user (the default arrangement) can NOT automate an admin process.

This has been the case since Vista. If it were possible for an ordinary process to send keystrokes into an admin process then Microsoft's entire security policy would be worthless.

Soooo - in order for Macro Scheduler to control an admin process IT MUST be run as Admin.

What RP_ADMIN=1 does is run the thing you are running with the Run command as admin. It does not alter Macro Scheduler's status. Macro Scheduler is still running at the lower use level with lower privileges.

Short answer: If you need to send keystrokes to a window running as admin Macro Scheduler also needs to be running as admin.

And by the same token to do anything that requires admin privileges (like copy files to System32 or program files - Macro Scheduler needs to be running as admin).

Phil Pendlebury · Post by **Phil Pendlebury** » Tue Oct 30, 2012 10:08 am

Of course Marcus, you are absolutely right and what is so stupid is I knew most of that.

What I didn't realise was that RP_ADMIN set doesn't make a script run as admin (which is actually totally obvious - how could a command from an already running app suddenly raise its privileges).

Also I had made a mistake in the path that was being checked (it was sometimes trying to write to a non-existent folder)

I have now selected run as admin on a newly created exe file and it works.

Thank you for your persistence. And this will be good reference for anyone who is confused by this I guess.

PS. Here's a nice simple test for anyone who may need it:

Code: Select all

Let>path=C:\Program Files

WriteLn>%path%\test.txt,rrr,Test file to see if we have permission to write
Wait>1
IfFileExists>%path%\test.txt
  MDL>Write Succeeded
  DeleteFile>%path%\test.txt
ELSE
  MDL>Write Failed - Try setting run as admin.
ENDIF