Windows Update Fehler 80244007 (WSUS)

Problem:

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

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):
WSUS_SQLServer

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
    WSUS_feature_postinstall
  5. nun den WSUS-Dienst neu starten und schon können Clients wieder Updates suchen und das WSUS MMC-SnapIn funktioniert auch wieder

Netzlaufwerke von Gruppenrichtlinien werden nach Windows 10 Upgrade nicht mehr verbunden.

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)
unc-hardening

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.

WLAN zu langsam

Kunde: „Das WLAN ist zu langsam!!11 Wenn ich eine Datei auf mein Notebook kopiere dauert das ewig und er kopiert nur mit 27mbit/s“

Admin: „Das WLAN ist schnell, die Karte in dem [ur]alten Macbook ist langsam.“

Kunde: „Unsinn, WLAN ist WLAN und das WLAN hat 300Mbit/s“

Admin: „Naja, aber die Karte kann nur 802.11g, das sind 54mbit/s“

Kunde: „Aber das WLAN hat doch 300MBit/s!!!111!“

Admin: „Ja, auch eine Autobahn hat immer 300km/h, trotzdem kann mein Heizölporsche nur 120 fahren“

Kunde: (überlegt … länger … und schaut dann mit großen Augen auf) „Oh … ah … achso! Stimmt.“ *Nimmt sein Notebook und geht*

🙂

vmWare vSphere 5.1/5.5 Client installiert auf Windows Server 2012R2 nicht

Problem

Der vSphere Client 5.1 lässt sich auf Windows Server 2012R2 nicht installieren. Es gibt keine Fehlermeldung, sondern das Setup verschwindet beim start der eigentlichen Installation einfach vom Desktop. Im Taskmanager ist der Installationsprozess aber noch zu sehen.

vmware-viclient-server2012r2

Lösung

Schuld ist das Fehlen des .NET Frameworks 2.0, was im .NET Framework 3.0 enthalten ist, was wiederum im Windows-Feature .NET Framework 3.5.1 versteckt wurde. Es hilft die Installation des .NET Framework 3.5 Features über den Servermanager -> Rollen und Features hinzufügen -> Weiter -> Weiter -> .NET Framework 3.5\.NET Framework 3.5.

 

 

Howto: vmware vSphere vCenter 5.5 mit Active Directory einrichten

Die Einrichtung des vCenter Servers mit dem Active Directory als Identitätsquelle ist etwas umständlich zu erledigen als unter 4.x/5, aber der Aufwand lohnt sich. Das SSO-Backend unter vSphere 5.5 ist praktisch komplett neu geschrieben und daher deutlich gradliniger als das SSO-Gebastel von früher. Leider ist dabei einiges an Adminfreundlichkeit auf der Strecke geblieben.

Ziel dieses Artikels: Ein vCenter Server soll gegen ein Active Directory („Windows Sitzungs-Anmeldedaten verwenden“) authentifizieren. Netzwerkdaten, DNS, Hostnamen und so weiter sind korrekt eingerichtet und der vCenter Server läuft soweit.

1. vCenter zum Active Directory hinzufügen

vCenter Verwaltungs-Weboberfläche (https://vcenter55:5480) öffnen.

  1. Als root anmelden
  2. Tab vCenter Server -> Authentication den Haken bei „Active Directory Enabled“ setzen und passende Domänenanmeldedaten eingeben
  3. „Save Config“
  4. Unter „SSO“ den Usernamen für den SSO-Login merken und ein Kennwort konfigurieren
    vcenter-active-directory-sso-username
  5. vCenter Server neu starten: System -> Reboot

vcenter-active-directory-enable

2. Identitäsquelle hinzufügen

  1. In den vSphere Webclient als der (oben gemerkte) SSO-Administrator einloggen (https://vcenter55.wittgastec.de:9443/vsphere-client)
  2. Verwaltung -> Konfigurationvcenter-active-directory-hinzufuegen
  3. Oben links auf das grüne Plus, die Identitätsquelle hinzufügen und das Fenster ausfüllenvcenter-active-directory-aktivieren
  4. Domäne auswählen und „Als Standartdomäne festlegen“
    vcenter-ad-sso-standart

3. Rechte für Domänen-Benutzer oder Domänen-Gruppen hinzufügen

Der Einfachheit halber nutze ich jetzt den guten alten vSphere (C#-) Client. Flash ist für die Weboberfläche ja ein dermaßen üble Wahl, das ich soweit möglich beim Client leiben werde. Aus Abwärtskompatibilitätsgrünen kann man als Admin darauf ja eh nicht wirklich verzichten. Also Client auf und als root am vCenter anmelden.

  1. Den vCenter Server auswählen -> Berechtigungen -> unten rechte MT und „Berechtigungen hinzufügen“
  2. Einen neuen Benutzer „Hinzufügen“ und in dem Hinzufügen-Fenster oben die Domäne auswählen vcenter-active-directory-benutzer-auswaehlen
  3. Gewünschte Rechte vergeben
    vcenter-active-directory-rechte

Schon fertig 🙂

VMWare ESXi: „Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine Coredumps für den Host gespeichert werden.“

Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine coredumps für den Host gespeichert werden

Es gibt zwei Möglichkeiten, die Meldung „Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine coredumps für den Host gespeichert werden“ los zu werden. Es gibt den „sauberen“ Weg, der ein neues Ziel für die Kerneldumps angibt, und den schnellen und einfachn Weg, Coredumps ab zu schalten.

Neues Ziel für coredumps konfigurieren

1) Per SSH am Server anmelden und die coredump Konfiguration anschauen:

~ # esxcfg-dumppart -l
Configured Dump Partition Not Found, Skipping

3) Freie Partitionen für Coredumps anschauen:

~ # esxcfg-dumppart -f

4) Die passende Partition zur coredump config hinzufügen:

~ # esxcfg-dumppart -s name

Zum Beispiel: esxcfg-dumppart -s naa.444408f4444000071c57384957867ee:7

Danach steht in der Ausgabe von esxcfg-dumppart -l in der Spalte „Is Active“ bei der entsprechenden Partiton ein „Yes“ und die Meldung im vSphere Client ist verschwunden.

Alternativ: Coredumps abschalten

Die coredump.Funktion des Kernels lässt sich auch komplett deaktivieren. Das geht unter Konfiguration -> Erweiterte Einstellungen -> VMKernel. Danach ist ein Host-Reboot notwendig.

es-wurde-kein-ziel-fuer-coredumps-konfiguriert-abschalten

vSphere Lost connectivity to the device mpx.vmhba32:C0:T0:L0 (HP ProLiant Gen9 Server from SD-Card)

Nach „einer Weile“ verliert ein HP ProLiant G9 die Verbindung zu seiner lokal eingesteckten (selbstverständlich „HP Enterprise“) SD-Karte:
Lost connectivity to the device mpx.vmhba32:C0:T0:L0

vmware-esxi-sd-card_lost-connection

Zum Glück läuft der VMware  ESX(i) seit Version 5 aus dem Hauptspeicher, läuft also problemlos weiter, bis er etwas schreiben möchte (Hostprofile zum Beispiel). In der Regel bootet der Server nach einem Herunterfahren (ausschalten) und einem kurzen Stromlosmachen (5-20 Sekunden) wieder.

Das passiert bis ILO Firmware 2.2x, der Fehler ist in Version 2.30 und höher behoben. Aktuell ist ILO Version 2.42.

Programme von Netzlaufwerken crashen nach Upgrade von Windows 7

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“ ofen 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.

Exchange 2013 internes Relay nach „RCPT TO:“ sehr langsam

exchange-delay-after-rcpttoProblem

Ein Exchange 2013 Receive Connector reagiert nach dem RCPT-Kommando extrem langsam. so langsam, das verschiedene SMTP-Clients sogar mit einem timeout reagieren. Die Zustellung klappt aber in den meisten Fällen.

Lösung

Der Empfangsconnector umgeht warscheinlich die Anti-Spam Agents nicht. In der Standarteinstellung hat eine Anonyme Verbindung (wie es bei einem Relay meistens der Fall ist) auf einem Connector nicht das Recht, die lokalen Filter zu umgehen. Daher kommt es zu (RBL und Tarpitting) Wartezeiten.

Umgehen der filter für Anonyme Verbindunge erlauben:

[PS] C:\> Get-ReceiveConnector -Identity "SERVER\Connectorname" | Add-ADPermission -user "NT-Autorität\Anonymous-Anmeldung" -ExtendedRights Ms-Exch-Bypass-Anti-Spam

In der Englischen Version eines Active Directory ist die (in UTF-8 geschriebene) „NT-Autorität\Anonymous-Anmeldung“ durch das entsprechende Prinzipal eines EN Active Directory zu ersetzen: „NT AUTHORITY\ANONYMOUS LOGON“.

In einen sehr guten Artikel zu dem Thema Connectoren“ hat der Zach schon vor einer Weile die wichtigen eigenschaften und das Schema zusammengefasst: http://www.the-little-things.net/blog/2014/07/06/exchange-receive-connector-tango-part-1/