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)

I have tried this solution from Patrik Schumacher, and it works, just for a while

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

Is this ConfigMgr SP1 CU1?

It is ConfigMgr SP1 with KB2801987(not sure if this is the CU1)
Version 5.0.7804.1000

This is not CU1 for SP1. I am not sure if the issue you described was fixed with CU1 for SP1, but it's worth a try.

This is not CU1 for SP1. I am not sure if the issue you described was fixed with CU1 for SP1, but it's worth a try. 

I can confirm seeing this in my environment. We noticed it this morning. I'm currently testing CU1 prior to upgrading my production environment, I'll report back if it corrects the issue.

I can confirm that its still an issue after Cumulative Update 1 for ConfigMgr SP1(KB2817245) was installed.

I went through the steps Patrik Schumacher mentioned after the installation last night, and i got these results:

And this morning, is says:

When i have a look into the software library\Elements and the Summary tab, it says:
Application Statistics:
Devices with Application: 163
Devices with installation FAilure: 1

Hey Torsten,

After my CU1 installation, it seems that my Software Updates have some issues with installing. They are spinning with "waiting to install".
My applications are running well, so it seems that this is a package problem.

Are you familiar with this?
I have been searching around on technet, and tried a couple of things, and i now wounder if i need a new client on my computers...

have you installed the patch for CU1 on your clients ?

Hi Niall.

If the version of the client is 5.00.7804.1000.... :)

I have the same problem witn Client 5.00.7711.000 and 5.00.7804.1000.  I don't think its a client version issue. 

When I run the Application infrastructure errors I get "CI Agent job was canceled", I was getting a "CI Version Info Timed Out", but I don't know if that just changes over time. 

Oh, and the error code showing is -2016410858 in case anyone is trying to search on the number.

FYI - With CU1 and latest patch the client version should be 5.00.7804.1202

Thanks William.

It is strange, because Config Manager client says on my server, that the version is 5.00.7804.1000.
The installer on the server, located in "Microsoft Configuration Manager\Client" or "Microsoft Configuration Manager\ClientUpgrade, also says that the version is 5.00.7804.1000...

And in appwiz.cpl --> "view installed updates" in section "System Center 2012 Configuration MAnager" it says
Culumative Update 1 for Configuration MAnager SP1 (KB2817245)

So where are the new client located?
If i try to install the SU1 once over, the precheck says its already installed, so there is no "repair" function...

Ok, I just had a meeting with a SCCM specialist, and he tells me to have a look at these

Installing SCCM 2012 SP1 CU1 - Quick start
and

Upgrade ConfigMgr 2012 SP1 clients with the CU1 update

I'll give the second link a try, and will report back over the weekend...

Well, i deployed this upgrade to a set of computers.

Configuration manager tells me that 11 out of 28 computers have this client version, but if i have a look at the deployment monitor, it says that 22 out of 28 is Successful, and the last 6 is unknown(thats ok...)

I had a look at the config manager client at the SCCM Server and a couple of my clients, and i can see these differences.

Why are there differences?
I thought that the version 1202 would be appear on every component..
And even after this upgrade, the monitoring issue is still here...

What you are showing above is correct.  Unfortunately cannot tell you why only 3 of the components show 1202, but I can confirm I see the same thing on my clients after the update.

Ok, thanks.

But i still have issues with monitoring deployments, that they are giving me wrong informastion back.
Do you have this issue William?

I haven't noticed but then again we only have only rolled the client to all our servers (about 350 clients) alone with 30 or so test workstation clients.  On the workstation side we are utilizing the Application Catalog for 99% of our software installs and the handful of deployments we have had on the server side have reported successful.  We are just a couple of weeks away from deploying the client to the rest of our workstations so I'll keep an eye out and report back if I see the same issue..

So... does anyone have any update on the actual issue that was stated at the beginning of the thread?

I'm afraid not.. I'll investigate more during this week, hope i have something to report back.

I have seen this issue at two customer sites now.  In one case, it when it occurs during a TASK SEQUENCE, the install updates step, stops processing for 2 HRS (for no reason) and overall the Install Software step takes 4.5 hours, when it should only take 30 minutes.

At my current customer, they are seeing this same error on their clients:

ReadStringFromFile failed (0x80070002). CIDownloader 6/13/2013 11:36:27 PM 4988 (0x137C)
ReadStringFromFile failed (0x80070002). CIDownloader 6/13/2013 11:36:27 PM 4988 (0x137C)
CLanterIdleTimerHelper::Execute Shutting down lantern CIDownloader 6/13/2013 11:51:01 PM 3952 (0x0F70)

Here is a snippet from the CIDowloader in as part of the Task sequence

Notice the 2 HOUR gap of the lantern engine shutting down, and it starting back up.

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

Hi Alan.

This is more like it.

I have checked this out on some of the clients, and i found that one of our applications where not available. Our application, is NOT a part of the TS, but deployed as Available application in Software Center, and still even if its not installed, we get errors.

I have for now, removed this deployment, and forced Application Deployment Evaluation Cycle, and now waiting to see
Ill report back during a couple of days, but Im pretty optimistic J

My SQL query to get a XML to reveal the friendly name of the offending application:

SELECT TOP 10 * FROM [CM_SITENAME].[dbo].[CI_ConfigurationItems] where CI_UniqueID like '%/Application_bd1e4c44-6776-43c7-8b66-55c6280c725b%'

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

Any update on exactly what actions trigger this issue, or how to untangle the mess?

Delete supersedence entries then recreate them? Delete deployments then recreate them for the superseding app?

We have hundreds of applications in our system and correcting this issue may prove very time consuming and difficult to diagnose with numerous apps reporting a problem in CIAgent.log on different PCs. :-(

As Alan Carita has answerd, that worked for me. I had to open the CIAgent.log, and did a search for "not available" and then find the friendly name with the sql query, and then manage one application at the time.

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

Superb

Hi all

nearly two years on from the last post on this thread and my companies environment now appears to be affected by this issue. We didn't experience it on 2012 SP1 but its appeared on our new 2012 R2 environment

- We are running SCCM 2012 R2 CU4, SQL 2012, we have a CAS and 4 Primary Sites

- We are experiencing this only with 'applications'

- Only clients in 2 of the 4 sites are affected

What is occurring

- A application is created and deployed

- Client runs an application evaluation and installs the application

- Deployment reports a success

- Client runs an application evaluation and the deployment then reports back as error

- This error isn't viewable in the 'view status' of the deployment. instead I have to run a infrastructure error report

- We do not use supersedence and the revision of the application stays the same

- This is only affecting clients under 2 of our 4 sites

What is odd is that the appintenteval.log looks fine when the client runs an application evaluation after the application has been installed "Current State = Installed, Applicability = Applicable, ResolvedState = Installed, ConfigureState = NotNeeded, Title = Oasys Safe 19.1.1.23" however as detailed above the client is reporting back to the MP that the application has now failed

So I guess my question is... are you all still affected by this issue? as deleting the application or deployment and recreating does not fix the issue

Thanks

Richard

Hi, we got this sorted with the help from MS premier support

in short there was a problem with a revision on an application by which the effected clients were looking for revision 8 when infact the latest revision was 10

We used the CIAgent.log on the problematic clients which gave the ID for the problematic application, also the revision the client was expecting. We then deleted this revision from the application which then resolved the issue

Hope this helps as we thought all application were affected, when infact it was just the one which caused the false negatives for all deployments

Richard