Outlook + Exchange ist die beste Kommunikationslösung für Teams. Nur wo setzt man an, wenn die Verbindung zum Server spinnt?
Wir gewähren Einblick in unsere Checkliste. Mit dem richtigen Riecher kann man vieles überspringen, aber wenn man strukturiert nach dem Fehler suchen möchte, findet man mit dieser Liste den Ansatzpunkt.
Achtung: Die Liste richtet sich als Gedankenstütze an Exchange-Admins, die wissen, was sie tun. Jeder Schritt der Daten oder Konfigurationen verändert könnte zu einem Datenverlust führen. Backup ist Pflicht! Und hinter jedem Schritt stecken dutzende Seiten Dokumentation und Wissen von Jahren. Wenn Sie sich unsicher sind, fragen Sie jemanden, der sich damit auskennt. Wenn Sie niemanden haben, beauftragen Sie uns: https://www.kk-software.de/produkte/107/exchange-server
Outlook-Exchange-Probleme können primär an 4 Stellen die Ursache haben:
- Probleme im Betriebssystem an Client, Domänencontroller oder Exchange-Server
- Outlook-Probleme am Client
- Active-Directory-Probleme am Domänencontroller
- Exchange-Probleme am Exchange-Server
1. Probleme im Betriebssystem
Die folgenden 13 Betriebssystem-Checks sollen jeweils durchgeführt werden bei:
- Jedem betroffenem Client-PC
- Allen zugehörigen Domänencontrollern
- Jedem Exchange-Server
Checkliste Betriebssystem:
Das sind Grundchecks, die quasi bei jedem PC-Problem durchgeführt werden sollten.
- Windows neu gestartet?
Erst mal die Systeme in einen definierten Ausgangszustand zu versetzen hilft sehr oft: https://www.youtube.com/watch?v=PtXtIivRRKQ - Festplatte ausreichend frei?
Mindestgrößen: PCs mind. 15 GB, Server mind. 50 GB, vor Installations- und Datenoperationen entsprechend mehr - Festplatte ohne offensichtliche Fehler?
- chkdsk c: (für alle Laufwerke wiederholen)
- Smart-Status auslesen → CrystalDiskInfo Portable http://crystalmark.info/download/index-e.html
- PC/Server auf Malware überprüft?
- CCleaner https://www.piriform.com/ccleaner/download/standard
- Die ganzen temporäre Dateien entfernen, damit folgende Suchen schneller gehen
- Autostart überprüfen, komische Einträge entfernen
- Registry überprüfen und ggfs. bereinigen.
- AdwCleaner https://toolslib.net/downloads/finish/1/
- Malwarebytes https://de.malwarebytes.com/mwb-download/thankyou/
- Taskmanager auf Malwarehinweise durchforstet?
- Spalte Benutzername: Laufen Prozesse, die sich nach Systemprozessen anhören, unter dem Benutzeraccount?
- Imagepfadname: Laufen Prozesse aus falschen Ordnern, insbesondere aus User-Ordnern, Temp-Ordnern oder Browser-Ordnern?
- Befehlszeile: Laufen Prozesse, die andere Prozesse huckepack nehmen?
- CCleaner https://www.piriform.com/ccleaner/download/standard
- Werden die richtigen DNS-Server benutzt?
- Sind ausschließlich DNS-Server von Domänencontrollern eingetragen (also keine Router oder externe DNS wie 8.8.8.8 und 8.8.4.4)? Test mit ipconfig /all
- Funktioniert die DNS-Auflösung?
nslookup starten- Wird der richtige DNS-Server benutzt?
- Domänenname eingeben, muss alle Domänencontroller der Domäne auslösen
- Funktioniert der Ping auf den Exchange-Server, sowohl auf die interne und externe Adresse?
Wenn die externe Adresse nicht im internen Netz geroutet wird, sollte im internen DNS der Host auf die interne IP-Adrese umgebogen werden. - Nehmen die Datenpakete im tracert den richtigen Weg?
Bei komplexen Netzstrukturen sollte der Weg zum Exchange-Server mit Tracert überprüft werden. Ebenso die Antwortpakete. Nehmen sie vielleicht unterschiedliche Wege oder ist ein Content-Filter oder Firewall dazwischen? - Sind im Ereignisprotokoll Fehler?
Welche Fehler werden angezeigt? Achtung: Im Ereignisprotokoll sind fast immer Fehler. Nicht in unbedeutenden Fehlern verrennen! - Laufen alle Dienste, die auf “Automatisch” stehen?
Nicht, das einfach nur ein Dienst nicht gestartet ist. - Ist das Patchlevel aktuell?
Wurde vielleicht eine Seite aktualisiert und das Protokoll wurde weiterentwickelt und ist jetzt inkompatibel? Check ob das Patchlevel (“Windows-Updates”) halbwegs aktuell ist: Client: nicht älter als 2 Monate, Server: nicht älter als 6 Monate, insbesondere auch Office/Outlook-Updates (“Sie erhalten Updates: Für Windows und andere Produkte von Microsoft Update”). Mit aktiven Internetdiensten muss der Patchlevel immer aktuell sein, sonst ist die Gefahr ausnutzbaren Sicherheitslücken ausgesetzt zu sein sehr hoch. - Blockt ein Virenscanner oder Firewall eine notwendige Verbindung?
Firewalls können Software-Firewalls auf dem Client oder dem Server sein oder Hardwarefirewalls bzw. virtualisierte Firewalls im Netzwerk oder in der Netzwerkinfrastruktur. Auch NAC-Lösungen (Network-Access-Control) können Netzwerktraffic von ungepatchten PCs verhindern.
Ebenso sind öffentliche WLANs, Hotelnetzwerke und ganze Staaten (z.B. China) bekannt dafür, den Netzwerkverkehr einzuschränken. - Uhrzeit identisch zwischen Client, DC und Exchange-Server?
Ein ganz banales Problem, dass in einer ordentlich konfigurierten Domäne nicht vorkommen sollte, aber Uhrzeitunterschiede können die Sicherheitsaushandlungen (zu Recht) durcheinanderbringen und die Verbindung verhindern.
2. Outlook-spezifische Probleme am Client
Nachdem im Betriebssystem keine Fehler sind, wird sich Outlook am Client gewidmet:
- Wurden die o.g. Checks im Betriebssystem durchgeführt?
- Haben alle User das Problem oder hat nur dieser Client das Problem?
Haben alle Clients das Problem, wird es sich um ein generelles Problem am Server handeln. Hat nur dieser eine User das Problem, wird die Ursache am Client oder am User-Postfach liegen. - Wurde Outlook neu gestartet?
Falls der PC beim Betriebssystem-Check nicht neu gestartet wurde. Zumal einige Fehler nur beim Outlook-Start erscheinen. - Wie ist der Outlook-Verbindungsstatus?
STRG + Rechtsklick auf Outlook-Symbol und “Verbindungsstatus…” überprüfen- Sind die ganzen Verbindungen da?
- Kommen immer wieder neue Verbindungen?
- Gibt es Fehler auf die Anfragen
- Funktioniert die E-Mail-Autokonfiguration?
STRG + Rechtsklick auf Outlook-Symbol und “E-Mail-Autokonfiguration testen…”- Findet er die richtigen Daten (insbesondere wenn es mehrere Exchange-Server gibt oder unterschiedliche URLs intern und extern)
- Funktioniert OWA (Outlook Web App)?
Test, ob der Postfachzugriff über OWA (Outlook Web App, früher Outlook Web Access): https://server.domain.local/owa/- Zertifikat überprüfen (Dauer, Hostnamen), Zertifikatsfehler sind sehr kritisch, Zertifikat muss überall (Aussteller, Dauer, Hostnamen) “grün” sein.
- Test-E-Mail an echo@tu-berlin.de
- Headerzeilen der Mail (ausgehend und eingehend) überprüfen (Header im OWA anzeigen: Oben rechts die 3 Punkte … → Nachrichtendetails);
- Beteiligte Server
- Richtiges Routing
- Schleifen
- Meldungen in den Headern
- Nach Updates btw. Neuinstallationen: Sind die Client- und Server-Versionen kompatibel?
Z.B. ist Exchange 2016 nicht mit Outlook 2007 kompatibel.
3. Checks am Domänencontroller
Oft liegen Exchange-Probleme in der Windows Domäne begründet.
Alle im Client und im Exchange als DNS-Server eingetragenen DCs checken.
- Wurden die o.g. Checks im Betriebssystem durchgeführt?
- Zeigt dcdiag Fehler an?
cmd (als Administrator ausführen). Um diese Befehle so zu benutzen muss das Verzeichnis c:\temp existieren, ansonsten die Dateiausleitung (>c:\temp\dcdiag01.txt) weglassen.- dcdiag >c:\temp\dcdiag01.txt
- dcdiag /test:DNS >c:\temp\dcdiag02.txt
- ggfs. für alle Server in der Domäne
- dcdiag /v /c /d /e >c:\temp\dcdiag03.txt
- DCDiag /Test:DNS /e /v >c:\temp\dcdiag04.txt
- Zeigt repadmin Fehler an?
- Repadmin /replsummary >c:\temp\repadmin01.txt
- Repadmin /Queue >c:\temp\repadmin02.txt
- Repadmin /Showrepl >c:\temp\repadmin03.txt
4. Exchange Server
Achtung: Hier sind bereits Maßnahmen unter die Checkliste gemischt. Diese Maßnahmen können zu Datenverlust führen. Nur ausführen, wenn man sicher ist, was man tut. Backup ist Pflicht!
Der Syntax der Kommandos unterscheidetet sich manchmal geringfügig zwischen der Exchange-Versionen. Der Fokus liegt auf der meistverbreitesten Version Microsoft Exchange Server 2013. Unter Microsoft Exchange Server 2016 sollten sie auch alle funktionieren. Wer noch ältere Versionen wie Exchange 2007 oder Exchange 2010 einsetzt, muss evtl. den Syntax entsprechend anpassen.
- Wurden die o.g. Checks im Betriebssystem durchgeführt?
- Wie alt ist das CU (Exchange Cumulative Update)?
Wurde es überhaupt jemals installiert? Sollte immer aktuell sein, aber niemals älter als 6 Monate, insbesondere wenn OWA oder andere Ports öffentlich im Internet erreichbar sind: https://technet.microsoft.com/de-de/library/hh135098(v=exchg.150).aspx - Wie ist der Status vom ECP?
https://server.domain.local/ecp/- Server → Datenbanken: Folgendes überprüfen:
- Spalte “Status” → Datenbanken eingebunden
- Rechts “Inhaltsindexzustand”
- Server → Datenbanken: Folgendes überprüfen:
- Vor Reparaturarbeiten: Ist die Festplatte ausreichend frei (>200GB)?
Achtung bei Reparaturarbeiten:- oft enormes Logfilewachstum, insbesondere bei Verschiebe- und Restore-Aktionen)
- ggfs. Umlaufprotokollierung aktivieren → Achtung: Datenverlust bei bestimmsten Restore-Szenarien, nur bei aktutem Platzmangel aktivieren.
- Speicherplatz ohne Full-Backup manuell freigeben (Achtung: Datenverlustgefahr!): Informationsspeicher stoppen → eseutil /mh → Der State muss auf „Clean Shutdown“ stehen → Wenn ja, können die Log-Dateien gelöscht werden (bis auf den Unterordner mit der GUID und die EDB-Datei, alss besonders die E00.log, E00xxxxxxxx.log und E00.chk)
- Muss das Postfach repariert werden?
Exchange-Shell- Postfach reparieren (ab Exchange 2013):
- Ein Postfach: New-MailboxRepairRequest -Mailbox LOGINNAME -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview -Archive
- Alle Postfächer der Datenbank: New-MailboxRepairRequest Database DATABASENAME -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview -Archive
- Fortschritt checken: Get-MailboxRepairRequest -Mailbox LOGINNAME bzw. Get-MailboxRepairRequest -Database DATABASENAME
- Postfach durch Umzug reparieren:
Häufig lassen sich Postfächer nur durch um Umzug in eine neue Datenbank reparieren:- ggfs. neue Postfachdatenbank anlegen
- New-MoveRequest -Identity ‚Lisa‘ -TargetDatabase „DB01“ -BadItemLimit 10000 -AcceptLargeDataLoss
- Bei vielen Umzügen Performanceoptimierung: c:\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config
MaxActiveMovesPerSourceMDB=“15”
MaxActiveMovesPerTargetMDB=“15”
MaxActiveMovesPerSourceServer=“50”
MaxActiveMovesPerTargetServer=“40”
MaxTotalMovesPerMRS=“250”
https://technet.microsoft.com/de-de/library/ff963524(v=exchg.141).aspx
- Virenscanner bremsen gerade bei alten/langsamen Servern die Rettungsmaßnahmen enorm aus.
Wenn intensive Daten- bzw. Rettungsmaßnahmen anstehen und ein Virenbefall ausgeschlossen werden kann, kann es die Schritte enorm beschleunigen, wenn man den Virenschutz lockert:- Virenscanner vor Rettungsmaßnahmen deaktivieren oder deinstallieren
- Virenscanner vor Updates deaktivieren
- Virenscanner/Firewall muss quasi alle Zugriffe auf alle kritischen Dienste erlauben
- Postfach reparieren (ab Exchange 2013):
- Wie ist der Healthstatus vom Exchange Server?
- https://server.domain.local/owa/healthcheck.htm muss 200 OK liefern
- get-healthreport $env:computername | ? alertvalue -ne healthy
- Get-ServerHealth $env:computername | ? alertvalue -ne Healthy | ft name,healthsetname,servercomponentname,alertvalue -AutoSize
- Get-ServerComponentState $env:computername
- Test-ServiceHealth | ft role,req*,servicesnotrunning
- Get-MessageTrackingLog -Start (get-date).addminutes(-5) -EventId receive
- Befinden sich Postfächer in Quarantäne?
- Get-Mailbox | Get-MailboxStatistics | Where {$_.IsQuarantined –eq $True}
- HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox GUID}
- CrashCount: the number of times that this mailbox has crashed a thread within the Store
- LastCrashTime: the last time that a mailbox thread crashed within the Stor
- HKLM\SYSTEM\CCS\Services\MSexchangeIS\ParameterSystem\Servername\Private-dbguid\Quarantined Mailboxes
- MailboxQuarantineCrashThreshold: The number of thread crashes that can be experienced by a mailbox before the store considers it a candidate to be quarantined.
- MailboxQuarantineDurationInseconds: The number of seconds a mailbox remains in quarantine before it is released. The default is 21,600 seconds, or six hours.
- Gibt es vielleicht zu viele Zugriffe auf das Postfach?
Zugriffsbeschränkungen auf Postfächer mit vielen Endgeräten und vielen Stellvertretern aufheben. Evtl. greift eine Drosselung und Verhindert neue (auch eigene) Zugriffe aufs Postfach- New-ThrottlingPolicy PolicyNoLimits
- Set-ThrottlingPolicy PolicyNoLimits -RCAMaxConcurrency Unlimited -EWSMaxConcurrency Unlimited -EWSMaxSubscriptions Unlimited -CPAMaxConcurrency Unlimited -EwsCutoffBalance Unlimited -EwsMaxBurst Unlimited -EwsRechargeRate Unlimited
- Set-Mailbox „Mailboxname“ -ThrottlingPolicy PolicyNoLimits
- Zusätzlich Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession anlegen und neues DWORD mit Session auf 128 anlegen.
- Zusätzlich im Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem ein neues DWORD mit Maximum Allowed Sessions Per User auf 128 anlegen.
- Funktioniert der Zugriff auf die Exchange-Dienste von neutralen Endgeräten?
Allgmeine Funktionalität Exchange (Kompletttest)- Testen mit https://testconnectivity.microsoft.com/ mit „Exchange ActiveSync“ → Achtung, dann kennt Microsoft (plus Proxyserver mit einer Root-CA) Ihr Kennwort , also vor dem Test das Kennwort ändern, den Test durchführen und nach dem Test das Kennwort wieder ändern.
- Gibt es einen Konflikt beim Server-Namen?
- Konflikt *.local vs. *.de ggfs. auflösen (Zertifikat, Split-DNS, Erreichbarkeit, Routing)?
- Externe und interne Adressen im ECP überprüfen?
- Stehen alle Namen im Zertifikat, auch autodiscover.xxx etc.?
- Reverse DNS Eintrag vorhanden: Kann die IP-Adresse zum Hostnamen aufgelöst werden?
- Werden eingehende E-Mails abgelehnt oder verzögert?
Oft kann es helfen externe Limits beim E-Mail-Empfang hochdrehen, dann sollte die Firewall am Gateway aber nur Zugriffe vom vorgeschalteten Mailserver annehmen.- Get-ReceiveConnector | Set-ReceiveConnector -ConnectionInactivityTimeout 00:20:00 -ConnectionTimeout 23:59:59 -MaxLocalHopCount 12 -MaxInboundConnection 20000 -MaxInboundConnectionPercentagePerSource 100 -MaxInboundConnectionPerSource 10000 -MaxProtocolErrors 50 -MaxRecipientsPerMessage 200
Ende
Wenn Sie jeden Punkt durchgearbeitet haben, sollten Sie auf die Ursache für den Fehler gestoßen sein. Zumindestens sind in diese Liste viele Ursachen für Exchange-Fehler der letzten 10 Jahre bei unseren Kunden eingeflossen. Haben Sie weitere Tipps, freuen wir uns darüber.
Und wenn Sie sich unsicher sind, fragen Sie einen Experten! Wir helfen Ihnen gerne: https://www.kk-software.de/produkte/107/exchange-server