RunAsSet

[jmangrum]

The question that I have is with RunAsSet. I have created a script to run an executable as administrator, and when running from the local machine than it run fine. If I reference the executable from a Novell drive, I get the message that could not find path to the executable. If I take the same run command but not use the RunAsSet then it works fine. Is this by design, or is there a way to make this work? Here is a sample of the 2 scripts I have tried:

Does Not Work

RunAsSet("Administrator", @Computername, "adminpassword")

RunWait("f:\test\regedit.exe")

RunAsSet()

Works

RunWait("f:\test\regedit.exe")

Seems like I am loosing my Novell login rights when I use the RunAsSet. Any suggestions?

Thanks

[scriptkitty]

When you work with runasset on a local drive, you are changing the logon name temporarly in essence.

Been a while since working with Novel, so forgive my rustyness.

Since you haven't logged into novel as such, most likely you have no rights to that drive. Normally when you log into novel, you have network drives and such, depending on who you are. I am not sure if you would have to set up the drives as the admin (or whatever your runasset name), or if you would have to use Netware tools to do it.

Again, I am a bit rusty on novel, and I don't know the new sytems. I know they have netware tools for this, but I am drawing a blank atm.

If you have the netware tools, you could try useing Map, as in

To map drive F: to SYS:\HOME\JMangrum on the current server, type

MAP F:=SYS:\HOME\JMangrum

Edited January 17, 2004 by scriptkitty

[nobby]

Novell does not accept the Administrator as a valid Netware user. I don't think that synchronizing the Administrator password will work either.

My solution would be to copy the necessary files you want to run to the local machine via a login script, then run the script, then delete the files...

Cheers

Nobby

[jmangrum]

Yeah, I was thinking also about the rights that Novell would give you, and you are right about the administrator, as the valid default administrator id is admin. The mapping to the drive would would, except that since you are logging in with a different ID, then you would have the other issues to contend with.

Thanks to both of you for the reply, and as suspected I do have to do the login local. I still think RunAsSet is a great command, as this has simplified the way I run scripts.

Thanks.

[Guest KeTeFLiPs]

I have the same problem.

It seems to be that with Novell you cannot login in workstation only with the RunAsSet.

There is no solution, it I have tried everything.

[Guest KeTeFLiPs]

I have the same problem.

It seems to be that with Novell you cannot login in workstation only with the RunAsSet. 

There is no solution, it I have tried everything.

<{POST_SNAPBACK}>

I make this (its spanish):

$var1 = RunAsSet("administrador", @computername, "*********",1)

If $var1 = 1 then

MsgBox(4096, "Not Works", "This OS dont support this", 10)

Else

RunWait("c:\temp\dotnetfx.exe /Q")

RunAsSet()

EndIf

And it return me a MsgBox, I find the problem, Novell dont support this.

[DaveF]

Since RunAsSet() is being used I'm going to assume that the client PCs are Win XP. This being the case, the initial problem is that mapped drives, whether to Windows or NetWare shares, are profile specific. So, I declare that J's issue was arising from the F: drive not being mapped for Administrator, or not mapped to the same share point.

Running a MAP command after RunAsSet() wouldn't work in this case because NDS authentication is per-profile, too, and Administrator won't have been authenticated, so the MAP command will fail.

The AutoIt3 function DriveMapAdd() lets you make a connection to a network share with credentials, but it's a script function; it doesn't care about RunAsSet() and will always run as the current user.

You could make a seperate script that performs the DriveMapAdd() using good NetWare credentials and then calls Run() after having done so and compile it into a separate EXE, then call that EXE with RunAsSet() with good Windows credentials from your first script so that the "current user" for the second script will be the desired user (e.g. Administrator) and then the NetWare authentication and drive mapping will be done before calling the EXE on the share. I've done it, it works on NetWare 6 with the 4.9 SP2 NetWare Client for XP.

[Edit: Clarification]

Edited March 15, 2005 by DaveF

[Guest Darth Coder]

I've got a similar problem, although with several WinXP Laptops trying to run an executable on a mapped drive on a Win2K network share. On most machines (mix Win2K and WinXP), my code works fine. It only seems to happen with a couple of XP laptops. Obviously, I am unsure if the cause is AutoIT or Windows, or something else with the PCs themselves.

Here is the error I am getting:

Unable to Execute the external program. The system cannot find the path specified.

The script maps the drive fine and, once the script crashes, I can browse to the mapped drive, find the file, and execute it manually.

I originally only tried it with RunAsSet(), but after your below suggestion, I added the credentials to the drive mapping, with no success.

Here is a sample of my code, though I don't believe the problem is there anymore. Maybe someone else can enligthen me. Thanks!!!

#include "file.au3"

;Map the Network Share
DriveMapDel("X:")
DriveMapAdd("X:", "\\server01\netlogon\adobe", 0, "domain\username", "password")


RunAsSet("username", "domain", "password",0)

$var = RegEnumKey("HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Acrobat Reader",1)

If $var = "7.0" then
;MsgBox(4096, "Exiting...", "Adobe Reader 7.0 is Already Installed on your PC!")
_FileWriteLog("x:\adobeinstall.log",@Computername & ", " & @Username & ", Already Installed")
RunAsSet()
Exit(2)
EndIf

;Run Adobe 7.0 Installer
MsgBox(0, "Adobe Reader 7.0 Install...", "Installing Adobe Reader 7.0...", 10)

Run ("x:\AdbeRdr70_enu_full.exe")

Thanks again!!!

Since RunAsSet() is being used I'm going to assume that the client PCs are Win XP. This being the case, the initial problem is that mapped drives, whether to Windows or NetWare shares, are profile specific. So, I declare that J's issue was arising from the F: drive not being mapped for Administrator, or not mapped to the same share point.

Running a MAP command after RunAsSet() wouldn't work in this case because NDS authentication is per-profile, too, and Administrator won't have been authenticated, so the MAP command will fail.

The AutoIt3 function DriveMapAdd() lets you make a connection to a network share with credentials, but it's a script function; it doesn't care about RunAsSet() and will always run as the current user.

You could make a seperate script that performs the DriveMapAdd() using good NetWare credentials and then calls Run() after having done so and compile it into a separate EXE, then call that EXE with RunAsSet() with good Windows credentials from your first script so that the "current user" for the second script will be the desired user (e.g. Administrator) and then the NetWare authentication and drive mapping will be done before calling the EXE on the share. I've done it, it works on NetWare 6 with the 4.9 SP2 NetWare Client for XP.

[Edit: Clarification]

<{POST_SNAPBACK}>

[Jos]

When your script also runs from a mapped drive it could help to add the workdir to the Run() statement because the program is shelled with different credentials.

Another thing that often work better is to copy the file first to a TEMP directory on the local hardisk, then do the RunAsSet and run the installer, this avoids issues with mapped drives and changing credentials......

Edited May 3, 2005 by JdeB

[DaveF]

...It only seems to happen with a couple of XP laptops...

#include "file.au3"

;Map the Network Share
DriveMapDel("X:")
DriveMapAdd("X:", "\\server01\netlogon\adobe", 0, "domain\username", "password")
RunAsSet("username", "domain", "password",0)

$var = RegEnumKey("HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Acrobat Reader",1)

If $var = "7.0" then
;MsgBox(4096, "Exiting...", "Adobe Reader 7.0 is Already Installed on your PC!")
_FileWriteLog("x:\adobeinstall.log",@Computername & ", " & @Username & ", Already Installed")
RunAsSet()
Exit(2)
EndIf

;Run Adobe 7.0 Installer
MsgBox(0, "Adobe Reader 7.0 Install...", "Installing Adobe Reader 7.0...", 10)

Run ("x:\AdbeRdr70_enu_full.exe")

Thanks again!!!

<{POST_SNAPBACK}>

Again, drive mapping is per-profile in Win XP, the drive is getting mapped for the interactive user but not the RunAsSet user.

Run() works fine with UNC paths, so you could just use the full path, but as JdeB notes you probably should add the workingdir parameter to your call to Run()

[Guest Darth Coder]

The UNC Path did the trick. I still think it's strange that only a couple of XP PCs choked on the drive mapping, but as long as the thing works now, I'm not complaining! Thanks!

Again, drive mapping is per-profile in Win XP, the drive is getting mapped for the interactive user but not the RunAsSet user.

Run() works fine with UNC paths, so you could just use the full path, but as JdeB notes you probably should add the workingdir parameter to your call to Run()

<{POST_SNAPBACK}>

[major4579]

The UNC Path did the trick.    I still think it's strange that only a couple of XP PCs choked on the drive mapping, but as long as the thing works now, I'm not complaining!  Thanks!

<{POST_SNAPBACK}>

Darth, the XPs that were giving you a problem - do they have Service Pack 2 installed? And the XPs that worked fine - are they still at Service Pack 1 or below? If so using UNC may solve a lot of problems for me. (I'm not at my client's site so I cannot test it yet).

In my case, the network logon script was running an AutoIT executable on a mapped drive on a W2K server. It has worked fine for many, many computers until one laptop got updated with SP2. Then I would get "Unable to Execute the external program. The system cannot find the path specified." This would happen if the AutoIT executable was ran from within the logon script or ran manually.

-Marc