Sign in to follow this  
Followers 0
jmangrum

RunAsSet

12 posts in this topic

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


Joseph MangrumCCNA, CNA, MCP, Network+

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

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 by scriptkitty

AutoIt3, the MACGYVER Pocket Knife for computers.

Share this post


Link to post
Share on other sites

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


CheersNobby

Share this post


Link to post
Share on other sites

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.


Joseph MangrumCCNA, CNA, MCP, Network+

Share this post


Link to post
Share on other sites

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.

:)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 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.

Share this post


Link to post
Share on other sites

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}>

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

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 by JdeB

Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

#10 ·  Posted

...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()


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.

Share this post


Link to post
Share on other sites

#11 ·  Posted

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}>

Share this post


Link to post
Share on other sites

#12 ·  Posted

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

Share this post


Link to post
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
Sign in to follow this  
Followers 0