/build/static/layout/Breadcrumb_cap_w.png

Blog Posts tagged with AutoIt

Ask a question

K1000 - Custom KBScriptRunner for 5.3

I've written an AutoIT script to force an inventory check-in (runkbot 4 0) and FS/MI processing (runkbot 6 0). The program outputs console text to custom logs (kbs_inventory.log and kbs_mi.log) in the install directory. I've added a splash screen as well, so you can tell what the script is doing (don't have to guess when it's done or look at processes).

Simply place the compiled EXE from my source code (both attached) in the Dell KACE Agent install directory, and run it under an account with local administrator rights (use RunAs if you're trying to run it under a restricted user account).

Enjoy!

 

#NoTrayIcon

;========================================================

; AutoIt version of Dell KACE KBScriptRunner.exe

;

; Written by: Andy Flesner - Systems Architect

; Original: February 20, 2012

; Last Updated: February 20, 2012

;========================================================

#Include <File.au3>

 

Global $programfiles = "C:\Program Files", $errlog = $programfiles & "\Dell\KACE\KBScriptRunner_error.log"


; Determine architecture

If @OSArch = "X64" Then

$programfiles = "C:\Program Files (x86)"

EndIf

 

; Force Dell KACE Agent Inventory

SplashTextOn("KBScriptRunner","Forcing Dell KACE Agent Inventory...",400,50)

RunWait(@ComSpec & ' /c "' & $programfiles & '\Dell\KACE\runkbot.exe" 4 0 > kbs_inventory.log',$programfiles & "\Dell\KACE",@SW_HIDE)

SplashTextOn("KBScriptRunner","Forcing Dell KACE Agent FS/MI Processing...",400,50)

RunWait(@ComSpec & ' /c "' & $programfiles & '\Dell\KACE\runkbot.exe" 6 0 > kbs_mi.log',$programfiles & "\Dell\KACE",@SW_HIDE)

SplashTextOn("KBScriptRunner","KBScriptRunner complete.",400,50)

Sleep(5000)

SplashOff()

 


Source - KBScriptRunner.au3

Compiled - KBScriptRunner.exe

Be the first to comment

A moment of Praise for AutoIT

Thank you AutoIT

You let me overcome hurdles 

and by hurdles, of course I mean rusted software

whose installation advice is to put the cd in

and doubleclick setup.exe

don't they understand, these horrid software companies?

the terror and agony that is manual installation

and so I praise you autoit

Send("{ENTER}") is my best friend.

View comments (3)

Dropbox Deployment Script

<# 
Setup.ps1
 
Uninstalls* all versions of DropBox and installs latest
 
* Dropbox does not install for all users, it installs for the installing user, and that
user requires administrative access... this is a problem.
 
Script uses 7-Zip (installed on all of our machines) to unpack the installer into the
desired destination directory, and then creates the necessary registry entries and
Start Menu shortcut.
 
Script does not load each registry hive and attempt to uninstall per-user installs.
 
OS: W8, W7, XP
Arch: x86, x64
 
Adam Sailer
2013.05.09
#>
 
 
## Globals
$invoke = split-path -path $myinvocation.mycommand.path -parent
$os = gwmi win32_OperatingSystem
$proc = gwmi win32_Processor
$debug = $false
 
 
$dest = $env:ProgramFiles
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall'
 
if (($proc.AddressWidth -eq 64) -and ($proc.DataWidth -eq 64))
{
    $dest = ${env:ProgramFiles(x86)}
    $key = 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall'     
}
 
 
Function KillApps
{
    write-host "`n`n@@ Called KillApps" -fore Magenta
    get-process -name *dropbox* | stop-process -force
}
 
 
Function Unpack
{
    write-host "`n`n@@ Called Unpack" -fore Magenta
 
    $7z = "$env:ProgramFiles\7-Zip\7z.exe"
    if (!(test-path $7z)) { exit 1 }
 
    $archives = (dir -path $invoke\setup -recurse -include Dropbox*.exe)
 
    foreach ($archive in $archives)
    {
        write "Unpacking : `"$archive`""
        $options = "x -o`"$dest\Dropbox`" `"$archive`" -y"
         
        if (!$debug)
        {         
            $process = (Start-Process -FilePath $7z -ArgumentList $options -Wait -Passthru)
            if ($process.ExitCode) { write $process.ExitCode; exit $process.ExitCode }
        }  
        else { write $options }
    }
}
 
 
Function Setup
{
    write-host "`n`n@@ Called Setup" -for Magenta
 
    $apps = @(dir -path $dest\Dropbox -recurse -include dropbox.exe)
 
    $path = "$env:AllUsersProfile\Start Menu\Programs"
 
    foreach ($app in $apps)
    {
        ## $app | select-object *
        $product = $app.VersionInfo.ProductName
        $version = $app.VersionInfo.ProductVersion
 
        $wshell = New-Object -comObject WScript.Shell
         
        $link = $wshell.CreateShortcut("$path\$product.lnk")
        $link.Description = $product
        $link.TargetPath = $app
        $link.IconLocation = $app
         
        if (!$debug) { $link.Save() }
         
         
        #### Registry Entries
 
        $item = "$key\$product"
        new-item -path $key -name $product -force | out-null
 
        set-itemProperty -path $item -name DisplayIcon -value "$app,0" -force
        set-itemProperty -path $item -name DisplayName -value $product -force
        set-itemProperty -path $item -name DisplayVersion -value $version -force
        set-itemProperty -path $item -name Path_Directory -value "$dest\$product" -force
        set-itemProperty -path $item -name Path_Shortcut -value "$path\$product.lnk" -force
        set-itemProperty -path $item -name Path_Menu -value "$path\$product" -force
        set-itemProperty -path $item -name Publisher -value "$product, Inc." -force
        set-itemProperty -path $item -name UninstallString -value 'Use PowerShell script' -force
 
        gp $item
    }
}
 
 
Function Uninstall
{
    Param(
        [Parameter(Mandatory=$false)]
        [string]$inp
        )
 
    write-host "`n`n@@ Called Uninstall" -fore Magenta
 
 
    $paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall',
        'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall'
        ) | where-object { test-path $_ }
 
    $items = @(dir $paths | % { gp $_.PsPath } | ? { $_.DisplayName -imatch $inp })
 
    foreach ($item in $items)
    {
        $item | gm | ? { $_.Name -imatch 'Path_' } | % {
         
            write "Delete : $($item.($_.Name))"
            if (!$debug) { remove-item $item.($_.Name) -recurse -force -ea SilentlyContinue }
        }
        write "Delete : $($item.PSPath)"
        if (!$debug) { remove-item $item.PSPath -force -ea SilentlyContinue }
    }
}
 
 
#
#
 
 
Clear
KillApps
Uninstall Dropbox
Unpack
Setup
View comments (3)

Admin Script Editor: Script Packager FAQ

The Script Packager is a feature of the Admin Script Editor which allows you to bundle your scripts and any dependant files in a single executable for easy distribution. Further, you can set your script to run with alternate credentials and even leverage Windows file security features to protect your script's code from the user runing it. Read more about this feature and see an introduction video here.

Due to the fact that the feature is not simple to use until understood, it was not included in the trial version of the application. Below are answers to many frequently asked questions about the Script Packager:

Are packaged script passwords encrypted?

When you supply alternate credentials in the package settings, this is not placed in your script or available in text. The information is encrypted within the packaged executable (in fact the entire executable is encrypted).

If you are placing a name and password within your script, you may be safe too. I you are using alternate credentials the package executes the script and any additional files are extracted to the temp directory which is secured with EFS and NTFS (both optional but enabled by default) so that user still cannot view the code or any additional files extracted during execution.

How do I handle passing command line arguments to packaged scripts?

Because the script is not being run directly, objects like WScript.Arguments.Count will not work with packaged scripts. Packaged scripts store the command line used to execute them in an environment variable named %ASEEXEARGS%. This is a simple string which you may look to in your script to take action based on command line arguments passed to the executable.

PowerShell Example:

$Args = Get-Content env:ASEEXEARGS 
if ($Args.Contains("-reboot"))
{
Write-Output("Args passed to indicate reboot request")
}

VBScript Example:

Set objShell = CreateObject("WScript.Shell") 
Set objEnv = objShell.Environment("Process")
strPath = objEnv("ASEEXEARGS")
If Instr(strPath,"-reboot") Then
wscript.write ("Args passed to indicate reboot request")
End If

Note: the ASE environment variables only exist while a packaged script is running, if you attempt to reference these variables in your code outside of a packaged script (such as running from ASE) these variables will not exist. To check for this condition programmatically, you can look at %ISEXE% to determine if the script is running as a packaged executable; if set to "1" you can assume the documented ASE variables will exist and may be referenced by your code.

What kind of security is provided to protect my script code?

The Script Packager™ was designed with security in mind...

Encryption

Files in the executable package are encrypted.

Source Protection

On Windows 2000 and later systems, during execution files are placed in a specified directory that is restricted through use of Access Control Lists (ACLs) on NTFS drives. Additionally, the Windows Encrypted File System (EFS) is utilized to further protect files in this access restricted folder. After execution, these files and folders are removed.

Alternate Credentials

On Windows 2000 and later systems, you may specify that the packages script is to be run with the credentials of an alternate user account.

Selling Scripts or Securing Scripts for Delivery Outside A Corporate Network

The EFS encryption is very secure with the caveat that you need to specify an account name and password in order to set the NTFS and EFS security. In other words, for an internal sys admin on a network it is an ideal solution. However, this will not work if you are planning on selling your scripts to customers since the EFS recovery agent for the domain would still be able to access the files while they were decrypted.

I've lost the source for my script but have the packaged executable, How do I extract my script?

Packaged scripts are not actually compiled, they are "packaged" into a self-extracting archive with some additional features and functionality. When a packaged script is run, it extracts itself to a specified location, executes, and then deletes itself. When the script is being run, it is decrypted and extracted in order to execute. This is your opportunity to get at the source files. Normally the location where the package is decompressed is %TEMP%, or specifically, a randomly numeric named subfolder of this location. Often scripts run and end too quickly to access this source so the trick would be to remove the permission to delete from this location.

So if you remove "Delete" permission from %TEMP% and then run the packaged script, it will extract, then run, but then fail to delete itself and you will then be able to browse to %TEMP%\######## (the number signs represent a random number) where you can see the source files.

If alternate credentials were specified when creating the package, it your own access to the files may be restricted. If it was created using alternate credentials with NTFS and/or EFS encryption enabled (they are both enabled by default when specifying alternate credentials) then keep in mind that you won't be able to access the files unless you're actually logged on with the alt credential account OR if your logged on account is an EFS recovery agent for the domain.

How can I hide the command prompt when running a VBScript?

Particularly when you use the ScriptForm Designer to create a graphical interface it can be undesirable to have the standard command prompt window appear when your script runs. To avoid this in a packaged script, change the process in the settings for the packaged script from cscript.exe (console interpreter) to wscript.exe (windows interpreter).

Are there any limitations to what I can specify for my package's filename?

To avoid possible issues with execution, refrain from including special characters in the names of packaged scripts. Because the file name is set as an environment variable value, including characters such as parenthesis can cause issues that prevent the script from successful execution.

My Packaged Script does not appear to run at all, what is going on?

If the script fails to run at all, you will find the reason why in the Windows Event log. On Windows NT and later systems, packaged scripts report success and failure to the Application Log.

If you have a path specified in the Process Name field, the script will fail to execute. This field should contain only the name of the interpreter itself (kix32.exe, cscript.exe, autoit3.exe, etc.)

If addressing network shares and using alternate credentials, specify a UNC path and not a mapped drive letter. The credentials of the specified account will not see mapped drives that belong to the user running the packaged script.

KiXtart and AutoIt Users: If the KiXtart (kix32.exe/wkix32.exe) or AutoIt (autoit3.exe) interpreter is not available on the system running the packaged script (in its %PATH%) you will want to include the interpreter in your package using the Additional Files option of the Script Packager.

Regarding Event Log Error Codes: Due to a lack of an installed messages DLL on client systems (currently not available) you will see some generic text in event log entries prior to the actual error message in the description text. Click here for details or see ASE help.

The following errors are reported if the packaged executable itself encounters a problem during execution:

-1 = packaged script attempted to unpack itself on a network drive (not supported)
-2 = packaged script could not process its configuration information (settings, paths, etc.)
-3 = packaged script executable is corrupt
-4 = packaged script attempted to apply credentials on a FAT volume
-5 = packaged script attempted to apply credentials on system older than Windows 2000
-6 = temporary target folder for script file storage is encrypted

If the package is able to run the script, but an error is returned when attempting to run your script an error of -10 is returned. A second event log entry will provide the Win32 error code that explains the error. If the error text is not included, use the Error Code Lookup utility in ASE to learn its meaning. Additionally, some commonly reported errors and explanations are documented in the ASE help file.

My packaged script runs, but has problems and does not execute as expected, what might be wrong?

The packaged script is simply executing the specified interpreter, and does not change your script in any way. However, because the script is running from a different location than from where the package is executed, referencing other files or utilities using Shell, Run, etc. will need to make use of our special environment variables to address external files.

When running with alternate credentials, the "current user" is that of the user specified for alternate credentials and not the account executing the package. To address the user profile area of the registry it is necessary to use our special environment variable in place of HKEY_CURRENT_USER references.

In both cases, using the "Packaged Executable" script template will provide you with a good start. Below is a quick summary of the environment variables available to ASE packaged executables; for more detail please see the ASE help file.

  • %ISEXE% - is equal to "1" if the script is running from within a packaged executable.
  • %ASEEXE% - is equal to the full path and filename of the packaged executable being run; use this when referencing files located alongside the packaged executable (do not specify no path, which infers "current directory").
  • %ASEEXEPATH% - like ASEEXE, this is equal to the full path of the packaged executable being run, but ends with a backslash and does not include the executable filename in its value.
  • %ASESCRIPTPATH% - is equal to the current directory of the executing script (in its temporary location). If you wish to reference files included with your package with the "Additional Files" feature, use this variable to specify their path for Shell/Run operations.
  • %ASEEXEARGS% - equal to any arguments passed to the packaged executable when it was launched
  • %ASEHKCU% - use this in place of HKEY_CURRENT_USER when using the "Alternate Credentials" feature of the Script Packager. HKCU points to the registry of the specified alternate account credentials. Using %ASEHKCU% will reference the registry of the user executing the packaged executable (HKEY_USERS\).

Note: ASEEXEPATH and ASESCRIPTPATH both end with a backslash (careful not to include an additional backslash in your strings!)

Be sure to expand environment variables as needed. In KiXtart, using an environment variable in a string expands it to its value by default. In VBScript the following method may be used:

Set oShell = CreateObject("WScript.Shell")
sBatPath = oShell.ExpandEnvironmentStrings("%ASESCRIPTPATH%")
oShell.Run sBatPath & "MyIncludedFile.exe"

Why might I not able to read the registry values I write on 64 bit systems when my script is packaged?

I am writing a tool that uses the registry as storage for all needed data. I am not able to read them out with the script is packaged but works fine with just the native vbscript.

Fror example...

amreglocation = "HKLM\Software\SAM"
logpath = WshShell.Regread(amreglocation & "\General\LogPath")
domainname = WshShell.Regread(amreglocation & "\General\DomainName")
accountdomain = WshShell.Regread(amreglocation & "\General\AccountDomain")

It is always a good idea to add some checking to see if your script sees the subkey expected before making use of values. However, this situation may be experienced if you are running a script packaged for 32bit on a 64bit system. On 64bit systems there is a separate registry node which would not be seen by a script executed as 32bit. When running natively with cscript, the adjustment is made automatically by the system. However, when packaging a script for 64bit systems, you'll need to create a 64bit package specifically.

One workaround that has been reported is to export your registry keys, edit them and then import them to the WOW6432Node.

Packaged scripts configured to run as 64bit packages may return error 216 (Failed to execute process in the context of the current user). When running packages on 32bit systems, be sure to have them set 32bit packages, or if size is not a concern to "autodetect".

What are some reasons I might see Error Code 2 when running my packaged script?

f you see the error "Failed to execute process. Error code 2" it usually means a dependency required to run your script is not available on the system where the packaged script is being executed. For example if your script is a KiXtart script, it requires KiX32.exe (or wKiX32.exe). There are a number of ways you can make this available on target systems:

1) Include KiX32.exe in a packaged script using the "Additional Files" feature.

2) In the additional files section of the ScriptPackager, check the box to automatically include the script interpreter (for KiXtart and AutoIt only, VBS and PS require installation).

3) Copy the file to the path on each target system. To automate this you might use a batch file that copies KiX32 to the system32 directory on systems where it is not found before executing. This is most common, but KiX32 can be placed in any directory listed in the target systems %PATH% variable.

Note: placing Kix32.exe in the same directory as a packaged executable will not work; packaged scripts are run in a subdirectory of %TEMP% and not in the same location as the packaged executable script.

4) If you are not using a packaged executable, you may place KiX32 on a network share such as NETLOGON and specify this as the location of KiX32 in any calls made to initiate the script.

There are certainly other ways to address this situation, but above are some comon solutions we have provided with ASE specifically as well as some general best practices.

Why might my packaged script unexpectedly cause a UAC prompt?

The fact that a script is packaged alone will not cause a UAC prompt. The most common cause for this behavior is in the chosen file name for the packaged executable. Any file containing some or all of the keywords "Install" or "Setup" will result in a UAC prompt as designed by Microsoft. 

Be the first to comment

Admin Script Editor: Script Packager Intro

The Script Packager is a feature of the Admin Script Editor which allows you to bundle your scripts and any dependant files in a single executable for easy distribution. Further, you can set your script to run with alternate credentials and even leverage Windows file security features to protect your script's code from the user runing it. I'm proud of this feature as it was an original idea since copied by many others. It basically works like this:

  • You set the name, tooltip, icon, security settings, alternate creditals, etc. in the Script Packager slide-out window and press the "Generate" button to build the executable (which can optionally be automatically executed so you can verify it works as desired).
  • By default the values chosen above are injected into the top of your script in a collapsed region of comments so that you don't need a separate settings file and can avoid the need to make all these choices again next time you wish to package your script (passwords are of course not stored).
  • When a script is executed its contents are extracted to a temp directory and executed from there.
    • If security options are approprately set, it can run with the credentials of another account and restrict access to the directory by denying the user access via Access Control List (ACL) and Encrypted File System (EFS) settings. 
  • Once the script is completed, the files dumped to the temp directory are removed from the system.

Some things to keep in mind:

  • the script is not compiled, it is packaged and extracted for normal execution
  • the script is not running from where the executable is launched, it is in a random temp directory so any relative path references will need to be modified to absolute paths or utilizing some special environment variables set by the package
  • you can pass arguments to the packaged script, but they are captured in an environment variable which you'll need to address as a string (you cannot use any native scripting language's features for referencing command line arguments in your script).
  • For a detailed FAQ on the Script Packager, please see this article.

Here you'll find a video walk-thru of the feature explaining most of what was stated above...

Be the first to comment
Showing 1 - 5 of 5 results

Top Contributors

Talk About K1000 Ticket Rules