Wie schalte ich Exchange, Active Directory und DNS nach der Microsoft-365-Migration sauber ab, ohne Mailflow- und Auth-Probleme?

Restabhängigkeiten nach der Migration: warum „nicht genutzt“ nicht „abschaltbar“ bedeutet

Nach einer erfolgreichen Migration zu Microsoft 365 wirkt die On-Prem-Landschaft oft wie ein entbehrlicher Altbestand: Postfächer liegen in Exchange Online, Teams ersetzt Telefonie- und Chat-Inseln, SharePoint Online löst Fileserver ab. „Nicht mehr genutzt“ beschreibt jedoch nur die sichtbare Benutzerperspektive. Für eine Abschaltung zählt stattdessen, ob Systeme noch als technische Referenz, Transitstrecke oder Autorität in Protokollen, Verzeichnissen und Namensauflösung fungieren. Genau diese verdeckten Rollen sind der Grund, warum das abrupte Trennen von Exchange-, Active-Directory- oder DNS-Komponenten regelmäßig Folgeschäden auslöst.

Restabhängigkeiten entstehen weniger aus „vergessenen“ Clients, sondern aus bewusst gesetzten Kopplungen: Hybrid-Designs benötigen Übergangsobjekte und Konnektoren, Identitäten werden weiterhin on-premises gemanagt, und DNS-Records bleiben als Einstiegspunkte für Autodiscover oder SMTP bestehen. Zusätzlich wirken Zwischenschichten wie Zertifikate, Reverse Proxies, Load Balancer oder Appliances, die noch immer auf interne Dienste zeigen. Erst wenn diese Beziehungen nachvollziehbar aufgelöst sind, wird eine Abschaltung zu einem kontrollierbaren Change statt zu einem Risikoereignis.

Typische Muster: „stillgelegt“ im Betrieb, aber weiterhin im Datenpfad

Ein Exchange-Server kann im Tagesgeschäft „unsichtbar“ sein und dennoch als zentrale Abhängigkeit verbleiben. Besonders häufig betrifft das den Mailfluss und die Service-Discovery. Beispielsweise senden Multifunktionsgeräte, Applikationen oder Netzwerkgeräte weiterhin über ein internes SMTP-Relay, während externe MX-Records längst auf Exchange Online Protection zeigen. Ebenso kann ein Autodiscover-Endpunkt auf ein ehemaliges On-Prem-Frontend verweisen, obwohl moderne Outlook-Clients oft automatisch korrigieren. Das Problem tritt dann verzögert auf: neue Geräte, neu installierte Clients oder geänderte Profile greifen wieder auf die alten Pfade zu.

Auch Active Directory wird nach einer Mailmigration selten automatisch entbehrlich. Solange Identitäten synchronisiert werden (Microsoft Entra Connect Sync bzw. Cloud Sync), bleibt AD die Attributquelle für UPN, Proxy-Adressen, Gruppenmitgliedschaften, Exchange-relevante Attribute oder Gerätezuordnungen. Selbst ohne Hybrid-Mailrouting kann das Schema und die Verwaltungsebene (z. B. Empfängerverwaltung, Gruppen) noch an Exchange-Management-Tools oder an definierte Prozesse gebunden sein. Eine Abschaltung ohne saubere Entkopplung führt dann nicht zu einem klaren „aus“, sondern zu schleichender Dateninkonsistenz: Objekte lassen sich nicht mehr korrekt pflegen, Attribute driften, und spätere Korrekturen werden aufwendig.

Abhängigkeiten, die erfahrungsgemäß übersehen werden

Die kritischen Restabhängigkeiten lassen sich in wenige Kategorien ordnen, die sich jeweils konkret prüfen lassen. Entscheidend ist die Unterscheidung zwischen „Konfiguration existiert noch“ und „Konfiguration wird noch genutzt“: Ein verwaister DNS-Record ist harmlos, solange kein Client ihn abfragt; ein Konnektor ist unkritisch, solange kein System darüber sendet. Umgekehrt genügt ein einzelnes Legacy-System, um eine komplette Abschaltplanung zu blockieren.

• Autodiscover und Service-Endpunkte: DNS-Records wie autodiscover.example.tld oder SCP-Einträge im AD können weiterhin auf interne URLs zeigen; prüfen lassen sich SCPs serverseitig u. a. mit Get-ClientAccessService | Select Name,AutoDiscoverServiceInternalUri (Exchange 2013–2019; in reinen Exchange-2019-Umgebungen ist das Cmdlet weiterhin relevant).
• SMTP-Relay und interne Sender: Applikationen, Scanner, Monitoring-Systeme oder ERP nutzen häufig feste Smarthosts; Indikatoren sind Connector- und Protokolldaten, z. B. Get-ReceiveConnector und Message-Tracking via Get-MessageTrackingLog (nur auf Exchange On-Prem; abhängig von aktivierten Transport-Logs und Aufbewahrungszeit).
• Hybrid-Konfiguration und Mailflussobjekte: In Microsoft 365 verbleiben Connectoren, Accepted Domains, Remote Domains und Transportregeln, die aus Hybridzeiten stammen; On-Prem können Objekte wie HybridConfiguration oder Federation-/OAuth-Konfigurationen relevant sein, z. B. Get-HybridConfiguration und Get-OrganizationConfig.
• Verzeichnisabhängigkeiten (AD als Autorität): Solange Synchronisierung aktiv ist, bleiben Änderungen an Benutzern/Gruppen an AD gebunden; typische Marker sind der Synchronisierungsstatus in Entra ID sowie der Nachweis, dass der SourceAnchor (historisch oft als „ImmutableId“ sichtbar) weiterhin aus AD abgeleitet wird.
• Zertifikate und TLS-Bindings: SMTP-TLS, Publishing-Endpunkte oder Reverse-Proxy-Konfigurationen nutzen Zertifikate, die noch auf Exchange-Hosts installiert sind; Prüfungen erfolgen über Exchange-Cmdlets wie Get-ExchangeCertificate sowie über Load-Balancer-/Proxy-Konfigurationen.
• DNS-Altlasten und CNAME-Ketten: Records wie mail.example.tld, legacy.example.tld, autodiscover.example.tld oder interne Split-DNS-Zonen können weiterhin auf stillgelegte VIPs zeigen; besonders riskant sind CNAME-Ketten, die bei Änderungen an einem Punkt wieder „aktiv“ werden.

Warum einzelne Records und Attribute eine Abschaltung blockieren können

Restabhängigkeiten sind selten gleichmäßig verteilt; häufig hängt alles an wenigen, aber zentralen Referenzen. Ein klassisches Beispiel ist Autodiscover: Selbst wenn 95 Prozent der Clients korrekt in die Cloud zeigen, reichen einige Sonderfälle (Outlook mit altem Profil, iOS-Mail-Accounts, Drittanbieter-Clients oder nicht aktualisierte GPOs), um auf einen nicht mehr vorhandenen Endpunkt zuzugreifen. Der Fehler wirkt dann wie ein „sporadischer“ Ausfall, obwohl er deterministisch ist: Der Client folgt seiner Konfigurationslogik und trifft auf einen toten Record.

Ähnlich kritisch sind Exchange-bezogene Attribute, solange Objekte aus AD synchronisiert werden. Viele Umgebungen behalten die Verwaltung von Proxy-Adressen und Verteilergruppen weiterhin on-premises bei, auch wenn kein Postfach mehr lokal existiert. Wird ein Exchange-Server in diesem Zustand entfernt, ohne die Management- und Attributpflege sauber zu ersetzen, entsteht ein operatives Vakuum: Änderungen sind zwar in der Cloud möglich, werden aber durch die Synchronisierung wieder überschrieben oder lassen sich wegen „source of authority“ nur eingeschränkt dauerhaft setzen. Das Problem zeigt sich erst beim nächsten Joiner/Leaver-Prozess oder bei einer Umbenennung.

Prüfprinzipien: vom „Konfigurationsinventar“ zur Nutzungsrealität

Eine belastbare Abschaltentscheidung entsteht aus zwei Perspektiven: Erstens muss die Konfiguration vollständig inventarisiert werden (DNS, Zertifikate, Connectoren, Hybrid-Objekte, AD-Sync, SCPs, Load-Balancer-Pools). Zweitens muss die tatsächliche Nutzung belegt werden. Für DNS bedeutet das Abfrage- und Resolver-Logs, für SMTP die Message-Tracking- und Gateway-Logs, für Autodiscover die Client-Zugriffe auf Webserver/Proxy und für AD die Synchronisierungs- und Änderungsflüsse. Wo Telemetrie fehlt, bleibt nur eine kontrollierte Umstellung mit Messfenster und Rückfalloption.

„Nicht genutzt“ ist damit keine Vermutung, sondern eine nachprüfbare Aussage: Kein Client fragt autodiscover.example.tld mehr intern ab, kein System verbindet sich per TCP/25 oder TCP/587 zum alten Smarthost, kein Reverse Proxy terminiert noch Zertifikate für mail.example.tld, und keine Prozesse erzeugen mehr AD-Änderungen, die zwingend on-premises erfolgen müssen. Erst wenn diese Bedingungen erfüllt sind, kann die anschließende Stilllegungsstrategie technisch sauber ansetzen.

Exchange On-Prem kontrolliert zurückbauen: Hybrid-Abbau, Relay-Prüfung, Accepted Domains und saubere Deinstallation

Ein Exchange-On-Prem-Server bleibt nach einer Microsoft-365-Migration häufig länger im Betrieb als fachlich erwartet – nicht wegen Postfächern, sondern wegen technischer Kopplungen: Hybrid-Konfiguration, SMTP-Relay für Geräte und Anwendungen, Autodiscover- und SPF-/MX-Logik, Zertifikate sowie die fortbestehende Rolle von Exchange-Attributen im lokalen Active Directory. Ein „Strom aus“ erzeugt in diesen Fällen keine saubere Stilllegung, sondern Folgefehler: Zustellprobleme, nicht mehr erreichbare Management-Endpunkte, veraltete Connectoren oder ein AD-Schema, dessen Verwaltungswerkzeuge fehlen.

Der Rückbau sollte daher als kontrollierte Demontage verstanden werden. Zielzustand ist eindeutig: keine produktiven Mailflüsse über On-Prem, keine Hybrid-Beziehungen, keine Abhängigkeit von Exchange-Diensten für Routing oder TLS-Termination, konsistente Domains und Connectoren in Microsoft 365, und ein On-Prem-Verzeichnis, das entweder ohne Exchange administrierbar bleibt oder bewusst weiterbetrieben wird.

Hybrid-Konfiguration gezielt entfernen statt „einfach abschalten“

In Hybrid-Szenarien steuert der Hybrid Configuration Wizard (HCW) unter anderem Connectoren in Exchange Online, Intra-Organization-Connectoren/Beziehungen für Koexistenzfunktionen sowie (je nach Ausprägung) die Nutzung von On-Prem als zentralem SMTP-Tor. Solange diese Bausteine aktiv sind, entstehen Abhängigkeiten, die beim Abschalten des letzten Exchange-Servers unmittelbar sichtbar werden: NDRs durch nicht erreichbare Smarthosts oder gestörte Koexistenzfunktionen, die noch von Prozessen, Systempostfächern oder Servicekonten genutzt werden.

Ein kontrollierter Hybrid-Abbau bedeutet, dass die Koexistenz explizit beendet wird: Mailrouting und Autodiscover werden vollständig auf Microsoft 365 umgestellt, nicht mehr benötigte Hybrid-Connectoren werden entfernt oder deaktiviert, und verbleibende zentrale Funktionen (z. B. Journal/Transportregeln, Disclaimer) werden in Exchange Online nachgebildet oder bewusst aufgegeben. In Umgebungen, in denen Directory Synchronization weiterhin betrieben wird, muss zusätzlich entschieden werden, wie Exchange-relevante Attribute künftig gepflegt werden (siehe Warnhinweise weiter unten).

• Hybrid-Status und Abhängigkeiten inventarisieren: Get-HybridConfiguration | Format-List
Get-IntraOrganizationConnector | Format-Table Name,Enabled,DiscoveryEndpoint
Get-OrganizationRelationship | Format-Table Name,Enabled,TargetAutodiscoverEpr
• Hybrid-Connectoren in Exchange Online prüfen (Beispiele): Get-InboundConnector | Format-Table Name,Enabled,SenderDomains,ConnectorType
Get-OutboundConnector | Format-Table Name,Enabled,SmartHosts,TlsSettings
• On-Prem-Mailflow-Objekte prüfen: Get-SendConnector | Format-Table Name,Enabled,AddressSpaces,SmartHosts,TlsDomain
Get-ReceiveConnector | Format-Table Name,Bindings,RemoteIPRanges,AuthMechanism

SMTP-Relay und Applikationsmail: die häufigste Restabhängigkeit

Viele Abschaltungen scheitern nicht am Hybrid, sondern am unsichtbaren „Drucker-und-ERP“-Verkehr. Geräte, Legacy-Applikationen und Monitoring-Systeme senden oft per SMTP an den On-Prem-Exchange (oder einen internen Smarthost), weil dort IP-basierte Annahme, Header-Normalisierung, TLS-Offloading oder das Weiterleiten in externe Domains historisch gelöst wurde. Wird dieser Pfad entfernt, brechen Prozesse ohne klare Fehlermeldung in der Fachanwendung.

Vor der Deinstallation muss daher ein Zielmodell für Relay feststehen: Microsoft 365 Direct Send (nur an interne Empfänger), SMTP AUTH Client Submission (mit modernen Authentifizierungsanforderungen) oder ein dedizierter Relaydienst bzw. ein Mail-Gateway. Wichtig ist die Trennung von „an interne M365-Postfächer zustellen“ und „ins Internet zustellen“; letztere Anforderung ist in vielen Umgebungen der Grund, warum ein lokaler Smarthost jahrelang überlebt.

• Aktive Relay-Nutzung auf Exchange ermitteln: Get-ReceiveConnector | Select Name,Server,Bindings,RemoteIPRanges,PermissionGroups,AuthMechanism
• Message Tracking für bekannte Quellen (Beispiel): Get-MessageTrackingLog -Start (Get-Date).AddDays(-7) -EventId "RECEIVE" -ResultSize Unlimited | Group-Object ClientIpAddress | Sort-Object Count -Descending
• Absenderdomänen und Routings prüfen: Get-AcceptedDomain | Format-Table Name,DomainName,DomainType,Default

Accepted Domains, E-Mail-Address-Policies und Routing-Fallen

Accepted Domains im On-Prem-Exchange wirken zunächst wie ein Relikt, werden aber in Koexistenzphasen oft als Routing-Entscheidung missbraucht. Besonders kritisch sind Konstellationen, in denen eine Domäne als InternalRelay geführt wird, weil On-Prem noch „Teilzustellungen“ übernimmt, etwa für Applikationspostfächer, Kontaktobjekte oder verwaiste Empfänger. Beim Rückbau muss nachgewiesen werden, dass keine produktive Zustellung mehr auf On-Prem angewiesen ist: alle Empfänger liegen in Exchange Online, alle relevanten Alias-/ProxyAddresses sind korrekt, und es existiert kein Split-Brain-Routing über alte Connectoren.

Zusätzlich verdienen Address Policies Aufmerksamkeit. Selbst wenn keine Postfächer mehr on-prem existieren, beeinflussen Policies und Empfängervorlagen noch, wie Proxy-Adressen bei synchronisierten Objekten gepflegt werden. Wird Exchange entfernt, ohne den zukünftigen Attribut-Pflegepfad zu klären, entstehen Inkonsistenzen: fehlende SMTP-Aliase, falsche Primäradresse oder uneinheitliche UPN-/Mail-Attribute.

• Accepted Domains und Typen auswerten: Get-AcceptedDomain | Sort-Object DomainType,DomainName | Format-Table Name,DomainName,DomainType
• E-Mail-Address-Policies prüfen: Get-EmailAddressPolicy | Format-List Name,EnabledEmailAddressTemplates,Priority,RecipientFilter
• Send-Connector-AddressSpaces auf Reste prüfen: Get-SendConnector | Select Name,AddressSpaces,Enabled,SmartHosts

Saubere Deinstallation: Voraussetzungen, Reihenfolge, Validierung

Die Deinstallation ist kein kosmetischer Schritt, sondern der technische Abschluss, der Konfiguration und Metadaten konsistent entfernt. Zwingende Voraussetzung ist ein stabiler Zielzustand für Mailflow (inklusive Relay) und Autodiscover/DNS. In DAG-/Mehrserver-Umgebungen braucht es eine definierte Reihenfolge: Datenbanken und Arbitration-/Audit-Systempostfächer müssen korrekt behandelt, Connectoren und Virtual Directories geprüft, Zertifikate aus der aktiven Nutzung entfernt und der Server aus Loadbalancern sowie Monitoring herausgenommen werden.

Für die Validierung genügt nicht, dass „keine Benutzer mehr auf dem Server sind“. Maßgeblich sind Protokollpfade und Dienste: keine eingehenden Verbindungen auf alte Receive-Connectoren, keine Abhängigkeit von Autodiscover-Endpunkten, keine Nutzung als Smarthost, keine verbleibenden Hybrid-Beziehungen. Erst danach ist die Deinstallation über die vorgesehenen Setup-Mechanismen fachlich vertretbar; ein manuelles Entfernen von Rollen oder das Löschen von Serverobjekten im AD erzeugt typischerweise langfristige Inkonsistenzen.

• Gesundheit und Warteschlangen vor dem Rückbau prüfen: Get-Queue
Test-ServiceHealth
• Restobjekte, die häufig übersehen werden: Get-Mailbox -Arbitration
Get-Mailbox -AuditLog
Get-Mailbox -Monitoring
• Deinstallation kontrolliert anstoßen (Beispielaufruf): Setup.exe /Mode:Uninstall

Warnhinweise: Exchange abschalten, obwohl das AD noch „Exchange-geführt“ ist

Ein häufiger Fehler besteht darin, den letzten Exchange-On-Prem zu entfernen, während Microsoft Entra Connect Sync/Cloud Sync weiterläuft und Empfängerobjekte weiterhin aus dem lokalen AD synchronisiert werden. In diesem Betriebsmodell gelten Exchange-relevante Attribute (z. B. ProxyAddresses, Mail, mailNickname) weiterhin als „source of authority“ im lokalen Verzeichnis. Ohne geeigneten Verwaltungsweg für diese Attribute entstehen schnell Drift und Support-Risiken: Änderungen werden in der Cloud vorgenommen, beim nächsten Sync wieder überschrieben oder führen zu inkonsistenten Objekten.

Technisch sauber ist daher eine der folgenden Entscheidungen, bevor der letzte Exchange-Server geht: Entweder bleibt eine unterstützte Management-Instanz (oder ein definierter Attributpflegeprozess) für das lokale AD erhalten, oder das Identitätsmodell wird so umgestellt, dass die relevanten Exchange-/Empfängerattribute nicht mehr aus On-Prem stammen. Welche Option zulässig ist, hängt von der konkreten Identitätsarchitektur, den eingesetzten Microsoft-365-Diensten und dem Support-Anspruch ab; ohne diese Klärung ist die Deinstallation ein unnötiges Risiko.

Active Directory, DNS und Zertifikate stilllegen oder bereinigen: Identitätsmodell, Records, Autodiscover und technische Abnahme

Active Directory nach der Migration: Identitätsmodell, Restabhängigkeiten und Exit-Kriterien

Nach einer Microsoft-365-Migration bleibt Active Directory häufig länger produktiv als geplant, weil das Identitätsmodell nicht allein durch „Mailboxen in der Cloud“ definiert wird. Maßgeblich ist, ob weiterhin hybride Identitäten existieren: Synchronisierte Benutzerobjekte, Gruppen und Kontakte sowie Anwendungen oder Geräte, die LDAP/Kerberos/NTLM gegen lokale Domain Controller nutzen. Selbst wenn die Synchronisation per Microsoft Entra Connect Sync (bzw. Entra Cloud Sync) deaktiviert werden soll, müssen die Auswirkungen auf Anmeldepfade, Berechtigungen und Applikationsbindungen sauber bewertet werden.

Ein klares Stilllegungskriterium für AD liegt nur dann vor, wenn keine Workloads mehr auf Domänenmitgliedschaft, Gruppenrichtlinien, lokale PKI, dateibasierte Berechtigungen (ACLs), Service-Accounts oder legacy Authentifizierung angewiesen sind. In der Praxis führen insbesondere MFPs/Scanner, Applikationsserver, alte SMTP-Relays, Fileserver sowie VPN-/WLAN-NAC-Lösungen zu versteckten Abhängigkeiten. Ein kontrollierter Rückbau beginnt daher mit einer Bestandsaufnahme der verbleibenden Domänenjoins, der GPO-Vererbung und der Authentifizierungsprotokolle im Netzwerk.

Bei beabsichtigter AD-Abschaltung gilt: Erst Identitäten und Endgeräte in ein cloudbasiertes Modell überführen (z. B. Entra ID Joined, Intune-Policies statt GPOs, Applikationsauthentifizierung modernisieren), dann Synchronisations- und Domänendienste beenden. Wird AD hingegen weiter betrieben (z. B. wegen Geräteverwaltung, Legacy-Apps, lokaler Fileservices), sollte die Bereinigung trotzdem erfolgen: alte OU-Strukturen, nicht mehr benötigte Service-Accounts, überholte GPOs, abgelaufene Zertifikatsvorlagen und DNS-Reste erhöhen nur das Risiko späterer Störungen.

• Synchronisationsstatus verifizieren: Get-ADSyncScheduler
Get-ADSyncConnector
• Domänenabhängige Clients/Server ermitteln: Get-ADComputer -Filter * -Properties OperatingSystem,LastLogonDate | Select Name,OperatingSystem,LastLogonDate
• Risikofaktoren in Security-Logs eingrenzen: Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624} -MaxEvents 2000
• GPO-Altlasten inventarisieren: Get-GPO -All | Select DisplayName,Id
Get-GPOReport -All -ReportType Html -Path C:\Temp\GPOReport.html
• Warnhinweis zu „AD abschalten“: Ein Abschalten der Domain Controller ohne vorherige Ablösung von LDAP/Kerberos/NTLM-Abhängigkeiten führt typischerweise zu flächigen Login-Fehlern, Dienstabbrüchen und nicht reproduzierbaren Timeouts in Applikationen (insbesondere bei hardcodierten DC-/LDAP-Targets).

DNS-Bereinigung: Autorität, Split-Brain, Autodiscover und „tote“ Records

DNS wirkt nach einer Migration als häufigster Störhebel, weil Clients und Gateways konsequent dem Namen folgen, nicht der „geplanten“ Zielarchitektur. Besonders kritisch sind Split-Brain-Konstellationen (interne Zone identisch zur externen) sowie historisch gewachsene Autodiscover-Setups. Ein lokaler DNS-Eintrag für autodiscover, der auf einen abgeschalteten On-Prem-Endpunkt zeigt, erzeugt Outlook-Anmelde-Prompts, lange Startzeiten oder wiederkehrende Authentifizierungsabfragen. Gleiches gilt für alte SRV-Records oder Proxy-Ausnahmen, die noch auf interne FQDNs zeigen.

Die Bereinigung sollte nicht allein auf „Records löschen“ hinauslaufen. Zunächst muss feststehen, welche Namespaces weiterhin benötigt werden: interne AD-DNS-Zonen (z. B. corp.local oder ad.firma.tld), öffentliche Mail-Domänen, Legacy-Hostnamen für Applikationen sowie Zertifikatsnamen. Danach wird jeder Record einem Owner und einem Zweck zugeordnet. Ein kurzer TTL vor der Umstellung reduziert das Risiko lang anhaltender Cache-Effekte, ersetzt aber keine technische Abnahme.

• Record-Inventory pro Zone: Get-DnsServerResourceRecord -ZoneName firma.tld -ComputerName dns01 | Select HostName,RecordType,TimeToLive,RecordData
• Autodiscover-Auflösung testen (Client-Sicht): Resolve-DnsName autodiscover.firma.tld -Type A
Resolve-DnsName autodiscover.firma.tld -Type CNAME
• TTL für Change-Fenster absenken (gezielt): Set-DnsServerResourceRecord -ZoneName firma.tld -OldInputObject $rec -NewInputObject $rec -TimeToLive 00:05:00
• Warnhinweis Split-Brain: Bei identischer interner/externer Zone muss geprüft werden, ob interne Clients public DNS nutzen dürfen. Eine halbherzige Umstellung erzeugt häufig „funktioniert nur im VPN“ oder „nur außerhalb“ als Fehlerbild.

Zertifikate und PKI: Namensräume, Ketten, Autoenrollment und verbliebene TLS-Abhängigkeiten

Zertifikate werden beim Rückbau oft unterschätzt, weil sie nicht nur Web-Endpunkte betreffen. Interne PKIs (AD CS) signieren häufig VPN, WLAN (EAP-TLS), RADIUS, Web-Proxys, LOB-Applikationen, LDAPS und Geräteauthentifizierung. Wird AD oder eine interne CA abgeschaltet, müssen die Vertrauenskette und die Verteilung von Root-/Intermediate-Zertifikaten neu geregelt werden. Andernfalls entstehen TLS-Fehler, die sich erst nach Ablauf eines Zertifikats oder beim Wechsel eines Endpunkts zeigen.

Im Kontext Autodiscover und Mailflow sind vor allem Zertifikatsnamen und SANs relevant: Historische Zertifikate enthalten häufig autodiscover.firma.tld, mail.firma.tld und interne Hostnamen. Sobald diese Endpunkte verschwinden, sollte das Zertifikatsportfolio bereinigt und die verbleibenden Services auf definierte, dokumentierte Namespaces konsolidiert werden. Zusätzlich ist zu klären, ob Autoenrollment via GPO noch aktiv ist. Bleibt es ohne Domain Controller bestehen, laufen Clients in ausbleibende Erneuerungen und beginnen später mit Trust-/Mutual-TLS-Problemen.

• Lokale Zertifikatsbestände prüfen (Server/Client): certutil -store -v My
certutil -store -v Root
• AD-CS-Status und Templates bewerten (falls vorhanden): certutil -config - -ping
• TLS-Endpunkte und Ketten testen (aus Sicht eines Clients): Test-NetConnection mail.firma.tld -Port 443
openssl s_client -connect mail.firma.tld:443 -servername mail.firma.tld
• Warnhinweis CA-Abschaltung: Eine interne Root-CA kann zwar offline bleiben, aber CRL/AIA-Verteilungspunkte müssen erreichbar bleiben, solange ausgestellte Zertifikate im Einsatz sind; sonst scheitern Revocation-Checks in sicherheitsbewussten Clients und Middleboxes.

Technische Abnahme: Nachweisführung, Monitoring und Rückfallkriterien

Die technische Abnahme der Stilllegung besteht aus reproduzierbaren Tests, die DNS-, Zertifikats- und Identitätspfad gemeinsam abdecken. Entscheidend ist die Messung aus unterschiedlichen Netzen (LAN, VPN, extern), weil Split-Brain-DNS, Proxy-PAC-Dateien oder Conditional Forwarders sonst unentdeckt bleiben. Für AD umfasst die Abnahme sowohl erfolgreiche Cloud-Anmeldungen als auch den Nachweis, dass keine produktiven Systeme mehr Domain Controller kontaktieren oder LDAP-Binds ausführen. Für DNS umfasst sie die autoritative Auflösung, Caching-Verhalten und das Entfernen nicht mehr benötigter Zonen/Delegationen. Für Zertifikate umfasst sie die Validierung der Kette, der Revocation-Erreichbarkeit und der SAN-Namen auf den verbliebenen Endpunkten.

Operational sollte eine Übergangszeit mit erhöhter Beobachtung eingeplant werden: DNS-Queries auf kritische Hostnamen, fehlgeschlagene TLS-Handshakes, wiederkehrende Autodiscover-Lookups sowie LDAP/Kerberos-Events liefern meist frühzeitig Hinweise auf vergessene Abhängigkeiten. Rückfallkriterien müssen konkret sein (z. B. definierte Fehlerrate, betroffene Anwendungsklasse, klarer Rollback-Schritt wie DNS-Revert oder temporärer Wiederanlauf eines DC/CA-Service). Ohne diese Kriterien wird jede Störung zur improvisierten Suchaktion, während Caches und Zertifikatsvalidierungen weiter im Hintergrund wirken.

• DNS-Undeclared Dependencies finden: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DNS-Client/Operational';Id=3018} -MaxEvents 200
• LDAP/AD-Zugriffe nachweisen (Beispiel DC Security Logs): Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625} -MaxEvents 500
• Autodiscover- und Outlook-Connectivity prüfen (Client): Test-OutlookWebServices -Identity user@firma.tld
Test-NetConnection autodiscover.firma.tld -Port 443
• Rückfallkriterium DNS: Wird nach einer Record-Umstellung ein kritischer Business-Service nicht erreichbar, muss der vorherige FQDN-Zustand inklusive TTL und Zonendaten versioniert vorliegen (z. B. Export per dnscmd /zoneexport firma.tld firma.tld.dns vor dem Change).