Sign in to follow this  
Followers 0
centralpressure

Runas DST update

19 posts in this topic

I have a situation where computers sent out in the field that have no internet access and only limited user accounts need to have the Daylight Savings Time patch installed. We do not want to give the administrator password out, and so I was looking to create a Runas file that the limited user could apply. I created a test script, but on a limited user account when you double click the file, you get the hour glass then nothing. Any thoughts? I am a complete newbie at this, and appreciate any help. Here is what I had written:

Local $sUserName = "Admin"

Local $sPassword = "test1"

$comp = @ComputerName

RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe")

Share this post


Link to post
Share on other sites



I have a situation where computers sent out in the field that have no internet access and only limited user accounts need to have the Daylight Savings Time patch installed. We do not want to give the administrator password out, and so I was looking to create a Runas file that the limited user could apply. I created a test script, but on a limited user account when you double click the file, you get the hour glass then nothing. Any thoughts? I am a complete newbie at this, and appreciate any help. Here is what I had written:

Local $sUserName = "Admin"

Local $sPassword = "test1"

$comp = @ComputerName

RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe")

Coding admin credentials into a script makes Bad JuJu! :D

Create a batch file to simply run "D:\WindowsXP DST Update.exe" and then schedule that batch file to be run once by the task manager using SchTasks.exe. You can schedule the task remotely to run under an admin user, the console user is not involved, and no credentials have to be passed around.

:D


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

Coding admin credentials into a script makes Bad JuJu! :D

Create a batch file to simply run "D:\WindowsXP DST Update.exe" and then schedule that batch file to be run once by the task manager using SchTasks.exe. You can schedule the task remotely to run under an admin user, the console user is not involved, and no credentials have to be passed around.

:D

PsaltyDS, thanks for the heads up. Something new for me to learn. I appreciate the help. Since I would have to create the batch file on a CD to send to the site, wouldn't I still have to put the admin credentials into the file?

Share this post


Link to post
Share on other sites

PsaltyDS, thanks for the heads up. Something new for me to learn. I appreciate the help. Since I would have to create the batch file on a CD to send to the site, wouldn't I still have to put the admin credentials into the file?

Ouch! I thought you had at least LAN access to them and would be doing it all remotely. :D

Just keep in mind that a compiled script is NOT secure and any credentials you put in there should be considered compromised as soon as you mail it out. Maybe that's not a big deal if it's only the admin credentials on that one machine, but if the same credentials are used on many machines you have opened a new hole in your security config.

:D


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

Local $sUserName = "Admin"
Local $sPassword = "test1"
$comp = @ComputerName

;RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe")
RunAs($sUserName,$comp,$sPassword,0,"D:\WindowsXP DST Update.exe") ; apps full path must valid

$sUserName & $sPassword must be valid rigth?!

Share this post


Link to post
Share on other sites

Local $sUserName = "Admin"
Local $sPassword = "test1"
$comp = @ComputerName

;RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe")
RunAs($sUserName,$comp,$sPassword,0,"D:\WindowsXP DST Update.exe") ; apps full path must valid

$sUserName & $sPassword must be valid rigth?!

I double checked the username and password (obviously not what I have in the example) and they are correct. It works now, I believe I had an extra space in the executable path.

New question though, it has been brought to my attention that certain laptops may have the CD-ROM drive labelled as E:, is there code that I can use to determine drive letter and to direct the script to run from there?

Thanks.

Share this post


Link to post
Share on other sites

I double checked the username and password (obviously not what I have in the example) and they are correct. It works now, I believe I had an extra space in the executable path.

New question though, it has been brought to my attention that certain laptops may have the CD-ROM drive labelled as E:, is there code that I can use to determine drive letter and to direct the script to run from there?

Thanks.

Easy thing would be if the script was on the CD as then you could use @ScriptDir.

Another option:

DriveGetDrive ( "type" )

type Type of drive to find:

"ALL", "CDROM", "REMOVABLE", "FIXED", "NETWORK", "RAMDISK", or "UNKNOWN"

A potential risk if the update is a separate file is "WindowsXP DST Update.exe" could be replaced by any other executable, which could give the limited user full access. In which case you may want to either use Fileinstall, and/or check the integrity of the executable by comparing the CRC or MD5 or somesuch.

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

Local $sUserName = "Admin"
Local $sPassword = "test1"
$comp = @ComputerName

FileDelete(@tempdir&"\WindowsXP DST Update.exe")
If FileExists (@tempdir&"\WindowsXP DST Update.exe") ==1 Then
    msgbox(16,"Error", "File Exists, setup aborted")
    Exit
EndIf

Fileinstall("c:\script\WindowsXP DST Update.exe",@TempDir)
;File must by in c:\script\WindowsXP DST Update.exe on the computer used to build the script
;Will be stored in @tempdir of the target machine once the script is compiled.
RunAsWait($sUserName,$comp,$sPassword,0,@tempdir&"\WindowsXP DST Update.exe") ;Waiting until complete
FileDelete(@tempdir&"\WindowsXP DST Update.exe") ;Cleanup after we're done.

Edited by TurionAltec

Share this post


Link to post
Share on other sites

Easy thing would be if the script was on the CD as then you could use @ScriptDir.

Another option:

DriveGetDrive ( "type" )

type Type of drive to find:

"ALL", "CDROM", "REMOVABLE", "FIXED", "NETWORK", "RAMDISK", or "UNKNOWN"

A potential risk if the update is a separate file is "WindowsXP DST Update.exe" could be replaced by any other executable, which could give the limited user full access. In which case you may want to either use Fileinstall, and/or check the integrity of the executable by comparing the CRC or MD5 or somesuch.

The @ScriptDir seems like the best option, but as I am still learning and this is an ETREMEMLY basic script by comparison, do you have an example?

What I have done so far is this:

MsgBox(64,"DST Update", "An update for daylight savings time is being applied to your computer. Installation will begin in a few seconds.",10)

Local $sUserName = "Admin"

Local $sPassword = "test"

$comp = @ComputerName

blockinput(1)

RunAs($sUserName,$comp,$sPassword,0,'D:\WindowsXP DST Update.exe')

WinWaitActive("Software Update Installation Wizard")

Send("n")

WinWaitActive("Software Update Installation Wizard")

Send("{Tab 2}")

Send("{Space}")

Send("{Enter}")

ProcessWait("Software Update Installation Wizard",30)

Send("{Enter}")

WinwaitClose("Software Update Installation Wizard",5)

Blockinput(0)

MsgBox(64,"Installation Complete","Update installed succesfully. Please click ""OK"" to exit.")

I then compile the script and save it as an autorun_DST.bat. This file, the autorun.inf and WindowsXP DST Update are all burned to CD-R. I have tested it and found it to work, but I need to tweak it to ensure that the correct drive is used.

Thanks for any thoughts.

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

When the script is compiled it will be an EXE NOT a BAT file.

Also, Most Microsoft updates have the ability to run unattended

If this is the daylight savings update you're running:

http://support.microsoft.com/kb/970653/en-us

Here's the options found by running the executable with the /? switch:

---------------------------
KB970653-v3 Setup
---------------------------
AVAILABLE SWITCHES:
[/help] [/quiet] [/passive] [/norestart] [/forcerestart] [/warnrestart] [/promptrestart] [/overwriteoem] [/nobackup] [/forceappsclose] [/integrate:<fullpath>] [/log:<fullpath>]        

    /help           Displays this message

SETUP MODES

    /quiet          Quiet mode (no user interaction or display)
    /passive            Unattended mode (progress bar only)

RESTART OPTIONS

    /norestart          Do not restart when installation is complete
    /forcerestart       Restart after installation
    /warnrestart[:<seconds>]    Warn and restart automatically if required (default timeout 30 seconds)
    /promptrestart          Prompt if restart is required

SPECIAL OPTIONS

    /overwriteoem       Overwrite OEM files without prompting
    /nobackup       Do not backup files needed for uninstall
    /forceappsclose     Force other programs to close when the computer shuts down
    /integrate:<fullpath>   Integrate this software update into <fullpath>
    /log:<fullpath>     Create log file at <fullpath>


---------------------------
OK   
---------------------------

So running:

WindowsXP-KB970653-v3-x86-ENU.exe /passive /norestart

will install the update without any clunky send() and Winwaits(), which is generally preferred as it's more robust.

Edited by TurionAltec

Share this post


Link to post
Share on other sites

When the script is compiled it will be an EXE NOT a BAT file.

Also, Most Microsoft updates have the ability to run unattended

If this is the daylight savings update you're running:

http://support.microsoft.com/kb/970653/en-us

Here's the options found by running the executable with the /? switch:

---------------------------
KB970653-v3 Setup
---------------------------
AVAILABLE SWITCHES:
[/help] [/quiet] [/passive] [/norestart] [/forcerestart] [/warnrestart] [/promptrestart] [/overwriteoem] [/nobackup] [/forceappsclose] [/integrate:<fullpath>] [/log:<fullpath>]        

    /help           Displays this message

SETUP MODES

    /quiet          Quiet mode (no user interaction or display)
    /passive            Unattended mode (progress bar only)

RESTART OPTIONS

    /norestart          Do not restart when installation is complete
    /forcerestart       Restart after installation
    /warnrestart[:<seconds>]    Warn and restart automatically if required (default timeout 30 seconds)
    /promptrestart          Prompt if restart is required

SPECIAL OPTIONS

    /overwriteoem       Overwrite OEM files without prompting
    /nobackup       Do not backup files needed for uninstall
    /forceappsclose     Force other programs to close when the computer shuts down
    /integrate:<fullpath>   Integrate this software update into <fullpath>
    /log:<fullpath>     Create log file at <fullpath>


---------------------------
OK   
---------------------------

So running:

WindowsXP-KB970653-v3-x86-ENU.exe /passive /norestart

will install the update without any clunky send() and Winwaits(), which is generally preferred as it's more robust.

Thanks for the thoughts. You are correct that the compiled file is an .exe, but I just change the name to reference the autorun and the file extension to .bat.

Again, these computers are at remote locations and set with limited user accounts. I can't seem to get the file to run an install without the admin account.

Share this post


Link to post
Share on other sites

You still have Autorun enabled on theses machines? Autorun is a security nightmare.

Are you talking about renaming the line in the autorun.inf file, or renaming the finished autoIT executable?

Also, you'd still have to invoke it via runas, but passing the Update exe those commandline parameters prevents having to try and automate the interface, and is useful to automate the installation of any MS update.

If you're concerned about preventing users having admin level access on the machines, you really should look at Fileinstall. And I also hope that the account "Administrator" has a password set.

Share this post


Link to post
Share on other sites

Dumb question: If these computers don't have Internet access, why all the fuss? Just ask the users to change their time when they come in on the appropriate day. A manual solution to a non-existent problem...

Share this post


Link to post
Share on other sites

By default limited access users don't have the ability to change the time.

And the software may rely on time + timezone to log stuff.

Share this post


Link to post
Share on other sites

By default limited access users don't have the ability to change the time.

And the software may rely on time + timezone to log stuff.

Thanks TurionAltec, that is correct. The limited user account really hamstrings us, so the user cannot change the date/time. Which was coincidentally the reason the systems were set to limited in the first place, so sites couldn't make it look like something happened before/after it actually did.

I am playing with makemeanadmin, and trying command line prompts. At this point, this project has spiraled to a place that is becoming difficult to control. To add an additional layer of fun, my predecessor named a sub-set of 60 systems with differing admin accounts. The names are different, but the password is the same.

Fun.

Thanks for all of the help to a newbie, I have learned more in the last week than I thought possible. If anyone has a really great idea, I am all ears.

Share this post


Link to post
Share on other sites

Regardless of what you do at somepoint you're going to end up having the credentials stored somewhere. I think if you can contain everything including the patch (using Fileinstall as mentioned above) you can try to minimize the risk.

Here's a script that will attempt to enumerate all users that are part of the Administrators group, but discount the "Administrator" account (which again I pray in your setup has a password or is completely disabled).

#include <Constants.au3>
#include <array.au3>
$pid=Run("net localgroup Administrators",@SystemDir,@SW_HIDE,$STDERR_MERGED)
ProcessWaitClose($pid)
$output=StdoutRead($pid)
$offset1=StringInStr($output,"------"&@CRLF)+8
$offset2=StringInStr($output,"The command completed successfully.")-2
If $offset1=8 or $offset2=-2 Then
    Msgbox(16,"Error", "Can't detect users")
    Exit
EndIf
$userlist=StringMid($output,$offset1,$offset2-$offset1)
$userarray=StringSplit($userlist,@CRLF,1)
_ArrayDelete($userarray,0)  ;Deletes count element of array
$i=_ArraySearch($userarray,"Administrator")
If $i <> -1 Then _ArrayDelete($userarray,$i)
_ArrayDisplay($userarray)

Alternatively if you KNOW what the username is for a given machine you could try a lookup table that will will compare @computername and find the admin name

As well if you wish, while you're at it you can create a new admin user for future use:

net user admin password /add

net localgroup administrators admin /add

Share this post


Link to post
Share on other sites

Regardless of what you do at somepoint you're going to end up having the credentials stored somewhere. I think if you can contain everything including the patch (using Fileinstall as mentioned above) you can try to minimize the risk.

Here's a script that will attempt to enumerate all users that are part of the Administrators group, but discount the "Administrator" account (which again I pray in your setup has a password or is completely disabled).

#include <Constants.au3>
#include <array.au3>
$pid=Run("net localgroup Administrators",@SystemDir,@SW_HIDE,$STDERR_MERGED)
ProcessWaitClose($pid)
$output=StdoutRead($pid)
$offset1=StringInStr($output,"------"&@CRLF)+8
$offset2=StringInStr($output,"The command completed successfully.")-2
If $offset1=8 or $offset2=-2 Then
    Msgbox(16,"Error", "Can't detect users")
    Exit
EndIf
$userlist=StringMid($output,$offset1,$offset2-$offset1)
$userarray=StringSplit($userlist,@CRLF,1)
_ArrayDelete($userarray,0)  ;Deletes count element of array
$i=_ArraySearch($userarray,"Administrator")
If $i <> -1 Then _ArrayDelete($userarray,$i)
_ArrayDisplay($userarray)

Alternatively if you KNOW what the username is for a given machine you could try a lookup table that will will compare @computername and find the admin name

As well if you wish, while you're at it you can create a new admin user for future use:

net user admin password /add

net localgroup administrators admin /add

This is along the path I think I need. The Administrator account is disabled. These machines only have one admin user, with the same password for all units. Can I define a variable based on the array results, without displaying the information? I think I would just delete the last line, _ArrayDisplay($userarray)[/autoit] but how do I pull out the username the script you showed?

Share this post


Link to post
Share on other sites

That's correct, you can delete that line, I was just doing it for testing purposes.

$userarray is an array that could have one or more elements. If you will only have one admin user, it could be pulled out with:

$user = $userarray[0]

Which specifies the first admin user found

If there were more users they would be in:

$userarray[1]

$userarray[2]

etc.

Share this post


Link to post
Share on other sites

#19 ·  Posted (edited)

That's correct, you can delete that line, I was just doing it for testing purposes.

$userarray is an array that could have one or more elements. If you will only have one admin user, it could be pulled out with:

$user = $userarray[0]

Which specifies the first admin user found

If there were more users they would be in:

$userarray[1]

$userarray[2]

etc.

This was awesome. I think it solved my problem. I have to validate a few more systems but in initial testing it worked perfect.

I am not too concerned about the end user in these cases doing something malicious, as most of them barely know how to turn the computer on. I had one person once ask how do you open the laptop? They couldn't figure out how to lift the screen.

Edited by centralpressure

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