How do I remove old SCCM deployments from client's registry?

RhoSysAdmin
RhoSysAdmin used Ask the Experts™
on
I'm using SCCM 1810 to push Acrobat updates to a set of Windows 10 computers.  8 of 12 work just fine.  4 of 12 show up in the error tab and in the success tab.  The error is the same for all 4 computers

0x87D00324 (-2016410844)  The application was not detected after installation completed.


I know the update installed b/c I visually confirmed it on each computer.  The other 8 computers report back success.  

I've tried updating the content of the deployment, then forcing a machine policy action on the clients.  

I've tried a full SCCM policy reset (WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE).

I've tried removing and re-installing the SCCM client (but I think I forgot to delete the "CCM" and "CCMCACHE" directories before re-installing).

I believe the source of my problem is a previous revision where I had the detect clause defined incorrectly.  While I have it correct now (assuming so since 8 of 12 clients can detect), and I don't see any references to the older revisions, I fear the 4 computers have a reference to a old revision buried somewhere.

I saw in a discussion that his errors were due to old revisions of his advertisement, and once he found those in the registry and deleted them, his errors flipped to successes.  My problem is I can't find any reference to my SCCM advertisements in the registry.  I don't know where to look.

Does this (delete old advertisements in registry) idea sound familiar to anyone?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Adam LeinssSystems Administrator

Commented:
Check HKLM\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System

Author

Commented:
I found that registry key, along with a long list of other advertisements, but not the one I'm looking for.  

Where do I go from here to get client and server to agree to just "already compliant" instead of "already compliant" and "Deployment failed"?
Adam LeinssSystems Administrator

Commented:
What does your detection method look like in the application?  Can you screenshot it?

Author

Commented:
Detection Method for Acrobat 2017 application (MSP)
I'm using the MSI for Adobe Acrobat 2017, but detecting the resulting version when the MSP has been applied.

I can tell you that two recent Acrobat 2017 (17.0.0) installs have been properly detected and patched by this same application in the last 24 hours.  My problem appears to be limited to just these four early-adopter SCCM clients that can't shake the fact that they're reporting "Already Compliant" and don't need to report "Unable to detect".

Could it be tied to an older revision of the application?  Would it make sense to delete all my old revisions?  I certainly don't need them.  None of the older revisions show any references, so I don't know if deleting them would do any good or not...
Adam LeinssSystems Administrator

Commented:
Deleting revisions won't hurt, you just won't be able to go back to them.  The other thing you might want to try is another detection method, such as looking at a particular file and what version it's at and see if you get different results for compliance.

Author

Commented:
I appear to have a client side specific issue with these 4 computers.  All targeted SCCM clients show "Already Compliant" - including the 4 "error" clients.  The 4 error clients also still show up as "Already compliant".

I'm searching through the CCM log files on one of the clients, and not finding the error codes.  Everything I've found in the logs (so far) shows the client thinks everything is good.

Are these old "error" deployment records on the server side, and not on the clients?

btw, should I be concerned I don't see an C:\Windows\CCM\Logs\AppEnforce.log on this client?
Systems Administrator
Commented:
AppEnforce.log logs app installs, AppDiscovery.log logs app discovery.  If the app is discovered as being installed, nothing happens in AppEnforce.log, so the absence of AppEnforce.log shouldn't be concerning.

I would recommend deleting and recreating the application.  That should create the application with a new GUID and shed any of the erroneous deployment information with it.  Since they all at the correct version of the application, the new application should come back as success for all 12 computers.

Author

Commented:
Looks like the nuclear option was the fix!!  All "already compliant" clients have reported back with the same status.  No has yet to report back with an error.

Thanks for walking me through the steps to get to this point!
Adam LeinssSystems Administrator

Commented:
No problem!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial