Autoren-Archiv: snacky

Problem:

WSUS Clients (in diesem Fall Windows Server 2012 R2) können nicht nach Updates suchen (Fehler 0x80244007).
Folgendes zeigt die WSUS-Verwaltungskonsole:

Kopiert man den Fehler in die Zwischenablage, beinhaltet diese (in etwa) folgendes:

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.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   bei System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   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.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.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)
   bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
   bei Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.get_ServerTools()

Fügt man das WSUS-SnapIn manuell einer MMC hinzu und will sich mit dem Server verbinden erhält man folgende Meldung (wobei ‚SQUID‘ natürlich den jeweiligen Servernamen darstellt):

Zu guter Letzt findet man folgenden Auszug in der Ereignisanzeige:

Fehler bei der Anmeldung für den Benutzer 'NT-AUTORITÄT\Netzwerkdienst'.Ursache: Fehler beim Öffnen der explizit angegebenen Datenbank 'SUSDB'. [CLIENT: ]

(Event-Quelle: MSSQL$MICROSOFT##WID; Event-ID: 18456)

Lösung:

Ursprung des Problems ist ein fehlerhaftes Windows Update auf dem WSUS Server (KB3148812).
Sollte dieses installiert sein (und die erforderlichen post-install Schritte noch nicht durchgeführt sein), ist die Empfehlung des WSUS-Teams (Blogbeitrag), das Update einfach wieder zu deinstallieren.

Anderenfalls kann das ersetzende Update KB3159706 die Ursache sein. Es wird als „The long-term fix for KB3148812 issues“ beschrieben, benötigt aber ebenfalls einige post-install Schritte um fehlerfrei zu funktionieren:

1. das KB3159706 installieren (sofern noch nicht geschehen)
2. eine Kommandozeile mit Admin-Rechten starten
3. den Befehl „C:\Program Files\Update Services\Tools\wsusutil.exe“ postinstall /servicing ausführen
4. daraufhin im Server-Manager das Feature „HTTP-Aktivierung“ hinzufügen, zu finden unter .NET-Framework 4.5-Funktionen -> WCF-Dienste -> HTTP-Aktivierung
   
5. nun den WSUS-Dienst neu starten und schon können Clients wieder Updates suchen und das WSUS MMC-SnapIn funktioniert auch wieder

Problem:

Nach dem (erfolgreichen) Update von Windows 7 auf Windows 10 werden „plötzlich“ Netzlaufwerke nicht mehr eingebunden, welche per GPO verteilt werden.
In der Ereignisanzeige findet man i.d.R. folgenden Fehler:

Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\foo.bar\SysVol\foo.bar\Policies\{UID}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.

Ursache ist in diesem Fall meist das UNC-Hardening, welches unter Windows 10 standardmäßig aktiviert ist.

Lösung:

Einfachste Lösung ist eine neue GPO anzulegen, welche das UNC-Hardening für die SYSVOL und ggfs. NETLOGON Freigabe wieder deaktiviert.
Dazu unter „Computerkonfiguration > Administrative Vorlagen > Netzwerk > Netzwerkanbieter “ die Richtlinie für Gehärtete UNC-Pfade aktivieren und folgende Einträge hinzufügen:

Wetname: \\*\SYSVOL
Wert: RequireMutualAuthentication=0, RequireIntegrity=0
(ggfs. für \\*\NETLOGON den selben Wert hinzufügen)

Bei der nächsten Anwendung der Gruppenrichtlinien an den Clients (spätestens nach einem Neustart) wird dann auch die Netzlaufwerke-GPO wieder angewendet und somit die Netzlaufwerke wieder eingebunden.

Problem

Nach dem (erfolgreichen) Update von Windows 7 auf Windows 10 stürzen auf einigen Arbeitsstationen auf einmal Programme ab, die „jahrelang“ völlig stabil liefen. Betroffen sind Prgoramme, die von Netzlaufwerken gestartet werden oder von Netzlaufwerken und UNC-Pfaden DLLs (nach)laden. Betroffen sind Windows 8/8.1 und hauptsächlich Windows 10.

Lösung

Seit Windows 8 werden offene SMB-Sitzungen zu Netzlaufwerke und UNC-Pfaden nach einer gewisser Leerlaufzeit (standardmäßig 15 Minuten) getrennt (autodisconnect und keepconn) um den Fileserver zu entlasten. Bei „moderner“ Software und Programmen die alle benötigten Bestandteile nur einmal laden ist das kein Problem – schwierig wird es bei klassischen Programmen die davon ausgehen, das eine SMB-Sitzung „ewig“ offen bleibt.

Die entsprechenden Werte kann man per Registry (oder via GPO) anpassen:

HKLM\System\CurrentControlSet\services\LanmanWorkstation\Parameters

ein DWORD-Wert „KeepConn“ mit dem Wert „FFFF“ (HEX) Anlegen und zudem unter

HKLM\System\CurrentControlSet\services\LanmanServer\Parameters

ein DWORD „autodisconnect“ mit dem Wert „FFFFFFFF“ (HEX) Anlegen.

Ergänzend: Bei Netzlaufwerken, welche per GPO verteilt werden, kann auch das Ändern der Richtlinie von „Ersetzen“ auf „Aktualisieren“ helfen. Die Einstellung „Element entfernen, wenn es nicht mehr angewendet wird“ ist dann leider nicht mehr möglich, aber Windows behält dann über die Anwdung einer GPO hinweg die Laufwerksverbindung bei.