Exchange Server 2019 SE und Sicherheitsupdates

🔐 Exchange Server 2019 SE (Subscription Edition) ist nicht direkt vom Supportende am 14. Oktober 2025 betroffen. Diese Version wurde speziell dafür entwickelt, auch nach dem offiziellen Supportende weiterhin Sicherheitsupdates und neue Funktionen zu erhalten.

Betroffen vom Supportende sind:

• Exchange Server 2019 CU14/CU15
• Exchange Server 2016 CU23

Für diese Versionen bietet Microsoft ab 1. August 2025 ein kostenpflichtiges Extended Security Update (ESU)-Paket an, das bis 14. April 2026 gilt. Diese ESUs enthalten nur kritische und wichtige Sicherheitsupdates, sind nicht öffentlich verfügbar und müssen über Microsoft bezogen werden.

🧭 Empfehlung von Microsoft

Microsoft empfiehlt dringend, rechtzeitig auf die Exchange Server Subscription Edition (SE) umzusteigen, da:

• ESUs keine Garantie auf Updates bieten
• Der Support für Exchange 2019 endgültig am 14.10.2025 endet
• Die SE-Version ab Juli 2025 verfügbar ist und ein In-Place-Upgrade von Exchange 2019 möglich sein wird

📄 Hinweise

In mehreren internen Sicherheitscheck-Dokumenten wird betont, wie wichtig die regelmäßige Aktualisierung von Exchange-Servern ist, insbesondere im Hinblick auf Sicherheitslücken und Compliance. Auch in internen Mails wurde bereits auf das Supportende und die Risiken hingewiesen.

✅ Fazit

Da auch Exchange Server 2019 SE nun ein Mietprodukt ist und der „Betrieb in eigenen Räumlichkeiten mit höhereren Risiken verbunden ist, als ein SaaS Online-Dienst wie Exchange Online, ist die Exchange Online-Variante zu bevorzugen und in Vollkostenrechnung wirtschaftlicher.

Exchange Server 2019 SE ist nicht betroffen vom Supportende, sondern stellt die empfohlene Lösung dar, um nach dem 14. Oktober 2025 weiterhin Sicherheitsupdates zu erhalten. Wenn du noch Exchange Server 2019 (nicht SE) nutzt, solltest du entweder:

• auf Exchange SE migrieren, oder
• ein ESU-Paket für 6 Monate erwerben (nur über Microsoft erhältlich)

Zwei kritische Schwachstellen in Azure-nahen Diensten

Im Rahmen des #Microsoft Patchday im September 2025 wurden zwei besonders kritische #Sicherheitslücken veröffentlicht, die Azure-nahe Komponenten betreffen. Organisationen, die Azure Automation oder Azure AD Connect (Entra ID Synchronisation) einsetzen, sollten dringend handeln.

CVE-2025-29827 – Azure Automation Runbook Execution Engine

Betroffene Komponente:
Azure Automation Runbook Execution Engine, insbesondere bei Einsatz von Hybrid Worker Nodes oder lokal ausgeführten Runbooks.

Risiko:
Ein lokal authentifizierter Angreifer kann manipulierte Runbooks nutzen, um Systemrechte zu erlangen.

Erforderlicher Patch:

• Sicherheitsupdate KB50329827 für Windows Server 2019/2022 auf Hybrid Worker Nodes.
• Aktualisierung der Runbook Engine über das Azure Portal oder PowerShell (Update-AzAutomationAccount).

Empfohlene Maßnahmen:

• Runbooks auf verdächtigen Code prüfen.
• Audit-Logs aktivieren.
• Least-Privilege-Prinzip für Runbooks durchsetzen.

CVE-2025-29972 – Azure AD Connect (Entra ID Synchronisation)

Betroffene Komponente:
Azure AD Connect, das für die Synchronisation zwischen lokalem Active Directory und Azure AD (Entra ID) verwendet wird.

Risiko:
Ein Angreifer kann durch manipulierte Synchronisationsprozesse administrative Rechte erlangen.

Erforderlicher Patch:

• Sicherheitsupdate KB50329972 für Azure AD Connect (mindestens Version 2.1.20.0).
• Aktualisierung des Azure AD Connect Health Agent über Microsoft Update oder manuell.

Empfohlene Maßnahmen:

• Sync-Konten auf unnötige Rechte prüfen.
• Multi-Faktor-Authentifizierung (MFA) aktivieren.
• Audit-Logs für Synchronisationsaktivitäten aktivieren.

Fazit

Die beiden Schwachstellen zeigen, wie wichtig es ist, auch Cloud-nahe Dienste wie Azure Automation und Azure AD Connect regelmäßig zu patchen und abzusichern. Unternehmen sollten die genannten Updates zeitnah installieren, idealerweise innerhalb von 7 Tagen nach Veröffentlichung, wie es auch in internen Sicherheitsrichtlinien empfohlen wird.

Sysprep erzeugt keine eindeutigen vm IDs

Wenn man Sysprep beim Klonen von Windows-VMs verwendet, kann es passieren, dass alle geklonten Systeme die gleiche IdentifyingNumber aus Win32_ComputerSystemProduct erhalten – insbesondere bei virtuellen Maschinen (VMs).

🧩 Warum ist das so?

IdentifyingNumber stammt aus SMBIOS

• Die Eigenschaft Win32_ComputerSystemProduct.IdentifyingNumber wird vom SMBIOS geliefert.
• Bei physischen PCs enthält sie z. B. die Seriennummer des Mainboards.
• Bei VMs (z. B. Hyper-V, VMware, VirtualBox) wird dieser Wert vom Hypervisor simuliert oder fix vorgegeben.

Sysprep verändert SMBIOS-Werte nicht

• Sysprep entfernt Benutzerinformationen, SIDs, Netzwerkkonfigurationen etc.
• Aber es verändert keine Hardwareinformationen wie:
  • IdentifyingNumber
  • UUID (aus Win32_ComputerSystemProduct.UUID)
  • SerialNumber (aus Win32_BIOS)
• Diese Werte bleiben nach dem Sysprep-Klonen identisch, wenn der Hypervisor sie nicht automatisch generiert oder du sie manuell ersetzt.

⚠️ Warum ist das ein Problem?

Asset-Management

Tools wie SCCM, GLPI, OCS Inventory oder Lizenzsysteme nutzen IdentifyingNumber zur Erkennung von Geräten.
➡️ Wenn alle VMs die gleiche ID haben → Geräteüberschreibung.

Lizenzierung

Software, die per Hardware-ID lizenziert wird (z. B. manche PHP-Verschlüsselungen, SQL-Server-Bindungen), wird beim Klonen ungültig oder doppelt registriert.

🛠 Lösung: Eindeutige SMBIOS-IDs zuweisen

Für Hyper-V:

powershellKopierenBearbeitenSet-VMFirmware -VMName "VM-Name" -SystemSerialNumber "DEINE-EINDEUTIGE-ID"

Für VMware Workstation/ESXi:

• In .vmx-Datei: iniKopierenBearbeitenuuid.bios = "56 4d 12 34 56 78 90 ab-cd ef 12 34 56 78 90 ab" serialNumber = "VM-1234567890"

Für VirtualBox:

cmdKopierenBearbeitenVBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/SerialNumber" "UNIQUE-ID"

⚠️ Diese Werte müssen vor dem ersten Boot nach dem Klonen gesetzt werden.

✅ Empfohlener Klon-Prozess für VMs mit Sysprep

1. Sysprep ausführen (generalize + shutdown)
2. VM nicht sofort starten, sondern:
   • eine neue UUID, Seriennummer, MAC-Adresse etc. konfigurieren
3. Erst danach VM starten und initialisieren lassen

🔒 Alternative: Bessere Hardware-IDs nutzen

Wenn du eine eindeutige Systemkennung brauchst, verwende eine dieser Optionen:

Oder:
Erzeuge bei Erststart eine eindeutige Kennung (z. B. GUID in Datei/Registry) → das ist verlässlich, selbst bei gleichen Hardware-IDs.

🧾 Fazit