Wie kann ich herausfinden, welcher Client mein Distributionsupdate zum Scheitern bringt?

Es passiert von Zeit zu Zeit. Ich aktualisiere ein Paket und muss den Verteilungspunkt aktualisieren. Wir haben mehrere DPs, und in der Regel funktioniert alles einwandfrei, jedoch kann unser Haupt-DP das Paket von Zeit zu Zeit nicht aktualisieren.

1 DP-Screenshot fehlgeschlagen

Das Inhaltsstatusprotokoll sagt nie viel über den Fehler aus. Ich habe keinen Back-End-Serverzugriff auf die Verwaltungspunkte oder die DPs. Ich bin nur der SCCM-Administrator. Ich kann alle Protokolle in SCCM überprüfen, Berichte ausführen und alles, aber ich weiß nicht, wo ich suchen soll.

In der Vergangenheit habe ich versucht, die Einstellung "Disconnect Users from Distribution Point" (Benutzer vom Verteilungspunkt trennen) für das Problempaket festzulegen. Beide Untereinstellungen sind auf 0 gesetzt, aber das funktioniert bei uns nicht wirklich. Das Problem scheint sich nach einiger Zeit von selbst zu lösen, aber manchmal dauert es mehrere Tage. Für die Mehrheit (wirklich für alle, aber es gibt möglicherweise ein oder zwei, die ich übersehen habe) setzen wir Clients auf "Programm vom Verteilungspunkt ausführen". Wenn Sie das Programm bereitstellen, wissen Sie nicht, ob dies irgendetwas damit zu tun hat oder was der Stamm ist Ursache ist.

Aktualisieren

Ich habe in den Berichten etwas mehr Informationen gefunden, insbesondere die All Status Messages for a Specific Package at a Specific SiteAbfrage. Als ich meine Paket-ID für die Abfrage verwendete, sah ich nach dem erneuten Fehlschlagen des DP-Updates einen hervorstechenden Eintrag:

Der Verteilungs-Manager konnte das Paket "Konfigurationsaktualisierungen" nicht verarbeiten (Paket-ID = SOM00013).

Mögliche Ursache : Der Verteilungsmanager hat weder Zugriff auf das Paketquellverzeichnis noch auf den Verteilungspunkt. Lösung: Stellen Sie sicher, dass der Verteilungsmanager auf das Paketquellverzeichnis / den Verteilungspunkt zugreifen kann.

Mögliche Ursache : Das Paketquellverzeichnis enthält Dateien mit langen Dateinamen, und die Gesamtlänge des Pfads überschreitet die vom Betriebssystem unterstützte maximale Länge. Lösung: Verringern Sie die Anzahl der für das Paket definierten Ordner, verkürzen Sie den Dateinamen oder bündeln Sie die Dateien mit einem Komprimierungsprogramm.

Mögliche Ursache : Auf dem Standortserver-Computer oder dem Verteilungspunkt ist nicht genügend Speicherplatz verfügbar. Lösung: Stellen Sie sicher, dass auf dem Standortserver-Computer und auf dem Verteilungspunkt genügend freier Speicherplatz verfügbar ist.

Mögliche Ursache : Das Paketquellverzeichnis enthält Dateien, die möglicherweise von einem aktiven Prozess verwendet werden. Lösung: Schließen Sie alle Prozesse, die möglicherweise Dateien im Quellverzeichnis verwenden. Wenn dieser Fehler weiterhin auftritt, erstellen Sie eine alternative Kopie des Quellverzeichnisses und aktualisieren Sie die Paketquelle so, dass sie darauf verweist.

Ich bezweifle die beiden mittleren Ursachen aus einfachen Gründen

Der Quellordner ist nicht so tief, dass er lange Dateinamen für NTFS enthält, obwohl ich versuchen werde, die Vollständigkeit zu überprüfen.
Ich kann Dateien problemlos zum DP hinzufügen, so dass dies kein Dateibereichsproblem darstellt. Andere Pakete können problemlos aktualisiert werden.

Was ich nicht erwartet hatte, ist, dass die dritte Ursache besagt, dass das Quellverzeichnis irgendwo verwendet wird. Welchen Unterschied würde das überhaupt machen? Kopiert man nicht einfach die Dateien vom Fileshare in die SCCM DP-Freigabe? Werfen Sie mich weiter für eine Schleife. B / C-Clients greifen nicht einmal auf das Quellverzeichnis zu, es ist so ziemlich nur ein Staging-Verzeichnis, aus dem sccm Dateien kopieren kann.

Damit bleibt nur die erste Ursache, aber das geht wieder auf dasselbe zurück: Andere Pakete können problemlos aktualisiert werden.

sccm sccm-2012

— MDMoore313
quelle

Zunächst würde ich den integrierten Bericht unter "Software-Updates - E - Fehlerbehebung" lesen.

— Garth Jones

Haben Sie die Protokolle in den Clients selbst überprüft? Das, mit dem ich normalerweise beginne, ist $ env: windir \ ccm \ logs \ wuahandler.log. Suchen Sie nach den Zeilen mit den Flags ERROR und WARNING. So sieht ein Update aus (ich habe keine Windows-Maschine zum Ausschneiden und Einfügen). 1) Sagen Sie, dass das Update gestartet werden soll. Dieser Teil nimmt viele Zeilen in Anspruch, weil er hübsch aussehen soll. 2) Sagen Sie, wer der SCCM-Server ist, der die Dateien abruft. 3) Erwähnen Sie, dass er Dateien überprüft und welche Pakete, falls welche vorhanden sind , es wird gemeldet wie "Ich kann kein Paket bekommen" oder "Ich kann den

— raubvogel

-1, dies ist ein Client, der dieses Problem höchstwahrscheinlich verursacht, aber 3000 Clients einzeln nach Protokollen zu durchsuchen, die darauf hinweisen, dass etwas, das dem Verteilungspunkt bereits bekannt sein sollte, verrückt ist. Ich weiß, was zu erwarten ist, dies ist keine Frage, die eine vage Antwort erfordert, oder sogar eine Frage, die von einer vagen Antwort profitieren kann. Das ist eine sehr spezifische Frage.

— MDMoore313

Wenn er über SCCM-Administratorzugriff verfügt, sollte er in der Lage sein, zu den Überwachungs-> Bereitstellungen zu wechseln und dort den Eintrag für das Softwarepaket zu finden. Wenn Sie darauf klicken, wird angezeigt, auf welchen Clients das installiert war und auf welchen nicht. Ich nahm an, dass das Bild, das er bekam, von diesem Bildschirm kam.

— Raubvogel

Ich bezweifle, dass Sie dies beheben können, wenn dies zutrifft "Ich habe keinen Back-End-Serverzugriff auf die Verwaltungspunkte oder die DPs".

Können Sie auf das Protokoll distmgr.log auf dem Standortserver zugreifen? Wenn nicht, müssen Sie das Problem an jemanden weiterleiten, der dies kann.

Dieses Problem hat nichts mit dem Kunden zu tun, daher würde ich andere Antworten ignorieren, die empfehlen, sich die Kunden anzusehen. Dieses Problem wird dadurch verursacht, dass der Site Server die Dateien nicht aus Ihrem Quellordner auf den Verteilungspunkt kopieren kann.

Wenn Sie nicht auf die Site Server-Protokolle zugreifen können, können Sie versuchen, zu lange Ordnerstrukturen zu vermeiden, indem Sie das Paket komprimieren, bereitstellen und entpacken, bevor Sie es auf Client-Seite installieren.

— TallPaul
quelle

+1 für die Protokollinformationen, aber das Problem ist, dass der Server die Dateien nicht kopieren kann ja, aber unsere Arbeitstheorie ist, dass ein Client irgendwie eine Schreibsperre für die DP-Dateien hat. Die Ordnerstruktur ist nicht zu lang, da in diesem speziellen Paket die Dateien bereits komprimiert waren und das Verhalten nicht konsistent, sondern fleckig ist.

— MDMoore313

Holen Sie sich das SCCM-Toolkit. Es verfügt über einen Protokollanalysator und Toolkits für Verteilungspunkte, mit denen Sie das Problem leichter finden können.

http://www.microsoft.com/en-us/download/details.aspx?id=36213

— Super1337
quelle

Könnten Sie etwas genauer erläutern, wie jemand das Toolkit verwenden würde, um einen Kunden zu finden, der noch an einem Paket festhält? Wenn nicht, ist dies effektiv eine Antwort nur auf Links, da ich das Toolkit bereits installiert hatte.

— MDMoore313