Erst WSUS 3.0 - dann Intranet ausgefallen

[vision311 10]

Guten Morgen

 

Ich habe folgendes Problem und wäre dankbar um jegliche Hilfe:

 

Seit gestern Abend habe ich auf SRV02 (DC, WSUS, IIS, SEP11, Abacus und Lizenzserver für verschiedene Applikationen) folgende Meldungen zu WSUS (Meldungen im nächsten Posting - Platzproblem)

 

-------------------------------------------------------------------------

 

Ich habe die Anweisung aus dem 7032 befolgt und erstmal die Konsoleneinstellungen gelöscht. Danach habe ich IIS, SQL und den Update Services-Dienst neu gestartet.

 

WSUS hat weiterhin nicht funktioniert. Ich bin den 120xxx-Fehlern nachgegangen und habe etliche Hinweise gefunden, die besagen, dass dem WWW-Publishingdienst das lokale Systemkonto zugewiesen werden soll.

 

Damit habe ich die ganze IIS-Geschichte definitiv zum erliegen gebracht:

WSUS funktioniert weiterhin nicht (auf Port 8530)

Die Webseite intra funktioniert nicht mehr (auf Port 80)

Der Symantec Endpoint Protection Manager funktioniert nicht mehr (auf Port 8443)

 

Ich habe dem Publishingdienst deshalb wieder den IUSR_SRV02 zuweisen wollen, und dabei natürlich das (bis dato von Windows zufällig generierte) Kennwort verloren.

 

Ich habe also (wiederum nach Anleitung eines KBs) das Kennwort des IUSR_SRV02 zurückgesetzt (neu vergeben) und dieses Kennwort an folgenden Orten manuel ersetzt:

WWW-Publishingdienst

Überall in IIS, wo dieser Benutzer eingetragen ist.

 

Trotzdem kann ich jetzt weder IIS noch den WWW-Publishingdienst starten.

 

Grüsse aus der Schweiz

Daniel

–

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Clients

Ereigniskennung: 13042

Computer: SRV02

Beschreibung:

Selbstupdate funktioniert nicht.

 

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Web Services

Ereigniskennung: 12002

Computer: SRV02

Beschreibung:

Der Berichterstattungswebdienst funktioniert nicht.

 

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Web Services

Ereigniskennung: 12012

Computer: SRV02

Beschreibung:

Der API-Remoting-Webdienst funktioniert nicht.

 

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Web Services

Ereigniskennung: 12032

Computer: SRV02

Beschreibung:

Der Serversynchronisierungs-Webdienst funktioniert nicht.

 

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Web Services

Ereigniskennung: 12022

Computer: SRV02

Beschreibung:

Der Clientwebdienst funktioniert nicht.

 

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Web Services

Ereigniskennung: 12042

Computer: SRV02

Beschreibung:

Der SimpleAuth-Webdienst funktioniert nicht.

 

Ereignistyp: Fehler

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Web Services

Ereigniskennung: 12052

Computer: SRV02

Beschreibung:

Der DSS-Authentifizierungswebdienst funktioniert nicht.

[vision311 10]

Heute morgen kam noch folgender Fehler hinzu:

 

Ereignistyp: Warnung

Ereignisquelle: Windows Server Update Services

Ereigniskategorie: Keine

Ereigniskennung: 7032

Computer: EWLSRV02

Beschreibung:

Die WSUS-Verwaltungskonsole konnte über die Remote-API keine Verbindung mit dem WSUS-Server herstellen.

 

Stellen Sie sicher, dass der Update Services-Dienst, IIS und SQL auf dem Server ausgeführt werden. Starten Sie IIS, SQL und den Update Services-Dienst erneut, wenn das Problem weiterhin besteht.

 

An der WSUS-Verwaltungskonsole ist ein unerwarteter Fehler aufgetreten. Möglicherweise ist es ein vorübergehender Fehler. Versuchen Sie, die Verwaltungskonsole erneut zu starten. Wenn der Fehler weiterhin besteht,

 

entfernen Sie die gespeicherten Einstellungen für die Konsole, indem Sie die WSUS-Datei unter "%appdata%\Microsoft\MMC\" löschen.

 

 

System.IO.IOException -- Fehler bei Handshake wegen eines unerwarteten Paketformats.

 

Source

System

 

Stack Trace:

bei System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)

bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)

bei System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

bei System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)

bei System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)

bei System.Net.TlsStream.CallProcessAuthentication(Object state)

bei System.Threading.ExecutionContext.runTryCode(Object userData)

bei System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)

bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)

bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

bei System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)

bei System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)

bei System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)

bei System.Net.ConnectStream.WriteHeaders(Boolean async)

** this exception was nested inside of the following exception **

 

 

System.Net.WebException -- Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..

 

Source

Microsoft.UpdateServices.Administration

 

Stack Trace:

bei Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)

bei Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)

bei Microsoft.UpdateServices.UI.AdminApiAccess.AdminApiTools.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)

bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)

bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()

bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.get_ServerTools()

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter Events and Errors Message Center: Basic Search.

[Sunny61 773]

Da sind wohl ein paar NTFS-Berechtigungen flöten gegangen. In diesem Artikel wird beschrieben, wie die Rechte aussehen sollen: The Microsoft Windows Server Update Services (WSUS) SelfUpdate service does not send automatic updates

 

IIS-Settings: Appendix C: IIS Settings for Web Services

WSUS-Verzeichnisse: Appendix D: Permissions on WSUS Directories and Registry Keys

Kontrolliere das ganz genau durch, ein flascher Haken an der flaschen Stelle hat schon so manchen WSUS aus der Bahn geworfen.

 

Edit: Noch einer: Source: Windows Server Update Services ID: 13042 (.NET Framework 2.0.50727.42) - Events And Errors Message Center: Message Details

 

Aufgrund welcher Aktion wurden die Fehlermeldungen erzeugt? Hast Du irgendwas neues installiert oder etwas deinstalliert? Symantec war vorher schon drauf?

[vision311 10]

Hallo Sunny61

 

Ich arbeite mal minutiös deine Links durch. Danke dafür

 

Symantec läuft seit Anfang jahr ganz friedlich mit WSUS. Am Anfang gabs Probleme, die aber dauerhaft behoben wurden.

 

Speziell ist, dass ich vor rund 3 Wochen WSUS neu installiert habe. Seither gabs aber, bis eben gestern, keine Probleme damit.

 

Gestern morgen wurde eine Software installiert, die jedoch nach Aussage des Entwicklers dieser Software keinen Zusammenhang haben kann: Die Software benutzt einen eigenen User und kommuniziert über DCOM mit den Clients.

–

Inzwischen taucht auch folgender Fehler auf:

Ereignistyp: Warnung

Ereignisquelle: IISADMIN

Ereigniskategorie: Keine

Ereigniskennung: 105

Datum: 30.07.2008

Zeit: 11:08:38

Benutzer: Nicht zutreffend

Computer: EWLSRV02

Beschreibung:

Der IISADMIN-Dienst konnte das anonyme/WAM-Konto EWL\IUSR_EWLSRV02 nicht überprüfen. Aus diesem Grund können Fehler bei einigen IIS-Funktionen auftreten.

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter Events and Errors Message Center: Basic Search.

 

 

Die Berechtigungen und Einstellungen von WSUS sind fehlerhaft:

Die benutzer sind wie gefordert mit den entsprechenden Rechten vorhanden.

Es fehlt der Ordner WSUSAdmin

 

 

Ich habe jedoch das Gefühl, dass ich erst den WWW-Publishingdienst und IIS wieder zum laufen kriegen muss (siehe Fehler oben), bevor ich mich weiter hinter WSUS setze.

[Sunny61 773]

Prüf im IIS die jeweiligen Links aus den Seiten ins Filesystem, den WSUS betreffend. Dann die NTFS-Berechtigungen pro Ordner, ist zwar eine zeitraubende Arbeit, aber sehr wahrscheinlich zielführend.

[vision311 10]

Nur zum sicher gehen: Diese Püfung erledige ich BEVOR ich IIS grundsätzlich wieder starten kann?

 

Edith meint:

 

Nach Änderung der Kontos für den WWW-Publishingdienst (Lokales Konto verwenden) läuft jetzt wenigstens die Intranet-Webseite wieder.

 

Ich klemme mich jetzt also noch einmal hinter Sunny61 Tips.

 

Danke für deine Hilfe bis hierhin!

 

Daniel

[Sunny61 773]

Nur zum sicher gehen: Diese Püfung erledige ich BEVOR ich IIS grundsätzlich wieder starten kann?

 

Edith meint:

 

Nach Änderung der Kontos für den WWW-Publishingdienst (Lokales Konto verwenden) läuft jetzt wenigstens die Intranet-Webseite wieder.

 

Na schon mal ein Teilerfolg. ;)

 

Ich klemme mich jetzt also noch einmal hinter Sunny61 Tips.

 

Zu 99 % sind es fehlende NTFS-Berechtigungen. Wurde gestern evtl. die letzten Windows Updates installiert?

 

Danke für deine Hilfe bis hierhin!

 

Bitte, gern geschehen. ;)

[vision311 10]

Updates wurden gestern keine installiert.

 

Ich melde Erfolg / Misserfolg morgen. Der Nachmittag wird mir durch Arbeit an einem Kundengerät versüsst.

[vision311 10]

Ich habe alle Berechtigungen durchgeprüft, alle zwingend notwendigen Ordner und Dateien geprüft. Es gab überall kleine Unstimmigkeiten, was mich einerseits nachdenklich stimmt..

 

Aufgrund der vielen kleinen Unstimmigkeiten habe ich beschlossen, WSUS komplett vom Server zu entfernen. Die anschliessende Neuinstallation / Konfiguration verlief ohne Probleme, eine erste Synchronisation verlief ohne Probleme. Clients melden sich langsam wieder und melden ihre Stati. Aber im Ereignislog werden diverse Dateien genannt, die nicht heruntergeladen werden konnten.

 

Ich lasse WSUS jetzt bis morgen ruhen und sehe dann weiter.

 

PS: Seit der Deinstallation und Neinstallation von WSUS funktioniert auch die dritte Webseite auf diesem Server wieder: SEP Manager. :)

[Sunny61 773]

Ich habe alle Berechtigungen durchgeprüft, alle zwingend notwendigen Ordner und Dateien geprüft. Es gab überall kleine Unstimmigkeiten, was mich einerseits nachdenklich stimmt..

 

Hmm, mich jetzt auch. Sehr komisch.

 

Aufgrund der vielen kleinen Unstimmigkeiten habe ich beschlossen, WSUS komplett vom Server zu entfernen. Die anschliessende Neuinstallation / Konfiguration verlief ohne Probleme, eine erste Synchronisation verlief ohne Probleme. Clients melden sich langsam wieder und melden ihre Stati. Aber im Ereignislog werden diverse Dateien genannt, die nicht heruntergeladen werden konnten.

 

Dann schau mal auf die Startseite vom WSUS: http://www.grurili.de/Bilder/WSUS3_27.gif

 

Evtl. hilft: WsusDebugTool herunterladen:

http://download.microsoft.com/download/7/7/4/7745a34e-f563-443b-b4f8-3a289e995255/WSUS%20Server%20Debug%20Tool.EXE

WsusDebugTool.exe /Tool:SetForegroundDownload

 

Ich lasse WSUS jetzt bis morgen ruhen und sehe dann weiter.

 

Jupp, sag Bescheid. ;)

 

PS: Seit der Deinstallation und Neinstallation von WSUS funktioniert auch die dritte Webseite auf diesem Server wieder: SEP Manager. :)

 

Dann hat bei der ersten Installation irgendwas nicht gepasst. Sind irgendwelche AV-Scanner während der Installation gelaufen?

[vision311 10]

Interessant:

 

Weder in der WSUS-Admin Seite noch in der Standardwebseite existiert SelfUpdate. Das passt zum Fehler WSUS, Client, 13042.

Aus früheren Installationen weiss ich, dass man das virtuelle Verzeichnis manuel anlegen kann. Tue ich dies und starte anschliessend IIS wieder neu, ist das Verzeichnis aus der Standardwebseite einfach wieder verschwunden!

Die Clients haben sich übrigens alle gemeldet, aber keiner liefert einen Status mehr ab :(

 

Im Software Deployment Log sind übrigens einzelne Warnungen drin, die wie folgt aussehen:

2008-08-06 06:57:04.249 UTC Warning w3wp.7 DBConnection.OnReceivingInfoMessage Invalid event dropped. EventInstanceID=BE80398E-32CB-4DAA-9CB6-3D792C2CAE53, ComputerID=41536e7c-734a-4e9d-8f20-97565d74edd3. Invalid UpdateID/RevisionNumber.

2008-08-06 06:57:04.264 UTC Warning w3wp.7 DBConnection.OnReceivingInfoMessage Invalid event dropped. EventInstanceID=D778F614-58FE-441F-A0D1-D857912F5A0D, ComputerID=41536e7c-734a-4e9d-8f20-97565d74edd3. Invalid UpdateID/RevisionNumber.

 

Kann da eine wuauclt.exe /resetauthorisation helfen?

 

Weiter finde ich solche Warnungen:

2008-08-06 06:56:59.670 UTC Warning WsusService.33 ContentSyncAgent.ProcessBITSNotificationQueue ContentSyncAgent recieved Failure for Item: 71b632dd-e2f0-4be0-bd2c-cb2487f788ce, Item fails

 

 

Zudem meldet IIS beim Neustart, dass die Identität vom IUSR nicht überprüft werden kann (IISADMIN, 105). Das Passwort für IUSR habe ich per adsutil.vbs ausgelesen und in ADUC eingetragen, das Passwort stimmt also überein. IUSR ist auch mitglied der USER-Gruppe und erfüllt somit die Anforderungen der entsprechenden MS-Anleitung. w3svc ist auch der einzige Dienst in der IIS-Metabase, der IUSR benötigt.

 

Und ja, der Virenschutz (Symantec Endpoint Protection) lief während der Installation.

[Sunny61 773]

Weder in der WSUS-Admin Seite noch in der Standardwebseite existiert SelfUpdate. Das passt zum Fehler WSUS, Client, 13042.

Aus früheren Installationen weiss ich, dass man das virtuelle Verzeichnis manuel anlegen kann. Tue ich dies und starte anschliessend IIS wieder neu, ist das Verzeichnis aus der Standardwebseite einfach wieder verschwunden!

 

Gibts das Verzeichnis auch im Filesystem? Läuft der WSUS auf Port 80 oder 8530? Ist auf dem WSUS auch die Website von Symantec installiert? Dafür gibts einen Workaround von Symantec: Symantec Endpoint Protection clients will not update definitions or signatures with WSUS (Windows Server Update Services) installed on the Symantec Endpoint Protection Manager system.

 

Die Clients haben sich übrigens alle gemeldet, aber keiner liefert einen Status mehr ab :(

 

Fehlermeldungen in der WindowsUpdate.log auf den Clients?

 

Und ja, der Virenschutz (Symantec Endpoint Protection) lief während der Installation.

 

Du könntest mal den WSUS deinstallieren, vorher den AV-Scanner deaktivieren oder deinstallieren. Bei der Deinstallation kannst Du das Content und die DB behalten.

[vision311 10]

Der SEP-Workaround ist mir bekannt. WSUS läuft deshalb auf Port 8530 und in einer eigenen Webseite.

 

Ich habe mir die Client-Logs mal geholt und kontrolliere diese minutiös. Danke für den Hinweis.

 

Ergebnis der Kontrolle: Die Clients weisen mehrfach Fehler 0x80190193 und 0x80244018 auf. Beschreibungen zu diesen Fehlern deuten auf Zugriffsprobleme auf die Webseite hin. Bei einigen wurde SSL aktiviert, dies trifft bei mir nicht zu. Bei anderen gab es Probleme mit dem IUSR_Maschine.

 

Die Fehlöermeldung beim Zugriffsversuch auf http://192.168.1.16:8530/selfupdate/wuident.cab vom Client her per IE sieht aus wie folgt:

HTTP Error 403.2 - Forbidden: Read access is denied. (HTTP-Fehler 403.2 - Verboten: Lesezugriff verweigert.)

Internetinformationsdienste (Internet Information Services oder IIS)

 

Das passt zur Fehlermeldung IISADMIN 105. Mir bleibt wohl nichts anderes übrig als noch einmal das Passwort bei jedem einzelnen Eintrag von IUSR_Maschine zu prüfen.

 

Und sowas anderthalb Wochen vor dem Abgang in dieser Firma..

[Sunny61 773]

Der SEP-Workaround ist mir bekannt. WSUS läuft deshalb auf Port 8530 und in einer eigenen Webseite.

 

Ich habe mir die Client-Logs mal geholt und kontrolliere diese minutiös. Danke für den Hinweis.

 

Gut. ;)

 

Ergebnis der Kontrolle: Die Clients weisen mehrfach Fehler 0x80190193 und 0x80244018 auf. Beschreibungen zu diesen Fehlern deuten auf Zugriffsprobleme auf die Webseite hin. Bei einigen wurde SSL aktiviert, dies trifft bei mir nicht zu. Bei anderen gab es Probleme mit dem IUSR_Maschine.

 

Ja, wird auch hier beschrieben: Issues with BITS

Geh doch auch mal die Berechtigungen im IIS und im Filesystem durch. Der NETZWERKDIENST muss Zugriffsrechte haben. Die Links zu den WhitePapern hatte ich schon gepostet.

 

Die Fehlöermeldung beim Zugriffsversuch auf http://192.168.1.16:8530/selfupdate/wuident.cab vom Client her per IE sieht aus wie folgt:

HTTP Error 403.2 - Forbidden: Read access is denied. (HTTP-Fehler 403.2 - Verboten: Lesezugriff verweigert.)

Internetinformationsdienste (Internet Information Services oder IIS)

 

Das passt zur Fehlermeldung IISADMIN 105. Mir bleibt wohl nichts anderes übrig als noch einmal das Passwort bei jedem einzelnen Eintrag von IUSR_Maschine zu prüfen.

 

Jupp, wenn Du die NTFS-Berechtigungen und die Rechte im IIS ausschließen kannst, dann ja.

 

Und sowas anderthalb Wochen vor dem Abgang in dieser Firma..

 

Na dann tust Du zum Schluß ja noch ein gutes Werk. ;)

[vision311 10]

Es ist nur ein Gedanke mit dem ich spiele:

WENN der IUSR_Maschine schon verschossen ist und ich auf drei Webseiten die Berechtigungen kontrollieren soll (Intranet läuft auch nur mit Lücken, haben Anwender berichtet) und WENN die Webseiten reichlich einfach in einem neuen IIS wieder eingepflegt sind, sollte ich nicht die Baustelle abreissen und IIS entfernen, neu installieren und auf grüner Wiese neu beginnen?

 

Wie schätzt Du das ein? Ich fürchte mich ein bisschen vor Folgefehlern in dem ganzen Gebilde, die später entdeckt werden. Nebst meinen geringen Kenntnissen gibt es nämlich keine weiteren in der Firma, die derzeit genügend Kenntnis haben, die Sache weiter zu verfolgen..