Recommended Posts
@/dev/null
The windows accounts are just that windows accounts and do not have anything to do with the Novell Zenworks account I am using to login to the network.
@DaveF
We are using Zenworks but this application and others will not repackage correctly for a push, this is why I'm trying this method. The users we will be pushing this out to do not have local admin right but their novell login does have access to the network share.
Using RunAsSet fails everytime regardless of the local account access rights, even using a local account with the same username and password as a novell account with access to the share. (ex. Initial login with local admin rights and novell rights to share. run script with RunAsSet( "same user name", @Computername, "same password") (same account as initial login) the script throws the error.
note: I'm not a network admin and have very little interaction with or knowledge of novell / zenworks administration.
Edited by Ramona
As far as I know, RunAsSet works with Windows shares only so you won't be able to use it with Netware volumes even if you specify them as UNC paths.@/dev/null
The windows accounts are just that windows accounts and do not have anything to do with the Novell Zenworks account I am using to login to the network.
@DaveF
We are using Zenworks but this application and others will not repackage correctly for a push, this is why I'm trying this method. The users we will be pushing this out to do not have local admin right but their novell login does have access to the network share.
Using RunAsSet fails everytime regardless of the local account access rights, even using a local account with the same username and password as a novell account with access to the share.
note: I'm not a network admin and have very little interaction with or knowledge of novell / zenworks administration.
<{POST_SNAPBACK}>
As has been suggested, the way I get round this problem is to FileInstall or copy setup files to the user's local temp directory and run setup from there. RunAsSet should work with local files using a local admin account.
Edited by SumTingWongThanks, I was leaning toward that.As far as I know, RunAsSet works with Windows shares only so you won't be able to use it with Netware shares even if you specify them as UNC paths.
As has been suggested, the way I get round this problem is to FileInstall setup files to the user's local temp directory and run setup from there. RunAsSet should work with local files using a local admin account.
<{POST_SNAPBACK}>
@/dev/null
The windows accounts are just that windows accounts and do not have anything to do with the Novell Zenworks account I am using to login to the network.
and that's exactly the problem 
Cheers
Kurt
__________________________________________________________(l)user: Hey admin slave, how can I recover my deleted files?admin: No problem, there is a nice tool. It's called rm, like recovery method. Make sure to call it with the "recover fast" option like this: rm -rf *
Does not work
;created this b/c RunWait threw errors with the @xxx macros $path = @HomeDrive &"\PrimoPDF" ;copy files local DirCopy ( "\\Kc3\apps\Utilities\PrimoPDF", $path, 1 ) ;change credentials; used same as initial login for testing purposes RunAsSet( "khelp", @Computername, "*****" ) RunWait( $path &"\PrimoSetup.exe /s /f1" &$path &"\setup.iss", $path ) . . .
It will launch and run the app w/o returning any error ( I've tested ) but the printer will not be installed.
Comment our RunAsSet and the printer installs.
Edited by RamonaSure you can.As far as I know, RunAsSet works with Windows shares only so you won't be able to use it with Netware volumes even if you specify them as UNC paths.
Works:
; Set up passwords
$passWord = "LOCALPASSWORD"
$nwPassWord = "NWPASSWORD"
; Assess whether we're an admin. If not RunAsSet to an admin user for the Local
; machine and re-run the script with superfluous parameters under the new
; credentials. If we arrive in this loop again with the superfluous parameters
; on the command line, the user in RunAsSet wasn't an admin, so exit.
If (Not IsAdmin()) Then
If $CMDLINE[0] = 5 Then
MsgBox(0, "Error", "The provided user is not an Administrator on this PC. Please contact your administrator.")
Exit
EndIf
RunAsSet("localadmin", @ComputerName , $passWord)
Run(@ScriptName & " 1 2 3 4 5")
RunAsSet()
Exit
EndIf
DriveMapAdd("", "\\xxx_zs1\zen", 0, "zenadmin", $nwPassword)
Run("\\xxx_zs1\zen\apps\tools\bginfo.exe")
; Enjoy.I'm running this from ZEN in a moment, I'll update this post with any alteration...
Runs as posted from a ZEN simple application running as the current user.
- ZEN 6.5, 4.01
- NetWare 6
- Windows XP SP1, SP2
Edited by DaveF
Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.
Have you got CIFS installed on your server?Sure you can.
<{POST_SNAPBACK}>
BTW, you can use this UDF to impersonate your local admin user in-script, i.e without re-running your script using RunAsSet.
Edited by SumTingWongNo, just the NetWare client. Were you unable to get this to work?Have you got CIFS installed on your server?
BTW, you can use this UDF to impersonate your local admin user in-script, i.e without re-running your script using RunAsSet.
Very interesting UDF, btw...
Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.
Well it's working now. Not sure what I did but it works.
But am not able to remove desktop shortcuts I guess b/c RunAsSet only works on Run/Wait cmds. Maybe I can write another script and just access it using Run.
edit
Yep, calling another script with run used the new credentials and removed the shortcuts.
Edited by RamonaWell it's working now. Not sure what I did but it works.
But am not able to remove desktop shortcuts I guess b/c RunAsSet only works on Run/Wait cmds. Maybe I can write another script and just access it using Run.
edit
Yep, calling another script with run used the new credentials and removed the shortcuts.
<{POST_SNAPBACK}>
Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.
This is a good solution but it's not working if the script is located on a server; Set up passwords
$passWord = "LOCALPASSWORD"
$nwPassWord = "NWPASSWORD"
; Assess whether we're an admin. If not RunAsSet to an admin user for the Local
; machine and re-run the script with superfluous parameters under the new
; credentials. If we arrive in this loop again with the superfluous parameters
; on the command line, the user in RunAsSet wasn't an admin, so exit.
If (Not IsAdmin()) Then
If $CMDLINE[0]= 5 Then
MsgBox(0, "Error", "The provided user is not an Administrator on this PC. Please contact your administrator.")
Exit
EndIf
RunAsSet("localadmin", @ComputerName , $passWord)
Run(@ScriptName & " 1 2 3 4 5")
RunAsSet()
Exit
EndIf
DriveMapAdd("", "\\xxx_zs1\zen", 0, "zenadmin", $nwPassword)
Run("\\xxx_zs1\zen\apps\tools\bginfo.exe")
Run(@ScriptName & " 1 2 3 4 5")
I wanna be able to start the AutoIt from a novell server... Any solutions ???
Is your script compiled to an EXE or is it just the AU3 script itself?
Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.
Exe
It work perfectly if my script is local but it'S not working at all if it's on a server...
RunAsSet("localadmin", @ComputerName , $passWord)
*** The problem is here : I can't run the file from the server anymore because I'm now runasset... ***
Run(@ScriptName & " 1 2 3 4 5")
RunAsSet()
Edited by WolfmorderI searched the forum again and again and found this...
#NoTrayIcon
$Desktop = @DesktopDir
AutoItSetOption("RunErrorsFatal", 0)
AutoItSetOption("TrayIconHide", 1)
Break(0)
$USERNAME = "Administrator"
$PASSWORD = "*"
$RUN = 0 ; run indicator
; retrieve the cycle from commandline
If $CMDLINE[0] = 1 Then $RUN = $CMDLINE[1]
If $RUN = 0 Then
RunAsSet($USERNAME, @ComputerName, $PASSWORD)
Run('"' & @ScriptFullPath & '" " 1"')
If @error Then MsgBox(4096+32,"Error", "Error starting under admin mode")
Exit
EndIf
DirCopy ( "\\local server\Ascripts\", "C:\Program Files\Ascripts\" ,1)
RunAsSet()
I tried it and it give the exact same error if the .EXE is located on a server.
I'm starting to despair 
Is there a way to make it work ? I'm searching
I understand now. I don't know a way to achieve what you want if all the files in question are on a network share, because a process started with RunAsSet initially has no network connection/authentication, and so couldn't execute / re-execute the secondary script if it's on a share.
The only workaround that I can think of is if the first script FileInstalls a second script on the local PC, then runs the second script RunAsSet to the desired credentials.
Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.
Sign in to follow this
Followers
0
-
Recently Browsing 0 members
No registered users viewing this page.
Why aren't you using ZENWorks?
This is tough, if you have an install tree that exists on Netware and it needs to be run RunAsSet, the best solution is to:
RunAsSet in initial script.
Re-run another (or the same[!]) script with the admin credentials. (Initial script can exit.)
The script running with new credentials has no authentication to Netware yet, so you have to run a DriveMapAdd with user name and passwd to authenticate to Netware, even to use a UNC path. Do so.
Run the install, preferably using a UNC path so you don't have to rely on a mapped drive being set up on a particular PC.
Enjoy.
I can't post an example for lack of time, but I may have done so previously, you might search the forum again for DriveMapAdd
Share this post
Link to post
Share on other sites