Isso é tudo o que consegui juntar dos logs. Eu uso o CMTrace para mesclar os seguintes logs: AppDiscovery, AppEnforce, AppIntentEval, CAS, ContentTransferManager, DataTransferService
- No console do SCCM, "Revisão" significa revisão de aplicativo no SCCM. O item em AppEnforce.log é o Tipo de Implantação do Aplicativo, não acho que eles devam necessariamente se alinhar, embora possam ser em aplicativos mais simples.
- A validade do conteúdo é avaliada de forma independente. Se você forçar uma redistribuição de conteúdo, esperaria que a revisão no conteúdo fosse incrementada. A mesma coisa se "atualização automática de conteúdo" foi verificada e o conteúdo foi determinado como tendo sido atualizado no servidor.
- Acho que todo o trabalho é feito pelo cliente. AppIntentEval mostra que um Aplicativo é aplicável e AppDiscovery determina qual ContentID / Revisão será usado. Isso faria o cliente pesquisar o servidor em busca de informações, não necessariamente fazendo com que ele fosse enviado do servidor.
- Porque o SCCM leva uma eternidade para fazer as coisas? Receio não poder responder isso com competência. O início das tarefas do cliente pode resultar na volta desses resultados da avaliação.
Coisas para ter em mente:
AppEnforce.log não é a imagem completa. A revisão do tipo de implantação não parece ser a mesma que a revisão do aplicativo, que é diferente da revisão de conteúdo.
Procure em AppIntentEval.log. Você vê ScopeId_xxx/DeploymentType_xxx/(revision)
. Você também vê ScopeId_xxx/Application_xxx/(revision)
. Estas não são a mesma entidade.
Acho que parte da sua pergunta é: "Como um cliente determina que o conteúdo que ele tem no cache ainda é válido, se as revisões estiverem desatualizadas?" ContentAccess.log mostra entradas como "All references to Content Content_xxx in cache have been removed. Content will be Tombstoned.
Suspeito que este mecanismo é como a validade é determinada.