Wenn ich in der Verwaltungskonsole eine Änderung an einer Anwendung vornehme, sehe ich, dass diese Revisionsnummer erhöht wird:
Wenn ich auf „Inhaltsstatus“ klicke, wird mir eine „Quellversion“ angezeigt, jedoch keine „Revision“ für die Anwendung.
Auf einem Client, auf dem die Anwendung bereitgestellt wird, kann ich den folgenden Eintrag für dieselbe Anwendung sehen in AppEnforce.log
:
„Erkennung des App-Bereitstellungstyps XXXXXXXXXXXXX 0.2.1 (ScopeId_F51CE1C8-9E1E-4412-8DC0-8870C8D09B93/DeploymentType_7ce08ce1-ddb5-4861-b5eb-d03752c142cb, Revision 22) für Benutzer wird durchgeführt.“
Dies alles wirft für mich folgende Fragen auf:
Was genau bedeutet "Revision" in der Konsole? Hat es die gleiche Bedeutung wie der Eintrag in in
AppEnforce.log
?Müssen verteilte Inhalte aktualisiert werden, damit die neue „Revision“ vom Site-Server an den Client weitergegeben wird?
Welche Arbeit führt SCCM aus, um eine „Revision“-Änderung in der Konsole an einen Client weiterzuleiten? Kann ich Artefakte dieser Arbeit in Server-Protokolldateien sehen?
Warum liegt die angezeigte „Revision“
AppEnforce.log
manchmal um ein Inkrement hinter der in der Konsole angezeigten „Revision“, obwohl schon viel Zeit vergangen ist?
Antwort1
Das ist alles, was ich aus den Protokollen zusammentragen konnte. Ich verwende CMTrace, um die folgenden Protokolle zusammenzuführen:AppDiscovery, AppEnforce, AppIntentEval, CAS, ContentTransferManager, DataTransferService
- In der SCCM-Konsole bedeutet „Revision“ die Anwendungsrevision innerhalb von SCCM. Das Element inAppEnforce.logist der Anwendungsbereitstellungstyp. Ich denke nicht, dass diese unbedingt übereinstimmen müssen, obwohl dies bei einfacheren Anwendungen der Fall sein könnte.
- Die Gültigkeit des Inhalts wird unabhängig ausgewertet. Wenn Sie eine Neuverteilung des Inhalts erzwingen würden, würde ich erwarten, dass die Revision des Inhalts erhöht wird. Dasselbe gilt, wenn „Inhalt automatisch aktualisieren“ aktiviert ist und festgestellt wird, dass der Inhalt auf dem Server aktualisiert wurde.
- Ich denke, die gesamte Arbeit wird vom Kunden erledigt. AppIntentEvalzeigt, dass eine Anwendung anwendbar ist, undAppDiscoverybestimmt, welche ContentID/Revision verwendet wird. Dadurch fragt der Client den Server nach den Informationen ab, ohne sie unbedingt vom Server herunterzuladen.
- Weil SCCM ewig braucht, um Dinge zu erledigen? Ich fürchte, das kann ich nicht kompetent beantworten. Das Starten von Client-Aufgaben kann dazu führen, dass diese Auswertungsergebnisse wieder in die richtige Reihenfolge kommen.
Zu beachtende Punkte:
AppEnforce.log liefert nicht das ganze Bild. Die Revision des Bereitstellungstyps scheint nicht mit der Anwendungsrevision identisch zu sein, die sich wiederum von der Inhaltsrevision unterscheidet.
Schauen Sie in AppIntentEval.log nach. Sie sehen ScopeId_xxx/DeploymentType_xxx/(revision)
. Sie sehen auch ScopeId_xxx/Application_xxx/(revision)
. Dies sind nicht dieselben Entitäten.
Ich denke, ein Teil Ihrer Frage lautet: „Wie stellt ein Client fest, dass der Inhalt in seinem Cache noch gültig ist, wenn die Revisionen veraltet sind?“ ContentAccess.logzeigt Einträge wie „ "All references to Content Content_xxx in cache have been removed. Content will be Tombstoned.
Ich vermute, dass die Gültigkeit anhand dieses Mechanismus bestimmt wird.“