15 replies to this topic

[ViroMan]

The following links will help you in creating scripts and APMs for the current generation of APUP and Autopatcher and will also let you understand the process that the programs go through to do what they do. Its a bit to read but, its actually fairly simple.

http://www.autopatch...loper_docs.html
This will help you understand a little about how apup works and a bit on how to create script files.

http://www.autopatch...APM_Format.html
This goes into detail about how to create APM files. You will need to read this one and the first link(chapter 5 and on) in order to make custom scripts.

http://www.autopatch...ease_Notes.html
This is the list of commands that work with Autopatcher and a description of what they do as well as exit codes and shortcuts.

http://www.autopatch...fice_GUIDs.html
This will help you how to detect MS Office and its addons.

Here is an example script..
http://www.autopatch...20120404.script

And an example APM that this script needs.
http://www.autopatch...st_2010_x64.apm

Edited by ViroMan, 22 May 2012 - 11:41 PM.

[TheArkive]

Question: are the APM files downloaded from www.autopatcher.com? Or are those actually generated somehow?

Question: What are the RTI files and are they downloaded or automatically generated?

Question: (this one is specific)
Regarding the Office 2007 SP3 script I have the following observations:
1) KB2526086 (SP3) and it's download is listed nowhere (i assume this is because it is assumed it was manually downloaded?
2) The APM office_2007.apm seems to be the main APM for the SP3 release. Should it contain reg keys to identify if SP3 has been downloaded?

Question: It seems that you bundle the updates with Office 2007 with the actual Service Pack update itself. I say this because I also downloaded the SP1 and SP2 addons pack for Office 2007. SP1 was actually downloaded as a part of the SP1 addon pack.

For consistency (in my opinion) it would make sense to put the Service Packs as their own downloads, and then to require a reboot for the rest of the updates, or to include the Service Pack and all the latest updates for that service pack (if it is possible to install the service pack without rebooting and then install all the updates and then experience no errors).

I'm just a little confused how the SP1 addon pack includes the SP1 update file, but the SP3 script does NOT include the SP3 file and does not include the reg checks for it either.

Did the SP3 link change maybe?

=======================================================================

At this point I'll just be doing trial and error until I figure it out. The current scripts are a bit confusing. I'm going to try a solution that involves always using a "clean start" so all files will be downloaded regardless. Once I get that done, I'll try the file checking. I still got lots to learn.....

[_def_x_]

TheArkive said:

Question: are the APM files downloaded from www.autopatcher.com? Or are those actually generated somehow?

Both. You will create em for each update, you will zip em up in a 7z file and then upload them to the server - see any script, at the end of a list of apm files - DownloadFrom=http://www.autopatcher.com/releases/office2007/office_2007_critical_glb_20120313.7z

Just grab an existing apm file or 2, remove all the details inside, use these as templates. Make sure to use a smart naming scheme so the file and folder match, just be consistant and clean if possible... see the docs

kb123456_office2007_sp3.exe - the original file.
kb123456_office2007_sp3.apm - the apm file, the exe dropped and .apm added.
kb123456_office2007_sp3.apm_files - notice the underscore?

Sometimes the file will allow for it, sometimes you will need to be creative. Here's a couple raw templates (apm, script) to look at - http://www.autopatch...dpost__p__15374

TheArkive said:

Question: What are the RTI files and are they downloaded or automatically generated?

The RTI tool will create a file (.rti) to sign the release, to make it official. You (?) will do this after the release looks good. It isn't important when building a new script. Without the .rti file the release will show unofficial. You would need to be a team member before getting the tool, this may have changed.

TheArkive said:

Question: (this one is specific)
Regarding the Office 2007 SP3 script I have the following observations:
1) KB2526086 (SP3) and it's download is listed nowhere (i assume this is because it is assumed it was manually downloaded?
2) The APM office_2007.apm seems to be the main APM for the SP3 release. Should it contain reg keys to identify if SP3 has been downloaded?

1) In most cases when you see sp3, sp2, etc - this is a requirement, it must already be installed on the users machine. It is up to the release manager to include the service pack or not in the package - in most cases no, too big. A service pack would be an addon, another script altogether. I'll repeat this again, make sure that no other update is getting installed if you're updating a machine to the next level service pack - do this first, reboot!

2) See the docs The apm files you mention are categories, and the best way to see how this works is to start clean, no other files except the 3 apm files listed here in the \modules folder - office_2007.apm, office_2007_moc.apm, office_2007_viewers.apm - Mess with the dates, notice how the categories change order. Also, look at the categories, notice no parent, the other apm files will list one of these 3 as parent - pay attention to this. Did I mention, see the docs When you have a few apm files (parent categories) in the \modules folder fire up AutoPatcher, experiment.

TheArkive said:

Question: It seems that you bundle the updates with Office 2007 with the actual Service Pack update itself. I say this because I also downloaded the SP1 and SP2 addons pack for Office 2007. SP1 was actually downloaded as a part of the SP1 addon pack.

The scripts may not be consistant here, if the service pack is small enough to bundle it may be a good idea, normally it is simply a requirement. If the service pack is not an available addon package, there may be links to the service pack - see the Windows XP and Windows 7 hotfix depot pages.

If you bundle the service pack make sure the user installs only the service pack, reboots, then proceeds with additional updates - see update detections for help with prerequisites, the docs .

TheArkive said:

For consistency (in my opinion) it would make sense to put the Service Packs as their own downloads, and then to require a reboot for the rest of the updates, or to include the Service Pack and all the latest updates for that service pack (if it is possible to install the service pack without rebooting and then install all the updates and then experience no errors).

I like your first idea, the service as a separate download, an addon pack.

TheArkive said:

I'm just a little confused how the SP1 addon pack includes the SP1 update file, but the SP3 script does NOT include the SP3 file and does not include the reg checks for it either.

Did the SP3 link change maybe?

AutoPatcher needs the help of volunteers, everyone has their own way, again, they're not always consistant. See what you think, get the size, get additional opinions. In some cases it may be easier to offer the link to the user rather than trying to find a detection that works with AutoPatcher, this can really be problematic - do you want the responsibility

=======================================================================

TheArkive said:

At this point I'll just be doing trial and error until I figure it out. The current scripts are a bit confusing. I'm going to try a solution that involves always using a "clean start" so all files will be downloaded regardless. Once I get that done, I'll try the file checking. I still got lots to learn.....

Build a package a few files at a time, run AutoPatcher to at least see if the update is visible, the title and description are good - trial and error. Again, read the docs fully, for both the scripts and apm files, and look at some existing scripts.

Edited by _def_x_, 07 May 2012 - 02:36 AM.

[ViroMan]

A very thorough explanation, Thank you def x. Your link at the end doesn't work though. Did you mean to post the nova.zip?

[_def_x_]

ViroMan, on 07 May 2012 - 02:15 AM, said:

A very thorough explanation, Thank you def x. Your link at the end doesn't work though. Did you mean to post the nova.zip?

Bummer, did the zip file get removed? I guess the pages can be loaded and saved, just thought the zip might be easier

[ViroMan]

I have the zip I will load to the server and relink your link.

ohh well you got rid of the link...

http://www.autopatch...uments/nova.zip

Edited by ViroMan, 07 May 2012 - 05:32 AM.

[click-click]

Take note that we are trying to get away from have a single file directory for each fix to cut down on the directory clutter. For example, for dotNET there are only three folders for all the dotNET fixes.

dotNET-x64_files							  
dotNET-x86-x64_files						  
dotNET-x86_files												

[TheArkive]

Ok thanks guys. Formulating my main question was a bit tough, but you guys answered a lot. The main thing I needed to know was "how do you guys do things now" as far as service packs and that pretty much answers it.

=========================================================

But I have a question about this:

click-click, on 07 May 2012 - 10:59 AM, said:

Take note that we are trying to get away from have a single file directory for each fix to cut down on the directory clutter. For example, for dotNET there are only three folders for all the dotNET fixes.

dotNET-x64_files							  
dotNET-x86-x64_files						  
dotNET-x86_files												

I understand the desire to keep things clean, but in my experience, mess is unavoidable. You either have mess in the files, or you have mess in the code. Messy files are easier to organize too. For the sake of completeness, how about keeping different product updates totally separate? Such as:

- Service Packs
- Updates for service packs
- Dot Net core/initial releases
- Updates for Dot Net releases
- Any other core/initial release
- updates for other core/initial releases

The only reason I can think of to include an initial/core release with the updates is if a reboot is not necessary. But if a reboot is necessary and the initial/core release is separate, you won't have as much code to dig through to keep the package up-to-date.

===================================================

I know this is more a matter of policy rather than coding, that's why I wanted to bring this up first. The way I see it, if there is some kind of way to identify a service pack, or some other core component that would require a "one file install and require reboot" within the APM files, then that would allow the scripts to be more complete. EDIT : And if that can be enforced by how things are installed by AutoPatcher.exe then that would be preferable. I'll experiment with it too and see if I can get it to work as intended with the framework the way it is. I'll also see if I can find the required Reg Keys for those troublesome installations. @ _def_x_: I'll gladly take on that responsibility!

Please let me know your thoughts, and if you guys have any past experience that gives a good reason to leave the organizing up to code rather than up to the folder structure, I'd sure like to hear it so I can re-gear my way of thinking without wasting time trying to re-invent a wheel that will break anyways

The main reason I feel this way is that I don't see any reason to download 2 service packs for the same product. Either stay with the old, or go to the new. I'll see if I can use the APM files to check for other updates in a way that service packs will override each other according to which one is later. That would fix the issues of downloading multiple service packs if someone wants to horde updates

Edited by TheArkive, 07 May 2012 - 12:47 PM.

[click-click]

TheArkive, on 07 May 2012 - 12:35 PM, said:

I understand the desire to keep things clean, but in my experience, mess is unavoidable. You either have mess in the files, or you have mess in the code. Messy files are easier to organize too.

Sorry, I have to disagree with that. My experience is just the opposite. It is much easier and less error prone when updating apm and script files if you have a clean structure without the clutter. When you come right down to it, apm and script files is the code you are talking about and the cleaner the structure, the cleaner the code. The manual work involved to update AP every Patch Tuesday is very time consuming and having a mess to deal with each time does not help.

[_def_x_]

TheArkive said:

The only reason I can think of to include an initial/core release with the updates is if a reboot is not necessary. But if a reboot is necessary and the initial/core release is separate, you won't have as much code to dig through to keep the package up-to-date.

You can easily have both a full installer (.NET 3.0) and updates for both 2.0 and 3.0, they are maintained by the use of detections - see the docs above. As an example, only 2.0 updates will show up in AutoPatcher when the DotNetFramework=2.0 is used as a prerequisite for any 2.0 update. Those updates that apply only to .NET 3.0 will use DotNetFramework=3.0. The same for service packs, updates for XP SP3 only will have listed WindowsVersion=XP_SP3_X86, all other updates will be invisible.

If you know what you're doing you can use a few specialized detections - see 9.7 Custom dependencies in the docs. If you use a specific dependency for an update, if the dependency is not met the update will not load on a system that does not meet the requirement - no IE7 (all IE7 updates will remain hidden), no .NET 4.0 (all 4.0 updates will remain hidden), except a full installer of course, assuming all other dependencies are met to properly install .NET 4.0 - correct OS, etc.

The moral of the story, if you properly create an apm file, when you update a machine, after reboot a whole new group of updates should appear, say after you install IE7. As well, all the other updates should also appear blue (installed) and unchecked or invisible.

TheArkive said:

@ _def_x_: I'll gladly take on that responsibility! Posted Image

You may have missed my point What I'm getting at is if you create a bad apm file and a user iborks their machine, come into the forums and give you hell, this gets old real fast. I was simply saying that for something as important as a service pack install (and all the potential failed installs) it may be wiser to have the user install it on their own then come back and download the proper release. Just MO

Again, see the second link above for details about getting updates to show or remain hidden depending on the system AutoPatcher is run on.

Also, don't reinvent the wheel, make sure you're on the same page with the other teram members, show them your script, they will approve your idea or send you back to make corrections, messy code and messy folder construct is very time consuming to fix, get the idea down first on how you want to design the release, get approval then move ahead.

[_def_x_]

Ditto to post #9, unless you've maintained a release, or spent hours hunting down problems, you've not walked in the same moccasins

It's doable to have all (or most) executables in a single folder, the only issue is to make sure that all the files have a different name, if there should be a collision, have the script rename the new file - see http://www.autopatch...20120404.script

I would try and get the apm and exe under the same name... seen here
vcredist_2005_x86.apm
vcredist_2005_x86.exe

[TheArkive]

@ click-click & _def_x_: I understand. I'll just keep on with that way of doing things then! I just wanted to voice my idea and see where it went. I had no intention to jump right in and play with the "big boys". I know I need to earn my way and show that I know what I'm doing and that I'm able to handle the work load.

Was there ever any intention to include the service packs and have AutoPatcher.exe handle mandatory reboots? Or is that always going to be assumed to be a requirement for the user to do on their own? It seems that the "opinion" is being expressed for users to do that on their own, but no one has really told me "this is the way we do it, and that's final". I'm looking for that kind of guidance because of how flexible your framework is. There are many ways to approach any one problem thanks to how AutoPatcher was coded.

Next question:

When trying to detect Office 2007, which method would be preferred:
1) The [OfficeComponents] section set all to "12" and OfficeComparison=JUSTONE
or
2) [SystemComponents] and ComponentFile=blah.dll and ComponentVersion=>12

I think I've heard of product releases that include just one of the products. If that's the case are these still considered installations of the Office Suite?
Are there any particular advantages over 1 vs 2 or vice versa?

=================================================

My final comment/question:

I didn't notice any option in the APM docs that would operate like this:

Solo_Install_Required=True/False

An option like this would allow AutoPatcher to check for conflicts. If 2 updates are selected that have an option like this set as TRUE, then there must be a HALT and the user must choose which packages to uncheck before the install continues. Was there ever any plan to include this kind of functionality? This would allow the Service Packs to be bundled as part of a package (as far as I can tell).

I like complete collections, but I understand why you guys prefer for a user to install the service packs themselves (it solves a lot of potential issues).

==============================

EDIT: Sorry, another policy question:
What would be the order of operations for trying to contribute Scripts and APM files? The scripts pretty much have to be approved by you guys, and I can create APM's to test with AutoPatcher.exe, but I can't complete the script until the APM's are loaded on your servers ... a slight catch 22

Edited by TheArkive, 07 May 2012 - 02:16 PM.

[Whatacrock]

It seems that everbody has their personal opinion to the folder issue.. have enough troubles with simple errors with folder names like missing an underscore and the likes,run a test with AP only to find it displays and error and the search goes on. I am on the fence in this issue as either is fine as long as consitiency is maintained in file/apm naming

Have to agree with the amount of time it takes doing an update of a release and some detections are a real pain as the support or security bulletin make no mention(they expect you to know what is required) of the prerequisites.Found this out the hard way trying to do an update in Win XP x64 and after reading 4 or so security/support bulletins was still none the wiser.(A 90minute waste of time)

My 2 cents worth.

Edited by Whatacrock, 07 May 2012 - 02:32 PM.

[ViroMan]

I may be the lead developer at the moment but I rely on my fellow team mates opinions for direction. I don't personally want to include any SPs as a download since I have seen on a few occasions a SP actually screw up a computer. I wouldn't want someone to blame that on us. If enough people want it we can put it in though. The customer is always right.

Quote

I didn't notice any option in the APM docs that would operate like this:

Solo_Install_Required=True/False

This is do able. A quick 10 mins of code could put this in apup2 but, it would make using Apup2 mandatory since we would need to alter a script adding a command not supported in apupv1. While I feel Apup2 is ready for this(except the download window still being glitchy) I am not sure of the opinion of everyone else yet.

Quote

When trying to detect Office 2007, which method would be preferred:
1) The [OfficeComponents] section set all to "12" and OfficeComparison=JUSTONE
or
2) [SystemComponents] and ComponentFile=blah.dll and ComponentVersion=>12

This is up to you. I prefer registry checks myself because I know the code for it is fast. The first one is a registry check BUT, it is a hardcoded one that may not work. We have been seeing some of the hardcoded checks fail recently for newer products like the DotNetFramework= is fairly picky about what is in there. I would go with #2 because it will always work.

Quote

What would be the order of operations for trying to contribute Scripts and APM files? The scripts pretty much have to be approved by you guys, and I can create APM's to test with AutoPatcher.exe, but I can't complete the script until the APM's are loaded on your servers ... a slight catch 22

Not really you can make the apms and the script and test them yourself. Apup allows you to specify a local script file for using instead of downloading one. The command would be like this

apup2.exe /log:2 /localscript:autopatcher:\Temp.script

that is for apup2 mind you. Otherwise its

apup.exe /log /localscript:\Temp.script

[TheArkive]

Sweet thanks for the feedback. I'm off to experiment!

EDIT: For now I'll stick with APUP v1, unless there is an urgent need to test something in APUP v2, then please let me know!

EDIT2: Btw, I came across this page: http://support.microsoft.com/kb/928116
It seems this would be rather helpful for reg checks on Office 2007 in Win7 (x86 & x64). I imagine writing one script for all applicable windows versions is the main issue anyways right?

EDIT3: Has anyone ever known a major earlier version to be updated past the next service pack version as a result of other updates? For example, if v12.0.1 is SP1 and v12.0.2 is SP2, has it ever occurred that SP1 could be updated up to or past v12.0.2 with only SP1 updates and still be SP1? (sorry if this is confusing, I can't imagine this sort of thing ever happens, but if it did that would be good to know!)

EDIT4: Is it possible to use environment variables in the paths? Or is there any other equivalent that can be used?
Found #4 in the docs. Sorry! Though what about "Program Files (x86)" ??? Is that one doomed to be laid out as the full path always?

Edited by TheArkive, 07 May 2012 - 08:24 PM.

[ViroMan]

I found more the older documentation that still applies... will post it up in a few mins.

Edit: updated with MS office GUID guide... this should help you Arkive

Edited by ViroMan, 23 May 2012 - 12:00 AM.