3 replies to this topic

[Kage_]

Hello,

While looking for some info for a Microsoft update I ran across yall and thought that AutoPatcher may be a solution that I have been looking for. To start out let me provide some details.

I support multiple systems ranging from XP SP1 to SP3, 2003 No SP to SP2, Vista SP1 and SVR 2008 SP1. The systems run custom software that is only qualified to run on the specific OS SPs that are tested for that specific version of the software. The manufacture of the software releases approved Microsoft updates each month that can be installed on the systems. Depending on the version of the software that is running determines what OS service pack is installed on that machine.

Currently I'm using a set of menu driven cmd files to automate the install of Windows updates using the build in switches for each of the updates. When updates are released I update the cmd files and then put the cmd files and updates on our network for everyone in our office. When run, the user selects the OS version to install the updates on to, a basic version check is then done to verify the correct current OS, and then the updates are installed. During the install process the script checks to see if the hotfix is already installed and if so it skips it.

So the questions I'm attempting to answer are:

1. Will AutoPatcher allow me to install only the updates I specify via some predefined method?

2. Can updates be installed with minimal user interaction? A basic window or command line.

3. How does AutoPatcher handle applying updates to older service packs?

Sorry if these question have been answered before. I looked through the FAQ and the doc pdf, but I didn't see any info related to these questions. If any additional details are needed please let me know and I'll do my best to answer them.

Thanks!

[_def_x_]

This is my opinon...

Lets start with what sounds like a network share. You seem to have a strategy that already works, from my point of view
trying to get AutoPatcher to smoothly work in your network may be more difficult.

AutoPatcher & Networks

Bottom line, AutoPatcher, APUP, networks, and proxy use never really developed. The developer of AutoPatcher has long
since moved on to other projects.

Q1...Yes, you can select only the updates you want.

Q2...Yes, this is the primary reason/use for AutoPatcher.

Q3...This may be problematic for you, at least with XP x86, SP3 is the target SP level with few updates for SP2, nothing for
SP1. An update may actually install on SP1 but it wont load in AutoPatcher because there are no detections for SP1.

You sound able enough to create your own apm files where you could create a custom release but it may be more work than
continuing to run your scripts. In fact, you sound like someone we could use around here - haha!

AutoPatcher can create an "answer" file that will load a custom set of updates "pre selected" by the file creator. So, you have
a large number of updates in your release, you can select only those updates that apply to a given circumstance, "OS", "User",
"Software App". When AutoPatcher is run it will ask you "Do you want to load the answer file for Bob, XPSP2, AppX, or no answer
file - it really does come in handy.

Unfortunately, we are at a difficult place at the moment with both AutoPatcher and APUP needing work done to their functionality
along with a scarce group of release maintainers (developers) - so the project's future is uncertain at the moment.

Again, these are my opinions. Cristiano may have more information for you should he choose to chime in.

Mike

[Kage_]

The updater will mostly be run from a usb drive, hard drive, and occasionally from a mapped network drive.

How does AutoPatcher know what to install? Can I just throw the updates into a specific directory and then tell it to install everything in that directory?

I may have answered question two on my own. From poking around in the apm files it appears that the install files are defined in the [Installation] section. This was looking at one of the apm files from the modules\AddOns.

The method I'm using now does work, but I'm always on the lookout for something to simplify the management of our repository.

Edited by Kage_, 22 June 2009 - 06:23 PM.

[_def_x_]

There are 2 programs (apps) that comprise the update process, APUP and AutoPatcher.

APUP (apup.exe) requires a direct internet connection, no proxy, etc, an unhindered connection to the world wide web.
APUP will download from autopatcher.com, but mostly from microsoft.com, and a few others depending on the release.

AutoPatcher (autopatcher.exe) is the GUI that provides the interface to chain the updates together for installation.

I would say download a few release packages and start experimenting, you may discover a way to get AutoPatcher and
APUP to work better in a network environment - who knows...

To get a look at the script, run apup, make your selection, begin the download process, and before you click the "Finish"
tab, look in the "temp_bin" folder for the *.script and "copy it to a folder of your choice to look thru it (using notepad).

Once you hit "Finish" the "temp_bin" folder is gone and all the contents (this is by design).

Have you tried Offline Update?

Yes, it is the detections in the apm file that lets AutoPatcher know what updates should be loaded. Like I said before,
if you could determine if Autopatcher and APUP can work in your environment, you have the skills it seems to customize
a release just about any way you need, many users have done just that. The only problem might be the environment in
which AutoPatcher and APUP are run. It may be easier to simply start using the apps and report any errors.