¿Cómo se propagan las revisiones de la aplicación desde un servidor de sitio SCCM a un cliente?

Question

Cuando hago un cambio en una Aplicación en la consola de administración, veo que este número de revisión aumenta:

Si hago clic en "Estado del contenido", puedo ver una "Versión fuente" pero no una "Revisión" para la aplicación.

En un cliente en el que se implementa la aplicación, puedo ver la siguiente entrada para la misma aplicación en AppEnforce.log:

"Realizando la detección del tipo de implementación de la aplicación XXXXXXXXXXXXX 0.2.1 (ScopeId_F51CE1C8-9E1E-4412-8DC0-8870C8D09B93/DeploymentType_7ce08ce1-ddb5-4861-b5eb-d03752c142cb, revisión 22) para el usuario".

Todo esto me deja con las siguientes preguntas:

1. ¿A qué se refiere exactamente "Revisión" en la consola? ¿Tiene el mismo significado que la entrada en en AppEnforce.log?

2. ¿Es necesario actualizar el contenido distribuido para que la nueva "Revisión" se propague desde el servidor del sitio al cliente?

3. ¿Qué trabajo realiza SCCM para propagar un cambio de "Revisión" en la consola a un cliente? ¿Puedo ver artefactos de este trabajo en los archivos de registro del servidor?

4. ¿Por qué la "Revisión" que aparece AppEnforce.loga veces en un incremento detrás de la "Revisión" se muestra en la consola aunque haya transcurrido mucho tiempo?

Answer 1

Esto es todo lo que he podido reconstruir a partir de los registros. Utilizo CMTrace para fusionar los siguientes registros:AppDiscovery, AppEnforce, AppIntentEval, CAS, ContentTransferManager, DataTransferService

1. En la Consola SCCM, "Revisión" significa revisión de la Aplicación dentro de SCCM. El artículo enAppEnforce.loges el tipo de implementación de la aplicación, no creo que deban alinearse necesariamente, aunque podrían hacerlo en aplicaciones más simples.
2. La validez de contenido se evalúa de forma independiente. Si fuera a forzar una redistribución de contenido, esperaría que la revisión del contenido aumentara. Lo mismo ocurre si se marcó "actualizar contenido automáticamente" y se determinó que el contenido se actualizó en el servidor.
3. Creo que todo el trabajo lo hace el cliente. AppIntentEvaldemuestra que una Solicitud es aplicable, ydescubrimiento de aplicacionesdetermina qué ContentID/Revisión se utilizará. Esto haría que el cliente sondeara al servidor para obtener la información, sin que necesariamente la enviara desde el servidor.
4. ¿Porque SCCM tarda una eternidad en hacer las cosas? Me temo que no puedo responder esto de manera competente. Iniciar las tareas del cliente puede hacer que los resultados de la evaluación vuelvan a estar en línea.

Cosas a tener en cuenta:

AppEnforce.log no es el panorama completo. La revisión del tipo de implementación no parece ser la misma que la revisión de la aplicación, que nuevamente es diferente de la revisión del contenido.

Busque en AppIntentEval.log. Verás ScopeId_xxx/DeploymentType_xxx/(revision). Tú también ves ScopeId_xxx/Application_xxx/(revision). Estas no son la misma entidad.

Creo que parte de su pregunta es: "¿Cómo determina un cliente que el contenido que tiene en el caché sigue siendo válido si las revisiones están desactualizadas?" ContenidoAcceso.logmuestra entradas como "All references to Content Content_xxx in cache have been removed. Content will be Tombstoned. Sospecho que este mecanismo es cómo se determina la validez.