Runas DST update

[centralpressure]

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")

[PsaltyDS]

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!

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.

[centralpressure]

Coding admin credentials into a script makes Bad JuJu!

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.

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?

[PsaltyDS]

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.

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.

[rvn]

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?!

[centralpressure]

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.

[TurionAltec]

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.

[TurionAltec]

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 September 24, 2009 by TurionAltec

[centralpressure]

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.

[TurionAltec]

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 September 24, 2009 by TurionAltec

[centralpressure]

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.

[TurionAltec]

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.

[Confuzzled]

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

[TurionAltec]

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.

[centralpressure]

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.

[TurionAltec]

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

[centralpressure]

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?

[TurionAltec]

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.

[centralpressure]

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 September 30, 2009 by centralpressure