Need Help with Removing applications from client PC's

  • Thread starter Thread starter Michael.van.Leyden
  • Start date Start date
M

Michael.van.Leyden

Hi,

I was to upgrade a application for a large OU. It was just a question of
replacing a msi for a newer msi. When removing a msi I choose the option
'Allow users to continue to use the software, but prevent new
installations'. After replacing the msi with the newer version I checked
to see if the application (new msi) was rolling out correctly. It wasn't
installing correctly on all PC's. On some PC's the new version of the
application could not rollout unless the older version was removed first.

Now I have a problem, I dont know how to remove the older version of the
application anymore, does someone know a method to be able to remove an
application once the option 'Allow users to continue to use the software,
but prevent new installations' has been used?

There are too many client computers affected to remove the application by
hand.

Regards Michael.
 
Michael,

Sure you'll hate me for saying this, but... this is exactly why you lab
something or at the very least try it on a smaller test OU. You NEED to do
this every time, unless your environment is small enough to do it by hand or
the consequences of failure are acceptable.

So, I am guessing that you deleted the whole thing rather than just
disabling it. This means that you can't assign the new package as an
upgrade or replacement to the old one. This would have been the preferred
way to do this -- testing it in a Test OU subordinate to the real parent
one.

Other than doing some complicated scripting, I would suggest the following:
1. Create a new OU subordinate to the one that contains messed up clients.
2. Change the GPO that distributed the NEW package to remove the package
when it falls out of scope.
3. Move 5 each of computers that have the old package, the replaced package,
and no package at all into the new OU.
4. Do not allow inheritance in the new OU of the upstream GPOs (the new
installs fall out of scope)
5. Deploy the OLD package again to the sub-OU... Hopefully, it will
re-install and overwrite the installation in the old ones and the botched
ones.
6. Set that package to uninstall when it falls out of scope.
7. Move the computers back to the parent OU
8. Destroy the test GPO and OU

This is not a guaranteed fix and it will be labor intensive with the
rebooting and updating of the security policies you'll have to do. Get them
into a lab, or do it over time a few days. Bite the bullet and explain the
process to your management to get their buy in. Its better to look
responsible than to have them get all kinds of complaints without warning.

What the net effect you are shooting for is to reinstall the old package
over itself while verifying that you can do a backwards migration to the old
version from the new. Then, you'll let the version fall out of scope,
uninstalling itself finally getting only the new package.

The downside is that your users are gonna hate you for a while... You may
want to figure out the down time you are expecting, double it, then multiply
that by the mean hourly rate of your employees. You might find that the
process of jumping through all of this is more expensive than hiring some
college kids or temps part time to re-install the app manually off hours.
 
Back
Top