Sign in to follow this  
Followers 0
hcstarck

Running From Network Drive Issues

14 posts in this topic

I have a problem. I had written a bunch of scripts in AutoIt that use the

If $CmdLine[0] = 0 then
   RunAsSet("administrator", @Computername, "password")
   Run('"' & @SCRIPTFULLPATH & '" parameter' )
   Exit
EndIf

snippet to ensure that the code is being run with admin priviledges to install software. This has worked fine for us for well over a year. However, we recently changed all the server passwords so that they are no longer sync'd with the local admin passwords. Now running the script returns a user name or password incorrect message. So it appears that the script had been authenticated using the passthru which no longer works since the passwords are different.

After I run the snippet I had been calling the installer. I. E.

RunWait("\\server\upgrade.exe /v/qb+!")

I tried adding another RunAs before the RunWait using the server auth info, but it still coming back with the incorrect logon info message. Changing the script to the new server info doesn't work because that info isn't valid locally. Does anyone know of a way to work this out? Thanks

Share this post


Link to post
Share on other sites



I have a problem. I had written a bunch of scripts in AutoIt that use the

If $CmdLine[0] = 0 then
   RunAsSet("administrator", @Computername, "password")
   Run('"' & @SCRIPTFULLPATH & '" parameter' )
   Exit
EndIf

snippet to ensure that the code is being run with admin priviledges to install software. This has worked fine for us for well over a year. However, we recently changed all the server passwords so that they are no longer sync'd with the local admin passwords. Now running the script returns a user name or password incorrect message. So it appears that the script had been authenticated using the passthru which no longer works since the passwords are different.

After I run the snippet I had been calling the installer. I. E.

RunWait("\\server\upgrade.exe /v/qb+!")

I tried adding another RunAs before the RunWait using the server auth info, but it still coming back with the incorrect logon info message. Changing the script to the new server info doesn't work because that info isn't valid locally. Does anyone know of a way to work this out? Thanks

The way you have it written RunAsSet("administrator", @Computername, "password") this is not using the server password but the local admin password. If you changed the server local admin password this should then just change the password. If you want to use a domain account the RunAsSet("administrator", @logondoman, "password") should work.

Top

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

I'd consider using DriveMapAdd as a workaround.

DriveMapAdd( "device", "remote share" [, flags [, "user" [, "password"]]] )

Edit: Well, I just remembered certain cases where using the UNC path is better due to the uninstall info stored in the registry.

Edited by CyberSlug

Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!

Share this post


Link to post
Share on other sites

The way you have it written RunAsSet("administrator", @Computername, "password") this is not using the server password but the local admin password. If you changed the server local admin password this should then just change the password. If you want to use a domain account the RunAsSet("administrator", @logondoman, "password") should work.

Top

I used the RunAsSet with the local account to ensure that the install would run (most of the installs I have automated all need admin rights to finish correctly). But using the admin account on the server doesn't work because the domain passthrough no longer works. So its like running it as a user. The problem with using a domain account is that all the domain account passwords change every so many days. So I would have to keep changing the stored password, and recompiling the scripts everytime the password changes.

I'd consider using DriveMapAdd as a workaround.

DriveMapAdd( "device", "remote share" [, flags [, "user" [, "password"]]] )

Edit: Well, I just remembered certain cases where using the UNC path is better due to the uninstall info stored in the registry.

That would work, except for the same password changing issue.

I guess I'm being lazy, but I run the scripts when setting up new PC's. It used to be I would just double click on AutoIt exe, and all of our software would get installed. But it sounds like there is no way to run the file on the server without entering the user/pass every time. Unless I am just using RunSetAs incorrectly. It seems to me like I should be able to do the admin check, if the AutoIt isn't being run as admin to recall itself using RunSetAs w/local admin. And then use RunSetAs to call the installer using the server admin info. But doing it that way still gives me the incorrect password issue. Should it theoretically work? And my code is just wrong? (Which is very possible)

Am I possibly getting the incorrect login because I am using the admin check snippet, and when its not being run with Admin, it calls itself again using the local admin account, which has no rights to connect to the server? (The AutoIt stub is on the server) So I may have to copy my stub locally if not being run as admin, and then run it using local admin, and then call the installer using the server admin? Maybe?

I'm just tossing out ideas, sorry if they are confusing. Thanks for the help

Share this post


Link to post
Share on other sites

I don't see any glaring errors. It seems it should work if the password is right. :think:

The only other idea I have would be the info at

http://blogs.msdn.com/aaron_margosis/archi.../24/193721.aspx

It the MakeMeAdmin batch file works, it should be possible to integrate the procedure into your AutoIt script.


Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!

Share this post


Link to post
Share on other sites

I just ran into this myself.

The fix was to set the working directory to an accessable point on the C:, like @tempdir

I did not have a working dir set, but when I did it ran fine. Also I had to run the script from Start/Run, it would not run with the folder open.

Top

Share this post


Link to post
Share on other sites

I don't see any glaring errors. It seems it should work if the password is right. :think:

The only other idea I have would be the info at

http://blogs.msdn.com/aaron_margosis/archi.../24/193721.aspx

It the MakeMeAdmin batch file works, it should be possible to integrate the procedure into your AutoIt script.

It looks like the MakeMeAdmin batch is definately an option. Now I'm just trying to use that code in an AutoItScript. Reason being that the batch requires you to manually type in the password. But I should be able to call the same commands using AutoIt. So far I have

RunAsSet ( "administrator", @ComputerName, "password" )

Run( @ComSpec & "/c net localgroup administrators /add " &@LogonDomain &"\" &@UserName )

Running that gives me the Unable to Execute the external program. Etc.. etc.. The code looks ok. Any thoughts??

Share this post


Link to post
Share on other sites

You need a space between the @ComSpec & " /c

Run( @ComSpec & " /c net localgroup administrators /add " & @LogonDomain & "\" & @UserName )

CyberSlug,

I copied your line exactly into the script, and I'm still getting the same error messages. Any other ideas? Thanks for the suggestions

Share this post


Link to post
Share on other sites

CyberSlug,

I copied your line exactly into the script, and I'm still getting the same error messages. Any other ideas? Thanks for the suggestions

I figured it out. I had to add the working dir to the Run. I'm assuming something to do with the whole passwords differeing thing. Or maybe the fact that when it did launch ComSpec, it was trying to run it from the network drive, where net.exe doesn't exist. I think. Anyways, it works now. Thanks for the help.

Oh yeah, I ended up having to use the same concept in the MSDN entry that CyberSlug linked to. Works pretty good as long as the script doesn't crash.

Share this post


Link to post
Share on other sites

not to hijack this thread, but i have a question that is along the same lines:

Is there any way to retieve the local path of a file from a networked computer? I want the local path: c:\folder\file.exe not the networked path: \\compuetername\folder\file.exe or the mapped path z:\folder\file.exe

Thanks for any help!!

Share this post


Link to post
Share on other sites

I figured it out. I had to add the working dir to the Run. I'm assuming something to do with the whole passwords differeing thing. Or maybe the fact that when it did launch ComSpec, it was trying to run it from the network drive, where net.exe doesn't exist. I think. Anyways, it works now. Thanks for the help.

Oh yeah, I ended up having to use the same concept in the MSDN entry that CyberSlug linked to. Works pretty good as long as the script doesn't crash.

Inspiered by this thread I have created my own littel RunAsSet from networked drive (I do mount it as the RunAsSet user). Runing Mozilla-Firefox as a diffrent user right this moment. :think:

If you add

Opt("RunErrorsFatal",0);0=Silent error sets @error to 1
Then Run($cmd) won't crash (at least it is not suposed to).

Now if only the cursor didn't blink so erratic.....

Share this post


Link to post
Share on other sites

You have to set a working dir that points back to the c:\

I ran into this with a run command from a share. This fix is not mine... I found it in another thread on this board.

Run( @ComSpec & " /c net localgroup administrators /add " & @LogonDomain & "\" & @UserName, @tempdir )

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