Massive Probleme beim Microsoft Januar Patchday

Diese Woche hatte ich massive Probleme nach dem Microsoft Januar Patchday am 11.01.2022. Die ausgelieferten Sicherheitsupdates haben auf den von mir betreuten Windowsservern einen Katastrophalen Schaden angerichtet. Dies scheint auch nicht nur mir so gegangen zu sein. Es gibt im Netz zahlreiche Berichte von anderen betroffenen und Günter Born hat einen Artikel bei Heise dazu geschrieben: Sicherheitsupdates vom Januar 2022 mit massiven Kollateralschäden in Windows. Gerade Installationen auf der Basis von Windows 2012R2 sind umfänglich betroffen.

Insbesondere von der Installation des Update KB5009624 auf Domain Controllern sollte man aktuell absehen. Es hat alle von mir betreuten Domain Controller in einee Boot-Loop (Boot-Schleife) geschickt und damit das gesamte Windowsnetzwerk lahmgelegt. Grund scheint ein Fehler im Modul lsass.exe zu sein. Auch darüber findet man weitere Details im Blog von Günter Born im Artikel Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife.

Nach der Deinstallation des Update KB5009624 auf den Domain Controllern funktionierten diese prinzipiell wieder, allerdings war einer der Domain Controller so beschädigt, dass er nicht mehr richtig funktionierte und sich auch standhaft weigerte mit den anderen zu replizieren. Alle Versuche diesen wieder zu reparieren blieben erfolglos. Erst als dieser von Hand gelöscht und komplett neu aufgesetzt wurde, nahm er wieder fehlerfrei seine Arbeit auf.

Nachdem alle Domain Controllern wieder einwandfrei arbeiteten, lief das Windowsnetzwerk prinzipiell wieder. Es gab aber haufenweise weitere Probleme im Windowsnetzwerk. Das gesamte IT Team war zwei Tage lang damit beschäftigt die Folgeprobelme und andere Fehlfunktionen des Microsoft Patchday zu lösen. Neben dem Boot-Loop auf Domain Controller traten bei uns auch noch folgenden Kollateralschäden durch den Microsoft Januar Patchday auf:

  • Nach dem Einspielen von KB5009624 und KB5009595 startete Hyper-V auf Windows 2012R2 nicht mehr. Informationen dazu findet man bei Microsoft im Artikel Virtual machines (VMs) in Hyper-V might fail to start
  • Nach dem ein Einspielen von KB5009624 auf den Windows 2012R2 Exchange Servern funktioniert ReFS nicht mehr. Sobald das Update deinstalliert wurde funktioniert dies zwar wieder. Mit Pech kann die Exchangeinstallation aber so beschädigt sein, dass man die Datensicherung zurückspielen muss.
  • Nach dem Einspielen der Updates funktionierte ein Cluster mit Windows 2012R2 Terminalservern nicht mehr. Selbst eine Deinstallation aller Updates und die anschließend komplette Neueinrichtung der Rollen konnte den Cluster nicht wieder richtig reparieren. Es gab andauernde nicht zu erklärende Fehlfunktionen. Deshalb wurde der Cluster von uns aufgegeben und die User auf einen neuen Cluster mit Windows 2019 Terminalservern migriert.

Ich habe Verständnis dafür, dass Hersteller wie Microsoft heute Sicherheitslücken sehr schnell schließen müssen, um die daraus resultierenden Gefahren für die Kunden schnell abzustellen. Ich finde die Informationspolitik zu den durch das Update verursachten Problemen von Microsoft jedoch völlig unzureichend. Warum gibt es nach wie vor keine offizielle Stellungnahme mit einer Auflistung der Probleme? Warum wurde auch drei Tage nach dem Erscheinen der Updates und den vielen Berichten über die Probleme die Update bis jetzt nur halbherzig zurückgezogen? Diese werden zwar aktuell nicht mehr automatisch ausgeliefert. Sie lassen sich im aber immer noch finden und ohne Warnung installieren. Siehe auch hier die Zusammenfassung von Günter Born Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?

Bis jetzt scheint es nur im Blog von Günter Born vernünftige Erklärungen, Zusammenfassungen und den aktuellsten Stand zu den massiven Problemen mit den Sicherheitsupdates des Microsoft Patchday vom 11.02.2022 zu geben. Vielen Dank von meiner Seite für diese gute Arbeit! Und der Weltkonzern Microsoft sollte sich fragen, warum das eigene Security Team so etwas nicht geschafft hat.

Exchange 2010: Ereignis-ID 6006 / SeSecurityPrivilege privilege is removed

Nach der Installation des Servicepack 2 für Mircosoft Exchange 2010 meldete die Ereignisanzeige andauernd eine Warnung “SeSecurityPrivilege privilege is removed …” mit einer wilden nummerischen SID und der Ereignis-ID 6006.

Nach einer Internetrecherche habe ich die Bedeutung dieser mal wieder herrlich verklausulierten Meldung herausgefunden. Microsoft will uns damit sagen, dass in der lokalen Sicherheitsrichtlinie

Verwalten von Überwachungs- und Sicherheitsprotokollen

die Exchangeserver nicht eingetragen sind. Diese Richtlinie ist in der Registry unter dem Pfad

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten\

zu finden. Normaler Weise sollten hier die beiden Standardgruppen “Exchange Servers” und “Exchange Enterprise Servers” stehen. Wenn man diese beiden Gruppen dort einträgt, gibt es zukünftig keine Warnungen in der Ereignisanzeige mehr.

Anzeigen der Postfachgröße bei Exchange 2010

Wer einen Server mit Microsoft Exchange betreibt ist oft auf der Suche nach den Benutzern, die zu viel Speicherplatz belegen. Leider gibt es in der grafischen Konsole von Exchange 2010 keine Möglichkeit in einer Liste alle Mailboxen mit ihrer Größe anzuzeigen. Um eine solche List zu erhalten benötigt man also die Power Shell. Die brauchbaren Kommandos für die Power Shell haben jedoch leider den Nachteil, dass Sie sich durch ihre Länge und komplexität nicht sonderlich gut merken lassen. Deshalb habe ich mir im folgenden mal drei nützliche Varianten zum ermitteln der Mailboxgröße aufgeschrieben.

Alle Mailboxen nach Größe anzeigen

get-mailboxdatabase | get-mailboxstatistics | Sort -Property TotalItemSize -descending| select-object DisplayName,@{expression={$_.TotalItemSize.value.ToMB()}}, Itemcount,ServerName

Alle Mailboxen nach Größe und mit Datenbank anzeigen

get-mailboxdatabase | get-mailboxstatistics | Sort -Property TotalItemSize -descending| select-object DisplayName,@{expression={$_.TotalItemSize.value.ToMB()}}, Itemcount,ServerName,Database |ft

Alle Mailboxen einer Datenbank auflisten
(anstelle von Test muss hier der DB-Name eingesetzt werden)

get-Mailboxdatabase -Identity "Test" | get-mailboxstatistics | Sort -Property TotalItemSize -descending| select-object DisplayName,@{expression={$_.TotalItemSize.value.ToMB()}},Itemcount,ServerName

Autodiscover bei Outlook abschalten

Die Autodiscover Funktion von Outlook ist eine nützliche Sache, die einen bei gemischten Umgebungen mit mehre Firewalls, DNS- und Exchangeservern in die Verzweiflung treiben kann. Vielleicht hat Microsoft deshalb ja sogar einen Song über Autodicover auf der Technet-Webseite veröffentlicht 😉


http://gallery.technet.microsoft.com/The-Autodiscover-Song-a68b9f7c

Leider läuft ab Outlook 2007 ohne autodiscover einiges nicht mehr (z.B. Free and Busy Informationen, der Abwesenheitsassist, das Offline Address Book usw). Dies lässt sich allerdings umgehen, indem man für den Client das Autodiscover abzuschalten. Im folgenden ein paar Registry-Einträge einem dies ermöglichen:

HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: DisableAutoStartup
Set to 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: ZeroConfigExchange
Set to 1
2. Free Busy:
Outlook 2007 zwingen den Public Folder Free/Busy zu nutzen:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Calendar
DWORD: UseLegacyFB
Wert:
0 (oder nicht vorhanden) = default Einstellung - Autodiscover nutzen
1 = public folder free/busy nutzen

Berechtigungen bei einem Exchange Server 2010 neu setzen

Unter bestimmten Umständen kann es dazu kommen, dass die Berechtigungen bei einem Exchange Server 2010 Server falsch gesetzt sind. Ich hatte neulich z.B. den Fall, dass interne E-Mails trotzt korrekter Konfiguration nicht von einem zum anderen Server übermittelt wurden.

Für solche Fälle gibt es den Schalter /preparelegacyexchangepermissions für die setup.exe. Wenn man die setup.exe mit diesem Parameter auf dem Server erneut startet, werden die Berechtigungen erneut gesetzt.

Outlook 2003 für Exchange 2010 verwenden

Wenn man mit Microsoft Office Outlook 2003 auf ein Microsoft Exchange Server 2010-Postfach zugreift, werden E-Mail die gelöscht oder verschoben wurden noch längere Zeit im Ordner angezeigt. Dies liegt daran, dass Microsoft bei Exchange 2010 keine UDP-Benachrichtigungen mehr an Outlook versendet.

Da sehr viele Kunden noch Outlook 2003 einsetzen, hat Microsoft diese Funktion aber mit “Update Rollup 3 für Exchange Server 2010 Service Pack 1” wieder ermöglicht. Damit die UDP-Benachrichtigungen wieder gesendet werden, muss allerdings zusätzlich der folgende Registrierungsschlüssel inklusive Subschlüssel erstellt werden:

SubkEy-Speicherort: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
SubkEy-Name: EnablePushNotifications
Typ: REG_DWORD
Wert: 1

Nähere Informationen findet man in dem Microsoft Knowledge Base Artikel 2009942.

Exchange: Autodiscover für externe Clients mit Outlook

Die automatische Konfiguration von Outlook erfolgt ab Version 2007 über die Datei autodiscover.xml. Ein externer Outlook-Client (also einer der nicht in der Domain des Exchangeservers ist) sucht diese Datei im Verzeichnis autodiscover auf einem Server mit dem DNS-Namen autodiscover.[Domain].[TLD]. Wenn ein externer Outlook-Client also mit einem Exchange-Server der Domain microsoft.de aufbauen soll, würde diese unter der URL https://autodiscover.microsoft.de/autodiscover/autodiscover.xml nach seiner Konfiguration suchen.

Eigene SSL-Zertifikate bei Exchange 2007 und 2010

Oft werden für Exchange Server eigene SSL-Zertifikate von thawte/VeriSign, Comodo oder ähnlichen Ausstellern verwendet. Dadurch gibt es bei dem ersten Aufruf von einem Client aus keine lästigen Meldungen, bei denen das “Zertifikat eines unbekannten Ausstellers” als vertrauenswürdig bestätigt werden muss. Wenn der Exchange-Server im LAN eine anderen Namen oder eine andere Domäne verwendet meldet Outlook nach dem Wechsel des Zertifikates bei jedem Start: “Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Webseite überein.” Dies liegt daran, dass der Common Name des Zertifikates nicht dem internen Namen des Exchange-Servers entspricht.

Um das Problem zu lösen muss man in der Exchange Management Shell die folgenden Befehle eingeben (dabei sollten der CAS_Server_Name und die URL natürlich entsprechend angepasst werden):

Set-ClientAccessServer -Identity CAS_Server_Name -AutodiscoverServiceInternalUri https://mail.contoso.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)" -InternalUrl https://mail.contoso.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)" -InternalUrl https://mail.contoso.com/oab
Set-UMVirtualDirectory -Identity "CAS_Server_Name\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.contoso.com/unifiedmessaging/service.asmx

Wobei der letzte Befehlt nur bei Exchange 2007 benötigt wird. Danach sollte man im IIS Manager noch die MSExchangeAutodiscoverAppPool Anwendung im Anwendungspool “Wiederverwenden” (tolle Übersetzung Microsoft!)

Nähere Informationen sind bei Microsoft im Knowledge Base Artikel 940726 zu finden.

Mac OS X: Synchronisierung mit einem Exchange-Server

Im Gegensatz zu Microsoft, die E-Mails, Termine und Kontakte in Outlook bündeln, liefert Apple bei Mac OS X dafür die drei Programme Mail, iCal und Adressbuch aus. Um die Funktionalitäten von Outlook auf einem Apple zu nutzen muss man also diese drei Programme verwenden.

Wenn man in Microsoft-Umgebungen Outlook für Kollaboration (Gruppenterminplanung, Ressourcenplanung, Dokumentenfreigabe usw.) verwenden möchte hat Microsoft dafür den Exchange-Server im Angebot. Apple hat bis jetzt keine entsprechende Software im Sortiment. Ab Mac OS X “Snow Leopard” liefert Apple aber einen sogenannten “Out-of-the-box Support” für Microsoft Exchange mit. Dabei ist jedoch zu beachten, dass Apple dafür ein “Microsoft Exchange Server 2007 Service Pack 1 Update Rollup 4” erwartet. Bei einem Exchange 2003 lief bei mir nur Mail. iCal und das Adressbuch funktionierten nicht.

Im folgenden nun eine kleine Anleitung für die Einrichtung eines Mac OS X “Snow Leopard” für die Zusammenarbeit mit einem Exchange 2007. Exchange 2010 habe ich bis jetzt noch nicht getestet, werde dies aber demnächst nachholen.

Mail
Mail nutzt das IMAP- und SMTP-Protokoll sowie die OWA-Schnittstelle (Outlook Web Access). Die Voraussetzung für die Verwendung von Mail ist also, dass diese Protokolle und Dienste auf dem Exchange-Server richtig eingerichtet wurden und erreichbar sind. Wenn dies gegeben ist kann man Mail mit drei Schritten über den Dialog zum einrichten neuer Accounts einrichten. Wenn man Mail das erste mal öffnet, startet dieser automatisch. Wenn der Benutzername “tester” und der IMAP-, SMTP- und OWA-Server “mail.appletest.de” heißen, sieht dies wie folgt aus:

iCal
Wenn Mail für die Verwendung eines Exchange-Server konfiguriert ist, sollte auch iCal auf den Exchange-Server zugreifen können. Um den Kalender angezeigt zu bekommen, muss man nur noch iCal starten und den Kalender über “Ablage” > “Name des Exchange Accounts bei Mail” öffnen.

Adressbuch

  • Das Programm “Adressbuch” öffnen und “Adressbuch” > “Einstellungen” wählen.
  • Im Bereich “Allgemein” die Option “Mit Exchange-Server synchronisieren” auswählen und und auf “Konfigurieren” klicken (falls erforderlich).
  • Exchange Benutzernamen, das Kennwort und die OWA Server-Adresse eingeben.
  • “Stündlich synchronisieren” wählen, wenn die Daten im Stundentakt synchronisiert werden sollen.

Reparatur einer Microsoft Exchange Datenbank

Wenn sich bei einem Exchange 2000 oder 2003 Server die Datenbank nicht mehr mounten lässt kann man versuchen diese mit den Kommandozeilen-Tools ESEUTIL und ISINTEG zu reparieren (ab Exchange 2007 wurden diese Tools in die Exchange Management Console eingebaut und können dort aufgerufen werden). Man sollte jedoch etwas Zeit mitbringen und vorher eine Datensicherung machen. Microsoft weißt nämlich explizit darauf hin, dass durch diese Tools auch Daten verloren gehen können und bei einer Datenbankgröße von 50 GB kann der Vorgang schon mal einen ganzen Tag dauern. Während der Reparatur wird jeweils im aktuellen Pfad eine temporäre Datenbank erstellt, die ca. 20% der alten Datenbankgröße benötigt. Der Pfad dieser Datenbank kann bei Bedarf mit dem Schalter /t geändert werden.

Im folgenden nun die einzelnen Schritte, mit denen ich bis jetzt die besten Erfolge beim reparieren einer Microsoft Exchange Datenbank erzielt habe:

  • SMTP Server anhalten (falls noch aktiv)
  • “ESEUTIL /MH DATENBANK” ausführen
    Zeigt den Status der Datenbank an.
  • “ESEUTIL /P DATENBANK” ausführen
    Diese Option versucht eine defekte Datenbank wieder “clean” zu bekommen, indem diese komplett neu aufgebaut wird und fehlende Verbindungen und Seiten dabei einfach entfernt werden.
  • “ISINTEG.EXE -s -fix -test alltests” ausführen
    Falls Tool nicht läuft, Transaction Logs in ein Backupverzeichnis verschieben. Auftretende Warnungen können ignoriert werden, sollten jedoch Fehler angezeigt werden, muss ISINTEG.EXE -s -fix -test alltests solgange wiederholt werden, bis keine Fehler mehr auftreten.