How do Application revisions propagate from an SCCM site server to a client?

Question

When I make a change to an Application in the management console, I see that this revision number is incremented:

If I click on "Content Status", I can see a "Source Version" but no "Revision" for the Application.

On a client to which the application is deployed, I can see the following entry for the same Application in AppEnforce.log:

"Performing detection of app deployment type XXXXXXXXXXXXX 0.2.1(ScopeId_F51CE1C8-9E1E-4412-8DC0-8870C8D09B93/DeploymentType_7ce08ce1-ddb5-4861-b5eb-d03752c142cb, revision 22) for user."

This all leaves me with the following questions:

1. What, exactly, does "Revision" in the console refer to? Does it have the same meaning as the entry in in AppEnforce.log?

2. Does distributed content have to be updated in order for the new "Revision" to propagate from the Site Server to the client?

3. What work does SCCM perform to propagate a "Revision" change in the console to a client? Can I see artifacts of this work in server log files?

4. Why is the "Revision" that appears in AppEnforce.log sometimes one increment behind the "Revision" shown in the console even though a long time has elapsed?

Answer 1

This is all what I have been able to piece together from logs. I use CMTrace to Merge the following logs: AppDiscovery, AppEnforce, AppIntentEval, CAS, ContentTransferManager, DataTransferService

1. In the SCCM Console, "Revision" means Application revision within SCCM. The item in AppEnforce.log is the Application Deployment Type, I don't think these should necessarily align, though they might in simpler applications.
2. Content validity is evaluated independently. If you were to force a content redistribution, I would expect the revision on the content to increment. Same thing if "automatically update content" was checked and the content was determined to have updated on the server.
3. I think all of the work is done by the client. AppIntentEval shows that an Application is applicable, and AppDiscovery determines which ContentID/Revision will be used. This would the client polling the server for the info, not necessarily getting it pushed down from the server.
4. Because SCCM takes forever to do things? I'm afraid I can't answer this competently. Kicking off client tasks may result in these evaluation results coming back in-line.

Things to keep in mind:

AppEnforce.log is not the whole picture. Deployment Type revision does not seem to be the same as Application revision, which is different again from Content revision.

Look in AppIntentEval.log. You see ScopeId_xxx/DeploymentType_xxx/(revision). You also see ScopeId_xxx/Application_xxx/(revision). These are not the same entity.

I think part of your question is: "How does a client determine that the content it has in the cache is still valid, if the revisions are out of date?" ContentAccess.log shows entries such as "All references to Content Content_xxx in cache have been removed. Content will be Tombstoned. I suspect this mechanism is how validity is determined.