Jump to content

RunAsSet question


Recommended Posts

What are the limitations of RunAsSet? If I deploy a software install that will run under a user with no rights how does RunAsSet handle it?

Example

RunAsSet( "administrator", "blah.com", "Insertpasswordhere")
RunWait( "\\SomeServer\somefolder$\SomeFolder\SilentInstall.bat")
Sleep(10000)
RunWait( "\\SomeServer\somefolder$\SomeFolder\Configuration.bat")
RunAsSet()

The script above functions if I am logged on as an admin. I have checked to see if the user has access to the folders listed and they do, but I cannot get the script to run. I am very new to all of this so any advice would be appreciated.

Edited by Anaxibius
Link to comment
Share on other sites

put the option in runasset to don't load user proflie option"1"

when you use this option the software if running under the current userlogon but set privilege of the admin!

by default it run a process under the admin profile and don't make ant change under the current user profile!

i hope you understand me! bye bye

tell me please if this solve your probleme!

GreenseedMCSE+I, CCNA, A+Canada, QuebecMake Love Around You.

Link to comment
Share on other sites

put the option in runasset to don't load user proflie option"1"

when you use this option the software if running under the current userlogon but set privilege of the admin!

by default it run a process under the admin profile and don't make ant change under the current user profile!

i hope you understand me! bye bye

tell me please if this solve your probleme!

I made the change you suggested but it did not resolve the problem. I have no doubt that this is a permissions issue, but the problem is on the local machine. I can execute the script, but the RunAsSet does not appear to be modifying the privledges. Any other ideas?

Edited by Anaxibius
Link to comment
Share on other sites

I made the change you suggested but it did not resolve the problem. I have no doubt that this is a permissions issue, but the problem is on the local machine. I can execute the script, but the RunAsSet does not appear to be modifying the privledges. Any other ideas?

I think that your problem has to do with using hidden shares. If you search the forum you will find similar problems in the past.


Time you enjoyed wasting is not wasted time ......T.S. Elliot
Suspense is worse than disappointment................Robert Burns
God help the man who won't help himself, because no-one else will...........My Grandmother

Link to comment
Share on other sites

I think that your problem has to do with using hidden shares. If you search the forum you will find similar problems in the past.

Thanks. I am not sure what really fixed this, but I changed it to look like a script I found using your advice. This is the final script that works.

AutoItSetOption("RunErrorsFatal", 0) 
AutoItSetOption("TrayIconHide", 1) 


Break(0)
$USERNAME = "administrator"
$PASSWORD = "secret"
$DOMAIN = "domain.com"
$RUN = 0     ; run indicator 
; retrieve the cycle from commandline
If $CMDLINE[0] = 1 Then $RUN = $CMDLINE[1]
If $RUN = 0 Then
   RunAsSet($USERNAME, $DOMAIN, $PASSWORD)
   Run('"' & @ScriptFullPath & '" " 1"') 
   If @error Then MsgBox(4096+32,"Error", "Error starting under admin mode")
   Exit
EndIf
; commands go here that require Administrator rights

RunWait( "\\server\share$\Appfolder\SilentInstall.bat")
Sleep(10000)
RunWait( "\\server\share$\Appfolder\Configuration.bat")
RunAsSet()

This did the trick. Wish I knew why, but hey I won't complain :P

Link to comment
Share on other sites

Ok, I figured out what was happening, but I haven't fixed the issue yet. What is happening is that an .ini file is being modified, but it is modifying the .ini under the Administrators profile. I have tried using the 0 and 1 at the end of the RunAsSet command. I have two ways of fixing this. I can figure out how to make RunAsSet do what I want or I can manually copy the .ini file to the correct location. If I go with the second option I need to know how to fill a variable with the currently logged on user. How do I do that? Or how do I get RunAsSet to modyfy the correct profile?

Link to comment
Share on other sites

Ok, I figured out what was happening, but I haven't fixed the issue yet. What is happening is that an .ini file is being modified, but it is modifying the .ini under the Administrators profile. I have tried using the 0 and 1 at the end of the RunAsSet command. I have two ways of fixing this. I can figure out how to make RunAsSet do what I want or I can manually copy the .ini file to the correct location. If I go with the second option I need to know how to fill a variable with the currently logged on user. How do I do that? Or how do I get RunAsSet to modyfy the correct profile?

I am not sure exactly what you want but @UserProfileDir will return the path to the logged on users profile folder. If you set this as a variable before you use RunAsSet then you can use it to find the profile folder.


Time you enjoyed wasting is not wasted time ......T.S. Elliot
Suspense is worse than disappointment................Robert Burns
God help the man who won't help himself, because no-one else will...........My Grandmother

Link to comment
Share on other sites

I am not sure exactly what you want but @UserProfileDir will return the path to the logged on users profile folder. If you set this as a variable before you use RunAsSet then you can use it to find the profile folder.

Thanks for the advice. I tried what you mentioned, but the problem is that when I copy the .ini files it has to be after the RunAsSet, because the folders and files do not exist prior to the installation. So what is happening is that I define the variable using the @UserProfileDir or @UserName prior to the RunAsSet, but as soon as RunAsSet initiates it changes the variable. I tested this by displaying a MsgBox with the variable name. If I put it prior to the RunAsSet it will actually display twice. Once with the User the script is running under and once as the administrator. If I place the MsgBox at the end it will simply display the Admin user name or directory.

AutoItSetOption("RunErrorsFatal", 0) 
AutoItSetOption("TrayIconHide", 1) 


Break(0)
$CONFIGLOC = @UserProfileDir
$USERNAME = "administrator"
$PASSWORD = "secret"
$DOMAIN = "domain.com"
$RUN = 0     ; run indicator 
; retrieve the cycle from commandline
If $CMDLINE[0] = 1 Then $RUN = $CMDLINE[1]
If $RUN = 0 Then
   RunAsSet($USERNAME, $DOMAIN, $PASSWORD, 0)
   Run('"' & @ScriptFullPath & '" " 1"') 
   If @error Then MsgBox(4096+32,"Error", "Error starting under admin mode")
   Exit
EndIf
; commands go here that require Administrator rights

RunWait( "\\server\share$\AppFolder\SilentInstall.bat")
RunWait( "\\server\share$\AppFolder\Configuration.bat")
FileCopy("\\server\share$\AppFolder\LinkOne.ini", $CONFIGLOC & "\Application Data\Mincom\LinkOne\WinView", 1)
FileCopy("\\server\share$\AppFolder\LinkOne_ui.ini", $CONFIGLOC & "\Application Data\Mincom\LinkOne\WinView", 1)
MsgBox(0, "Test" , $CONFIGLOC, 10)
RunAsSet()
Edited by Anaxibius
Link to comment
Share on other sites

Thanks for the advice. I tried what you mentioned, but the problem is that when I copy the .ini files it has to be after the RunAsSet, because the folders and files do not exist prior to the installation. So what is happening is that I define the variable using the @UserProfileDir or @UserName prior to the RunAsSet, but as soon as RunAsSet initiates it changes the variable. I tested this by displaying a MsgBox with the variable name. If I put it prior to the RunAsSet it will actually display twice. Once with the User the script is running under and once as the administrator. If I place the MsgBox at the end it will simply display the Admin user name or directory.

AutoItSetOption("RunErrorsFatal", 0) 
AutoItSetOption("TrayIconHide", 1) 
Break(0)
$CONFIGLOC = @UserProfileDir
$USERNAME = "administrator"
$PASSWORD = "secret"
$DOMAIN = "domain.com"
$RUN = 0    ; run indicator 
; retrieve the cycle from commandline
If $CMDLINE[0] = 1 Then $RUN = $CMDLINE[1]
If $RUN = 0 Then
   RunAsSet($USERNAME, $DOMAIN, $PASSWORD, 0)
   Run('"' & @ScriptFullPath & '" " 1"') 
   If @error Then MsgBox(4096+32,"Error", "Error starting under admin mode")
   Exit
EndIf
; commands go here that require Administrator rights

RunWait( "\\server\share$\AppFolder\SilentInstall.bat")
RunWait( "\\server\share$\AppFolder\Configuration.bat")
FileCopy("\\server\share$\AppFolder\LinkOne.ini", $CONFIGLOC & "\Application Data\Mincom\LinkOne\WinView", 1)
FileCopy("\\server\share$\AppFolder\LinkOne_ui.ini", $CONFIGLOC & "\Application Data\Mincom\LinkOne\WinView", 1)
MsgBox(0, "Test" , $CONFIGLOC, 10)
RunAsSet()
Do you need Administer rights to copy the files. If not you could move the RunAsSet() up to before the copying.


Time you enjoyed wasting is not wasted time ......T.S. Elliot
Suspense is worse than disappointment................Robert Burns
God help the man who won't help himself, because no-one else will...........My Grandmother

Link to comment
Share on other sites

Do you need Administer rights to copy the files. If not you could move the RunAsSet() up to before the copying.

I don't need admin rights to copy the files, but the folders do not exist prior to the installation under RunAsSet. Oh...wait nm. I see what you are saying. Edited by Anaxibius
Link to comment
Share on other sites

Ok...new code.

AutoItSetOption("RunErrorsFatal", 0) 
AutoItSetOption("TrayIconHide", 1) 


Break(0)
$USERNAME = "administrator"
$PASSWORD = "secret"
$DOMAIN = "domain.com"
$RUN = 0     ; run indicator 
; retrieve the cycle from commandline
If $CMDLINE[0] = 1 Then $RUN = $CMDLINE[1]
If $RUN = 0 Then
   RunAsSet($USERNAME, $DOMAIN, $PASSWORD, 0)
   Run('"' & @ScriptFullPath & '" " 1"') 
   If @error Then MsgBox(4096+32,"Error", "Error starting under admin mode")
   Exit
EndIf
; commands go here that require Administrator rights

RunWait( "\\server\share$\AppFolder\SilentInstall.bat")
RunWait( "\\server\share$\AppFolder\Configuration.bat")
RunAsSet()
$CONFIGLOC = @UserProfileDir
MsgBox(0, "Test" , $CONFIGLOC, 10)
FileCopy("\\server\share$\AppFolder\LinkOne.ini", $CONFIGLOC & "\Application Data\Mincom\LinkOne\WinView", 1)
FileCopy("\\server\share$\AppFolder\LinkOne_ui.ini", $CONFIGLOC & "\Application Data\Mincom\LinkOne\WinView", 1)
Exit

If I use RunAsSet with a 0 when the MsgBox pops up it displays the path c:\Documents and Settings\Administrator when I use 1 it displays c:\Documents and Settings\Default User. I need it to show the currently logged on user. The only way I can get it to even display the currently logged on user is to put the MsgBox prior to the RunAsSet initialization. Any time after that it is hosed and since I need the folders to be created first the copy has to be after.

Link to comment
Share on other sites

BigDod and others:

I found this thread http://www.autoitscript.com/forum/index.ph...65entry119865 that starts out having the exact same problem I am having. Unfortunately I will need the @UserName or @UserProfileDir to list the current logged on user and I don't think that was ever actually solved in the thread I list.

Perhaps I am missing something if I look at the help file it says "[optional] 0 = do not load the user profile, 1 = (default) load the user profile, 2 = use for net credentials only" to me that means that when I use RunAsSet with a ) option that when I use the @UserName it should report CurrentlyLoggedOnUser not Administrator or Default. All help is greatly appreciated.

Link to comment
Share on other sites

Thanks for the sugesstions all. I thought I would bump this post up to the top with my solution. I seacrhed and read until my eyes hurt, but I pieced together what I needed. Long story short I simply had to have all of the RunAsSet commands run in a seperate script. So basically I just created everything I needed and looked at what needed to be run under admin rights and put those ina seperate script which I called from my primary script. Worked flawlessly. Thanks.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...