Orphaned Deployments

I have been known to say “Group Policy comes without a this may be a career limiting configuration change you are about to make, are you sure!? message.” You can do a lot of things with GP that can cause a ripple effect that you are not prepared for so always be careful, test, then re-test.

With that said, it is also a very predictable system and at Specops we continue to leverage that great predictable system with our solutions.

Recently a Specops Deploy Customer un-linked their SD/Application GPO from an OU. What happens in this scenario?

Managed vs. Orphaned

When an administrator adds a package to their Specops Deploy App GPO they configure that package to behave a certain way. The configured behavior is mostly related to pre-install commands, post-install commands, uninstall behavior and more. The package by itself does not do anything. In order to get a package to a user/computer you create a deployment.

A Deployment can be configured to define additional behavior related to the actual installation of the package. For example an administrator can configure a deployment to ‘Uninstall the package if the deployment falls “Out of the Scope of Management.”’

When a deployment is targeting a computer those deployment(s) will be enacted on that computer and the packages in those deployments will be installed. The deployments will be referenced as ‘Managed Deployments’.

SD Administrators can take a look at managed deployments on client systems in a few different ways. I like to use PowerShell.

Get-ChildItem ‘HKLM:SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Managed Deployments\System’

The above PowerShell command will display all managed deployments on that client for you to review.

If a managed deployment disappears, an administrator deletes a link, a user can’t process the GPO due to a group membership change, or any other reason, the deployment may go to ‘Orphaned Deployments’.

Get-ChildItem ‘HKLM:SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Orphaned Deployments\System’

This means that there is software still on the client system that is no longer managed by the Specops Deploy Application.

This most likely does not cause an issue for administrators, but if mistakes are made, and GPOs are unlinked and deployments are orphaned, when the problem is resolved those applications may want to re-install themselves. That may not be great.

How to Recover From a Mistake

There is a simple way to resolve the issue if an Administrator mistakenly unlinks a GPO. The Managed vs. Orphaned deployments are stored in the Registry on the client as you can see from the above PowerShell commands. Now they just have to move. So, instead of ‘Get-Item’ we can use ‘Move-Item’.

Move-Item ‘HKLM:SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Orphaned Deployments\System\*’ –Destination ‘HKLM:SOFTWARE\Specopssoft\Specops Deploy\client Side Extension\Managed Deployments\System’

Relink the GPO and you should be good to go. As with everything make sure you test out this procedure in a lab. PowerShell is incredibly powerful so be careful. Fat fingers count.

Challenge

Want to take this to a new level? Get computer names from a text file or from AD itself and run move-item from that list. Some complex scenarios can be solved simply if you take the time to learn the PowerShell option.

(Last updated on October 30, 2023)

Tags: , ,

Back to Blog