Dispatches from the realm of I.T.

☰ Menu

Removing software that was originally deployed via Group Policy

Problem: Software that was installed via Group Policy needs to be removed or upgraded and the original policy responsible for deploying said software no longer exists. Furthermore, attempting to remove the software manually via Programs and Features while logged into an account with Administrative privileges results in error messages similar (or identical) to this one:

Even with an “admin” account, the software cannot be removed manually.

Solution: We need to create a brand new GPO for software removal. Before we do, here’s a quick outline of what needs to be done:

Use the new GPO to re-deploy the package (or packages — it is possible to remove multiple packages with the same policy.) Make sure that “Uninstall the applications when they fall out of the scope of management.” is checked on either the package, or the entire policy (or both.)

Use security filtering to target the objects that need to have the software uninstalled. Make sure you read this post first, it might save you a bunch of time and frustration.

Allow enough time to pass for Group Policy to refresh. Alternatively, force a refresh via reboots and/or gpupdate /force

Remove the machines targeted in step #3 from Security Filtering.

Repeat step #5

Let’s get to it then…

Step #1: Locate the original MSI package — read this post — and copy it to an accessible network location.

Step #2: Create a new unlinked GPO.

Create a new, unlinked GPO so that we don’t accidentally apply it to the wrong OU, Users, Machines, etc.

Make sure to give the new GPO a descriptive name.

Step #3: Use the new GPO to re-deploy the package or packages — it is possible to remove multiple packages with the same policy. Make sure that “Uninstall the applications when they fall out of the scope of management.” is checked on either the package, policy, or both.

Configure the new policy to deploy the package.

Browse to the original MSI that was located in step #1.

If you are only using this policy to remove one package, select “Advanced” in this dialog. Otherwise, select “Assigned” and repeat this step for each package that needs to be removed, then skip the next screenshot.

If you selected “Advanced” in the previous dialog, check the box titled “Uninstall this application when it falls out of the scope of management”.

If you are using this policy to remove multiple packages, there is no need to specify “Uninstall this application when it falls out of scope of management” for each package, instead, you can apply it to the entire policy. Right click on “Software installation” and select “Properties”. Check the box “Uninstall the applications when they fall out of the scope of management” in the next screenshot.

Check the box “Uninstall the applications when they fall out of the scope of management”, and hit “OK”.

Close the Group Policy Management Editor when you are done configuring your policy

Step #4: Use security filtering to target the objects that need to have the software uninstalled. Make sure you read this post first, it might save you a bunch of time and frustration.

In the next few steps, I’m going to use Security Filtering to target only the machine that needs this policy. In the examples that follow, the machine name is W7PRO64-STAGING. You could just as easily Security Filtering to filter on a Security Group containing users, computers, or both; or you could target a specific user in the same way that I’m going to target the machine in my example. Just remember that the standard rules about OUs still apply: Regardless of whether you use a Security Group or whether you target the object (user or computer) directly, the targeted object needs to exist within the same OU as the policy is linked. Also remember that if your policy is supposed to target User objects, then any settings need to be configured under User Configuration; if it targets Computer objects, then your settings need to be configured under Computer Configuration.

Click the “Add…” button to add the targeted objects (Users, Computers, or Groups)

We do not wish to target all Authenticated Users in the OU that this policy will eventually be linked , so we need to remove the Authenticated Users group from Security Filtering.

… But, due to the previously mentioned post, the Authenticated Users group does require Read access to this policy. So click on the “Delegation” tab, click “Add”, type “Authenticated Users” into the box titled “Enter the object name to select”, click “Check Names”, then click “OK”.

Make sure that “Read” is selected in the “Permissions” dropdown box, and then click “OK”.

You should end up with something like this

If you want to be certain your permissions are correct, click “Advanced”, then click “Advanced” on the dialog that appears, and make sure that your targeted Users, Computers, or Group, have “Read” and “Apply” permissions and “Authenticated Users” only have “Read” permissions.

One way to tell if the MSI deployed by your “removal policy” was actually re-deployed is by checking the the install date (… found in the “Installed On” column) in Programs and Features — it should be updated to the date that the software was re-deployed.

Some things can go wrong here:

Group Policy might not refresh for a long time, or not at all. Try enabling the following two items on the policy (if it is being applied to a Computer). These settings need to be applied to the Computer, so you may need to create a new policy and link it to the OU containing your targeted Computer objects.

Navigate to Computer Configuration\Policies\Administrative Templates\System\Logon and set Always wait for the network at computer startup and logon to Enabled

Navigate to Computer Configuration\Policies\Administrative Templates\System\Group Policy and set Configure software installation policy processing to Enabled and check both Allow processing across a slow network connection and Process even if the Group Policy objects have not changed

The MSI you thought was the “original” turns out not to be, and you end up with something like this in Programs and Features:

The software contained in the MSI deployed by your “removal” policy may have been the same version, but the MSI was not identical to the original. In this case, you need to try to retrieve the original MSI (… for the software that you were trying to remove in the first place) from a machine that still has the software installed.

This happened to me once when I tried to use this technique to remove Google Apps Sync. Instead of retrieving the original MSI (as per my instructions, linked above in step #1) I downloaded an MSI from Google that was the same version of the software I was trying to remove, taking a gamble that the downloaded MSI might be identical to the originally installed one. You see the result. If this happens to you, don’t panic. Just proceed to step #6 as if it never happened. Once the duplicate copy has been removed, you can repeat step #1 (or actually do step #1 in case you skipped it the first time, which may be the reason you’re in this mess), skip step #2 (because you already have a policy that can be re-used) and then complete the rest of the instructions, starting from step #3.

Navigate to the OU in which the policy is linked, right click on the policy, and select “Delete”. When prompted with the following: “Do you want to delete this link? This will not delete the GPO itself.” Click “OK”.

Remove the targeted group from Security Filtering. When asked “Do you want to remove this delegation privilege?” Click “OK”.

This will force an “out of scope” status, and the software should be uninstalled after Group Policy refreshes.