Como as revisões de aplicativos se propagam de um servidor de site SCCM para um cliente?

Question

Quando faço uma alteração em um Aplicativo no console de gerenciamento, vejo que este número de revisão é incrementado:

Se eu clicar em "Status do conteúdo", posso ver uma "Versão de origem", mas nenhuma "Revisão" do aplicativo.

Em um cliente no qual o aplicativo está implantado, posso ver a seguinte entrada para o mesmo aplicativo em AppEnforce.log:

"Executando detecção do tipo de implantação de aplicativo XXXXXXXXXXXXX 0.2.1(ScopeId_F51CE1C8-9E1E-4412-8DC0-8870C8D09B93/DeploymentType_7ce08ce1-ddb5-4861-b5eb-d03752c142cb, revisão 22) para o usuário."

Tudo isso me deixa com as seguintes perguntas:

1. A que exatamente se refere "Revisão" no console? Tem o mesmo significado que a entrada in AppEnforce.log?

2. O conteúdo distribuído precisa ser atualizado para que a nova "Revisão" seja propagada do Site Server para o cliente?

3. Que trabalho o SCCM realiza para propagar uma alteração de "Revisão" no console para um cliente? Posso ver artefatos deste trabalho nos arquivos de log do servidor?

4. Por que a "Revisão" que AppEnforce.logàs vezes aparece um incremento atrás da "Revisão" é mostrada no console mesmo depois de muito tempo?

Answer 1

Isso é tudo o que consegui reunir a partir dos registros. Eu uso o CMTrace para mesclar os seguintes logs:AppDiscovery, AppEnforce, AppIntentEval, CAS, ContentTransferManager, DataTransferService

1. No Console do SCCM, "Revisão" significa revisão do aplicativo no SCCM. O item emAppEnforce.logé o tipo de implantação de aplicativo, não acho que eles devam necessariamente se alinhar, embora possam ocorrer em aplicativos mais simples.
2. A validade de conteúdo é avaliada de forma independente. Se você forçasse uma redistribuição de conteúdo, esperaria que a revisão do conteúdo aumentasse. A mesma coisa se "atualizar conteúdo automaticamente" foi verificado e o conteúdo foi determinado como atualizado no servidor.
3. Acho que todo o trabalho é feito pelo cliente. AppIntentEvalmostra que um Aplicativo é aplicável, eAppDiscoverydetermina qual ContentID/Revisão será usado. Isso faria com que o cliente pesquisasse as informações no servidor, não necessariamente fazendo com que elas fossem enviadas do servidor.
4. Porque o SCCM leva uma eternidade para fazer as coisas? Receio não poder responder a isso com competência. O início das tarefas do cliente pode fazer com que os resultados da avaliação voltem a estar alinhados.

Coisas a ter em mente:

AppEnforce.log não é tudo. A revisão do tipo de implantação não parece ser igual à revisão do aplicativo, que é novamente diferente da revisão do 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 possui no cache ainda é válido, se as revisões estão desatualizadas?" ContentAccess.logmostra entradas como "All references to Content Content_xxx in cache have been removed. Content will be Tombstoned. eu suspeito que esse mecanismo é como a validade é determinada.