SCCM Troubleshooting SUP Failover - Teil 1

Wie wohl bekannt ist, können mehrere Software Update Points in einer Umgebung verwendet werden. D.h. den Clients stehen mehrere Zugriffspunkte für den Bezug von Updates zur Verfügung.

Das Vorgehen ist folgendermaßen. Der Client schickt eine Updateaufforderung und erhält eine Liste aller ihm zur Verfügung stehenden Software Update Points. Davon sucht er sich einen beliebigen aus und versucht sich zu diesem zu verbinden. Sollte die Verbindung nicht hergestellt werden können, versucht der Client im Intervall von 30 Minuten sich erneut mit dem Software Update Point zu verbinden. Bei weiteren Verbindungsfehlschlägen, wird der Client für gewöhnlich vier Mal diesen Vorgang wiederholen. Nach dem vierten Fehlversuch wartet der Client weitere 2 Minuten und wählt dann einen anderen Software Update Point aus. D.h. ein Failover wird durchgeführt.

Dieser Vorgang kann jedoch nur durchgeführt werden, wenn bestimmte Meldungen zurückgegeben werden, die den Failover initiieren. Wenn eine Fehlermeldung ausgegeben wird, die nicht Teil der bestimmten Meldungen ist, wird kein Failover durchgeführt. Über den folgenden SQL Befehl können diese sogenannten Retry-Codes ausgegeben werden.
select * from SC_Component_Property PROP
join SC_SiteDefinition SCDEF on SCDEF.SiteNumber = Prop.SiteNumber
where Prop.Name = 'WSUS Scan Retry Error Codes'
and SCDEF.SiteCode = 'PR1'
--Where PR1 is the primary site code.

Der Befehl kann dem Artikel unter [1] entnommen werden. Eine Fehlermeldung, die nicht in der Liste enthalten ist, ist z.B. der Error Code 0x80072ee2 der ein Netzwerktimeout bedeutet. Bei dieser Fehlerrückgabe, wird folglich kein Failover durchgeführt.

Und hier entstehen häufig Probleme für den Systemadministrator, der eigentlich gerne dieses Failover erzwingen würde, aber nicht kann, da der Code nicht in der Liste enthalten ist. Dafür steht uns jedoch ein Workaround zur Verfügung, indem wir den ausgegebenen Code der Code-Liste hinzufügen. Schauen wir uns an, wie wir den Workaround umsetzen können.
  1. Dafür geben wir im Bereich „ausführen“ wbemtest ein. Ich verwende hierbei einen Administratoraccount
  2. Dann verbinden wir uns zu root\sms\site_<sitecode> und geben den Sitecode ein.
  3. Dann führen wir folgende Query aus. “select * from sms_sci_component where componentname=”SMS_WSUS_CONFIGURATION_MANAGER”
  4. Und wählen das Objekt aus.
  5. Dann klicken wir auf die Properties
  6. Und wählen die View Embedded aus.
  7. Und wir sehen in der Ausgabe den Property Name „WSUS Scan Retry Error Codes“.
  8. Hier wählen wir den Wert 2 und fügen den Code hinzu. Hier beispielsweise
  9. Dies entspricht dem genannten Fehlercode in dezimaler schreibweise.
  10. Anschließend sichern wir die Einstellungen und das Objekt.
Und schon haben wir einen Error Code der Liste hinzugefügt und der Failover findet statt, sobald diese Fehlermeldung protokolliert wird.

Einen Workaround und ein Failover zu haben ist natürlich schön und gut aber eigentlich wäre es natürlich besser, wenn der Failover gar nicht erst eintreten müsste. Daher möchte ich mir nun anschauen wie man am besten beim Troubleshooting vorgehen kann.

Korrupte Komponenten

Viele der Fehlermeldungen erfolgen, weil Komponenten korrupt sind oder fehlen, wie z.B. Einträge in der Registry oder Komponenten, die nicht registriert sind.
0x80245003, 0x80070514, 0x8DDD0018, 0x80246008, 0x80200013, 0x8004015, 0x800A0046, 0x800A01AD, 0x80070424, 0x800B0100, 0x80248011

Man könnte hier manuell eine Registrierung der Komponenten durchführen und die Registrykeys überprüfen. Einfacher ist dies jedoch über den Windows Update Troubleshooter, der einem diese Arbeit abnimmt oder gegebenenfalls ausgibt, dass der Vorgang nicht durchgeführt werden konnte. Genaue Infos, was das Tool im einzelnen macht und der Download kann dem Link unter [2] entnommen werden.

Zudem ist es gut zu überprüfen, ob der aktuellste Windows Update Agent verwendet wird. Die aktuellen Agenten können über den KB Artikel 949104 bezogen werden [3]. Sollte der Troubleshooter das Problem nicht beheben können, kann der Windows Update Agent Data Store, also der Bereich in welchem die Updates hinterlegt werden, resettet werden mit den Befehlen
NET STOP WUAUSERV
NET STOP BITS

Dadurch werden die Dienste, die für Windows Updates, automatische Updates und BITS ausgeschaltet. Anschließendes kann der SoftwareDistribution Ordner unter C:\Windows umbenannt werden, wodurch beim Start der gerade beendeten Dienste ein neuer Ordner angelegt wird. Dies geschieht über den Befehl:
NET START WUAUSERV

BITS ist dann automatisch mit aktiviert, kann aber mit
NET START BITS

nochmals überprüft werden. Über den Befehl NET START und der Name des Dienstes, kann der Dienst wieder gestartet werden. Anschließend sollte überprüft werden, ob ein Updatebezug wieder möglich ist.

Sollte dieses Vorgehen nicht geholfen haben, sollte man sich das WindowsUpdate.log hernehmen. Das kann Aufschluss über die Fehlerursache geben. Den Link zur Interpretation des Logs ist unter [4] vorhanden. Ich empfehle hier als Logviewer CMTrace zu verwenden, welchen in den Configuration Manager Client Tools enthalten ist, da hier die Fehlermeldungen gut sichtbar hervorgehoben werden.

Ich habe mir meinen Windowsupdate.log auch mal angeschaut. Und in meinem Fall habe ich die Fehlermeldung
0x80004015 fail to register class object

Der auf eine fehlerhafte Berechtigung deutet. Daher sollte man schauen, ob die für Windows Update benötigten Dienste gestartet werden können. Für gewöhnlich werden die Dienste per GPO verwaltet. In der Regel reicht es aus, dem Dienst die Gruppe Netzwerkdienste hinzuzufügen und diesen volle Rechte zu geben.

[1] https://blogs.technet.microsoft.com/umairkhan/2014/10/02/configmgr-2012-r2-multiple-sup-scenario-clients-not-failing-over-to-the-other-sup/
[2] https://support.microsoft.com/de-de/kb/2714434
[3] https://support.microsoft.com/de-de/kb/949104
[4] https://support.microsoft.com/de-de/kb/902093

SCCM Troubleshooting SUP Failover - Teil 2

Wie wohl bekannt ist, können mehrere Software Update Points in einer Umgebung verwendet werden. D.h. den Clients stehen mehrere Zugriffspunkte für den Bezug von Updates zur Verfügung.


 

System CenterIris GerlachSUP, Troubleshooting, Failover