Jump to content

Help with autoinstaller framework


sshrum
 Share

Recommended Posts

As I've been doing desktop standardization and desktop support for a handful of the hospitals here in Orange County, I've been using AutoIT to create automated un/installers for the various applications that are in use as documentation is:

1. hard to find,

2. difficult to decipher,

3. easy to lose,

4. hard to take with you to a user's desk, and/or

5. non-existant and only one person knows what to do

Anyways, I write code and I figured I'd make a standard framework script for a automated uninstall/installer package.

Code here

I haven't been using AutoIT long but now I use it everyday. I'm looking for input as to the sort of things that should go here OR to find out that someone else already has one made (or not). Remember this is just the framework for future works that I wrote in like 10 minutes. My main concerns (as you will see) are with UNC shares as most software will reside somewhere on the network.

I'm also looking to *pretty-it-up*. Icon usage, bells and whistles, etc.; stuff like the TrayTip.

Input welcome.

TIA

Edited by sshrum

Sean Shrum :: http://www.shrum.net

All my published AU3-based apps and utilities

'Make it idiot-proof, and someone will make a better idiot'

 

Link to comment
Share on other sites

Your first concern is going to be that you'll need to either map your drives again for the admin user if you have to RunAsSet() or else call the installer from a UNC path if it's on a network share.

Since some installers trip out if they're invoked from a UNC path, drive mapping for the Admin as well might be better for a generic script.

In the past I've made scripts that re-called themselves RunAsSet() the admin user to run the installer, especially if there had to be other chores done like pre-writing a product key in the HKLM portion of the registry to get a silent install.

Since you're not using command line arguments you could use my _RerunAs() UDF, which looks like:

Func _RerunAs($_rerunUser, $_rerunDom, $_rerunPwd, $_rerunErrMsg = 0)
  ; Test if we're and Admin already
   If (Not IsAdmin()) Then
     ; Test if we were called by ourself
      If $CMDLINE[0] = 5 Then
        ; Not and Admin and called recursively if we get here,
        ;  so bail out with an optional error message.
         If $_rerunErrMsg Then
            MsgBox(0, "Error", "The provided user is not an Administrator on this PC.")
         EndIf
         Exit 1
      EndIf
     ; This is the first run of the script and we're not an
     ;  Admin so call ourself recursively as an Admin
     ;  with some dummy args so we'll know we called ourself.
      AutoItSetOption("TrayIconHide", 1)
      RunAsSet($_rerunUser, $_rerunDom , $_rerunPwd)
      RunWait(@ScriptName & " a b c d e")
      RunAsSet()
      Exit 0
   EndIf
  ; If execution reaches this point we're an Admin,
  ;  so set a flag to tell the rest of the script.
   Global $weAreAdmin = 1
EndFunc

The above comes with some caveats:

- It needs AutoIt version 3.1 because it uses a default argument in the function.

- It's intended to be used in compiled scripts.

- You can't use it with a script that needs command line args.

You could use the $weAreAdmin flag to optionally run parts of the script for both the limited user and the Admin user or either.

As a final note, check out AppDeploy if you haven't already, there's a bounty of info there about silencing software installation so that you don't have to worry about catching dialog windows and sending button presses...

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.

Link to comment
Share on other sites

AppDeploy is already in my links area unfortuntely my parousels there haven't mined anything useful (yet).

Good point about installers freaking out on UNC path names thou.

In this regard, I'm coming up with (doodling with the idea of) a package delievery system that would allow the script to download, extract, and run program(s) from the local drive. One of the apps that I have autoscripted is like this and it works great (even for uninstalling). I need to look at all the installs to see how much data I'll need to deal with.

OTOH, I might just define a tempmap setting to define a disposable mapping. :">

Keep the suggestions coming.

Edited by sshrum

Sean Shrum :: http://www.shrum.net

All my published AU3-based apps and utilities

'Make it idiot-proof, and someone will make a better idiot'

 

Link to comment
Share on other sites

I've created 2 frameworks....1 for installs, another for uninstalls.

Scripts here.

Take a look. The installer now handles creation of a temporary drive mapping for installs and allows for the creation of persistent mapping.

The uninstaller uses the windows Uninstall registry to pull UninstallString info (kinda handy).

If I think of anything else or get any ideas thrown my way, I'll update the scripts.

Sean Shrum :: http://www.shrum.net

All my published AU3-based apps and utilities

'Make it idiot-proof, and someone will make a better idiot'

 

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...