Monitoring of an application tells me that the installation was successful, but after a while, the same monitoring tells me that the installation that was successful now got a lot of errors.

This is the monitoring windows telling me that Elements have a compliance % of 57,1, and it was about 98-99%...

As you can see, Ive got 92 clients that are successful and 69 errors, which is wrong

And the correct amount of errors are 2 computers that failed.

Ive checked some of the computers that get this deployment, and who is not located in the successful status, and they all got Elemets installed.

Why do I get all these errors when the installation is successful?
I find it very strange that its random which computers that report successful, and after a while then reports error(but nothing is logged in the error log)

• Moved by Joyce Wang [MSFT]Microsoft employee Tuesday, June 18, 2013 6:06 PM

My team has
been working a similar issue where our application compliance was slowly changing from success to error using SCCM 2012 (no SP1). After 3 weeks of
working with Microsoft we finally resolved this issue. We are using task sequences to deploy application stacks. There is a known bug that causes issues
when changing the task sequence to update the rev of an application in it (allegedly fixed in SP1). The TS was still referencing an old version of the application despite our updates and from the console you can't tell. When the machine runs its policy evaluation and hits one of these apps it stops fails the evaluation of all applications. So, App "A" has the issue in the TS, you deploy App "B" and initial compliance looks good until the App Policy runs and hits the issue for App "A" and report an error for your App "B" deployment

CIAgent.log
(The prod version of this app is "12", below you can see the TS was still using version "10"

CIAgentJob({BB81C59E-0D68-4F80-8C26-F3672FDA6993}): CAgentJob::VersionInfoTimedOut for ModelName
ScopeId_FBAD85CC-8425-4A82-9A2A-A69D6941A909/RequiredApplication_826f927c-b7b4-446b-9767-9e03529677ff, version 10 not available.

CCIInfo::SetError - Setting CI level error to (0x87d00314). <- this repeated many times

VersionInfo ModelName=ScopeId_FBAD85CC-8425-4A82-9A2A-A69D6941A909/RequiredApplication_826f927c-b7b4-446b-9767-9e03529677ff,
Version=10, IsVersionSpecific=TRUE timed out

The results of this SQL query give you a link to XML to reveal the
friendly name of the offending application.

select top 10 * from CI_ConfigurationItems where CI_UniqueID like '%/Application_826f927c-b7b4-446b-9767-9e03529677ff%'

Once we had this we removed it from the task sequence then added it back in. Once all the clients check in and run the App Policy again they will see the update and magically all the errors for unrelated applications changed from error to success

• Edited by Alan Carita Monday, June 17, 2013 2:18 PM typo
• Proposed as answer by Joshua Knorr Tuesday, June 18, 2013 5:57 PM
• Marked as answer by lansti Wednesday, June 19, 2013 6:05 AM

We've been dealing with this issue on and off since shortly after we upgraded to 2012 last year. We really started noticing it after trying to deploy third and fourth versions of some standard applications; iTunes, Java, Shockwave, etc.

In our case were pretty sure the culprit is my messing around with supersedence on actively deployed Applications. Since we upgraded to 2012 I've been constantly experimenting and tweaking our apps to get things juuuuuust right and I think I finally have a safe process that avoids supersedence tweaks.

I started working on a few apps this week and discovered the issue popping up again after I converted Reader over to my new process, which of course included tweaking supersedence on an older version that still had a deployment on it.

Since this has only been happening for us when we upgrade Applications, our best solution has just been to delete the old Applications deployment. It takes a few hours for machines to get their marbles straight but the errors eventually reduce to almost nothing and stay there until the next time I tweak something it doesnt like.

The posts above regarding CIagent.log and SQL for CI_ConfigurationItems are spot on for what weve been doing for determining the offending Application, but at this point weve gotten so used to the issue that the query is more a formality because were usually pretty sure what we did wrong. I dont think weve intentionally tried to reproduce the issue yet but I think we could if we really wanted to.

Seeing that some are having this issue with Task Sequences and not Applications, heres what I think this issue boils down to: the CM client gets confused when referenced/dependent/superseded Applications change on a deployment/configuration item. It could be a bug in the client where it cant figure out that things have changed, or it could be a bug in how the database gets updated when we make these changes. Either way, itd be nice if this didnt happen.

• Edited by Zandarian Tuesday, June 25, 2013 3:33 PM formatting

As an update, I found that those apps that had supersedence enabled, and a deployment older than the current revision of the application appeared to be the problem.

I located 2 apps with this configuration, and both were causing the fault.

To correct the issue, I deleted the old deployments (Machine deployments, user deployments were irrelevant) and recreated them. Over the next day, CIAgent.log files were error free.

• Proposed as answer by Pelivar Wednesday, July 03, 2013 3:12 AM

Hi Richard,

We are in exactly the same situation as yourself, and can only temporarily resolve this by updating the deployment content (things return to the erroneous state the following day). Did you ever resolve this?