[wpkg-users] Orphaned packages (patches, settings and service packs)

[Rainer Meier]

Hi Mike,

Please reply to the list too.

Mike Moynihan wrote:
> I understand that these orphaned packages would be removed from the
> client, if I remove them entirely from the host.  But, this only works
> if I am actually removing the software package entirely from wpkg control.
>  
> In my case, I am wishing to remove say... Microsoft Office from all
> machines within a group.  I currently have an SP3 package and a few
> tweak packages.  I have them as separate packages to ensure that they
> "check" and install as needed.  Neither of them have a separate
> uninstaller, and when the primary package, Microsoft Office, is removed,
> all that was installed by the add on packages get removed also.  This
> leaves the add on package orphaned.

Actually what you're saying is that you misused/misconfigured your WPKG package
tree. It seems you added update packages as independent packages without
specifying dependencies between each other while they actually depend heavily on
each other (I wrote this already in my previous message).

If you specify a dependency of your "sp2" package to the "basic" package, then
you would not have this problem because WPKG would first remove the "sp2"
package before removing the base package. In addition if you specify such
"add-on" or "update" packages independently you should specify checks for the
update/add-on instead of the same ones as the base package has.
For example if you install Microsoft Office 2007 the "SP2" package should check
file versions (or use appropriate checks to verify if SP2 is actually
installed). If you specify an uninstall check for "Microsoft Office xxx 2007"
WPKG will obviously not be able to verify if SP2 is installed, but just if
Office 2007 is installed.

For Office 2007 I suggest the following for example:
- Use only one "office" package
- specify an uninstall check for "Microsoft Office xxx 2007"
- to allow WPKG to really verify that updates are applied properly you might
specify several file-system checks to verify file versions

Now use the following <install... /> commands:
- install basic office 2007 (you should integrate SP1/2 files into basic
installation directly to quickly install Office 2007 including the updates for
new installations)

Use the following <upgrade... /> commands:
- install SP1 silently
- install SP3 silently

Now assume that SP3 is appearing. >ou just need to add a new command to the
upgrade command list (re-applying SP1/SP2 is usually not a problem) so your
upgrade commands should do the following:
- install SP1 silently
- install SP2 silently
- install SP3 silently

Then increase the package revision number.

In case you correctly integrated SP3 into your Office 2007 software repository
then new installations will directly get SP3 and existing installations will
(re-) apply SP1, SP2 and SP3.


So you only need one single Office 2007 package. From my point of view it's
anyway a bad idea usually to create independent packages for updates. As a rule
of thumb I usually create one single package definition per application.


> I do not want to remove the Microsoft Office package from my main
> package list, as I have many other hosts that contain it in their
> profiles.  I can not run "remove" for these orphaned packages, and it
> would not work anyways, since each "check" portions fails.
>  
> Every time I run WPKG.js on these machines, these "check"s are
> performed, and these packages are left orphaned in the client wpkg.xml.
>  
> I have thought about doing a revision of these, but since they are in
> use by other clients to wpkg, I have to keep the "check" and the
> installer the same.  Putting in a dummy remove doesn't help, since the
> check fails for the orphans.
>  
> I could edit the wpkg.xml on each client, but I would hope there is a
> better way to clear these.  Am I missing a way to clear these orphaned
> packages that already works?
> I have some ideas for wpkg.js mods, but wanted to see if there was a
> current way to handle this issue before I go there.

As I wrote you seem to have chosen a strange way to deploy Office service
packages. So there are several ways to fix it up.

1. Use approach I outlined above
First of all just remove your SP1/SP2 packages completely from your server-side
package database.
Then enhance your office basic package with the commands I outlined above and
increase its revision number.

On next reboot your clients which fight with orphaned packages will try to
uninstall SP1/SP2 but will fail again but then just remove the packages from
local wpkg.xml because it detects zombie packages.
Clients which still have Office assigned tho their workspaces will try the same
(remove SP1/SP2) but as it seems you did not specify any commands here WPKG will
not execute anything, print that the package is still installed and remove the
"zombie" packages exactly as for the other PCs (with the difference that Office
is still installed here).

On the clients where your office package is still assigned it will go through
the update procedure and therefore execute your SP1/SP2 upgrade you just added.

This way you can clean up all clients. All clients will remove the SP1/SP2
packages (without actually executing commands if you do not have remove commands
in your package definition). Clients which do not have the basic office package
assigned will be clean afterwards. Clients with office package assigned will
execute the upgrade commands (well, in your case you might leave them empty if
you're sure all clients got SP2 already).



2.
If you want to keep your SP1/SP2 packages you might just fix them up to work
correctly. First of all make sure the packages contain correct checks to ensure
that SP1/SP2 is installed. This might require some scripting or just to verify
some binary (word.exe, powerpoint.exe...) version verification.
Then add a package dependency - SP1 depends on the base package and SP2 depends
on SP1 package:

<base office package>
   \- SP1
        \- SP2

Then increase the revision number of SP1/SP2 package.

Actually I did not try but knowing WPKG functionality the following is expected
to happen:

On clients where your orphaned WPKG packages exist:
- WPGK will try to upgrade your SP2 package and as it depends on SP1 it will
first upgrade SP1 - as this one depends on the base package it will first
re-install office.
- After installing office base package, applying upgrade commands of SP1 and
upgrade commands of SP2 (upgrade commands should be equal to the install
command, simple calls to the silent SP installer) you end up with a fully
installed Office 2008 SP2 on these machines.
- Now (still within the same WPKG run WPKG will start to remove the packages:
  - SP2
  - SP1
  - Base office package

At this step it is obvious that SP2 really needs to check file versions or use
different mechanisms to verify that SP2 is uninstalled properly. In case you
just check for the Office 2007 uninstall entry this will still be there after
the uninstall procedure will be regarded as "failed" (in this case WPKG cannot
proceed removing SP1 because SP2 is still installed).


As uninstalling service packs is not very easy it's usually not done. If you
specify an uninstall command within the SP2 package which completely removes
office it might work as well but its for sure not clean packaging because then
you would have three packages which all remove software which is deployed with
others (SP2 uninstall would remove SP1 and base office software).

This again is a reason why you should use only one single package for each
application.
I really recommend switching to the one-package approach as outlined in method 1
above.

br,
Rainer