E2013 Troubleshooting
Beachten Sie dazu unbedingt auch die Seite Ex2013 Heathcheck
Mit Exchange 2013 wurden einige Dinge ergänzt, die bei der Fehlersuche und Beseitigung helfen können aber auch Hindernisse sein können. Diese Seite soll kurz die Vorgehensweise bei der Fehlersuche beschreiben.
Strukturierte Fehlersuche
"Reboot tut gut" ist aus meiner Sicht ein schlechter Ansatz ein Problem dauerhaft zu lösen. Interessanter ist es für Exchange 2013 im Rahmen des Ex2013 Heathcheck einen Fehler automatisiert zu beheben. Aber soweit müssen wir es ja nicht kommen lassen. Wenn aber ihr Server sporadisch einen Neustart hinlegt, dann kann das durchaus das Exchange 2013 Health Monitoring sein. Eine Fehlersuche und Korrektur bei Exchange unterscheidet sich nicht allzu viel von einer Autowerkstatt oder einem Arztbesuch-
- Fehlerbild beschreiben lassen und hinterfragen
- Objekt untersuchen und Ursache feststellen
- Lösungsmöglichkeiten bewerten und umsetzen
Hört sich aufwändiger an aber es ist tatsächlich oft das "nicht Zuhören" oder eine unvollständige untersuchung, die letztlich Zeit kostet und sogar den Schaden verschlimmert. Wenn wir nun davon ausgehen, das der Fehler "irgendwo" beim Server zu suchen ist, weil mehrere Personen das gleiche Problem haben und Korrekturen am Client keine Lösung geschaffen haben, dann muss man den Server "untersuchen"
Analyse Healthreports
Mein erster Ansatzpunkt beim Server sind die Informationen des Healthreports. Die Funktion "Managed Availibility" von Exchange 2013 prüft sowieso die Funktion vieler Komponenten und wenn Sie nicht schon von SCOM oder einer anderen Monitoring-Lösung auf Probleme aufmerksam gemacht wurden, dann ist dies ein einfacher Aufruf:
PS] C:\>get-healthreport $env:computername | ? alertvalue -ne healthy | fl heal* Server State HealthSet AlertValue LastTransitionTime MonitorCount ----- ----- --------- ---------- ------------------ ------------ MSX2013 NotApplicable MailboxTransport unhealthy 7/3/2013 9:08:38 PM 57 MSX2013 NotApplicable MSExchangeCertif... Disabled 1/1/0001 1:00:00 AM 2
Eine ausführlichere Information gibt es mit "Get-ServerHealth":
get-serverhealth $env:computername | ? alertvalue -ne Healthy | ft name,healthsetname,servercomponentname,ale value -AutoSize Name HealthSetName ServerComponentName AlertValue ---- ------------- ------------------- ---------- Transport.NDRForUnrestrictedLargeDL.Monitor HubTransport HubTransport Disabled TransportLogGenerationCheckpointDepthMonitor HubTransport HubTransport Disabled TransportCategorizerJobAvailabilityMonitor HubTransport HubTransport Disabled FederatedDecryptionAgentFailedToXDecryptMonitor HubTransport HubTransport Disabled TransportDeliveryFailures544Monitor HubTransport HubTransport Disabled TransportDeliveryFailuresDeliveryStoreDriver520Monitor HubTransport HubTransport Disabled TransportDeliveryFailuresDeliveryStoreDriver560Monitor MailboxTransport None Disabled IsMemberOfResolverResolvedGroupsCacheSizeMonitor HubTransport HubTransport Disabled IsMemberOfResolverExpandedGroupsCacheSizeMonitor HubTransport HubTransport Disabled Transport.DomainSecureCertAuth.Monitor HubTransport HubTransport Disabled Transport.DomainSecureCert.Monitor HubTransport HubTransport Disabled TlsDomainClientCertificateSubjectMismatchMonitor HubTransport HubTransport Disabled Transport.DomainSecureServerDomainCertFailed.Monitor HubTransport HubTransport Disabled Transport.DomainSecureServerCertFailed.Monitor HubTransport HubTransport Disabled TransportFedCertMonitor MSExchangeCertificateDeployment None Disabled TransportFedCertExpiredMonitor MSExchangeCertificateDeployment None Disabled MessageCountMonitor Transport HubTransport Disabled DeferredMessageCountMonitor Transport HubTransport Disabled AverageMessageCountMonitor Transport HubTransport Disabled TotalMessageCountMonitor Transport HubTransport Disabled MessageCountExceedsAverageByPercentMonitor Transport HubTransport Disabled MessageCountExceedsLowestByNumberMonitor Transport HubTransport Disabled AggregatedQueueMonitor Transport HubTransport Disabled
Wenn Sie hier einen Service finden, der "Unhealty" ist, dann können Sie die Probe manuell starten.
Invoke-MonitoringProbe `
-identity <health set name>\<probe name> `
-Server <server name> `
| Format-List
Die "richtige Healthset-Probe finden Sie wieder im Eventlog. Die Healthsets werden im Exchange 2013 Management Pack detailliert beschrieben
- Exchange 2013 Management
Pack Health Sets
http://technet.microsoft.com/en-us/library/dn195892(v=exchg.150).aspx
Analyse ServerComponents
Und dann gibt es ja noch die ServerComponents, über die ein Admin bestimmte Komponenten administrativ "Down" setzen können. Auch hier lohnt sich mal ein Blick, ob alle "Aktiv" sind
[PS] C:\>Get-ServerComponentState $env:computername Server Component State ------ --------- ----- MSX2013.netatwork.de ServerWideOffline Active MSX2013.netatwork.de HubTransport Active MSX2013.netatwork.de FrontendTransport Active MSX2013.netatwork.de Monitoring Active MSX2013.netatwork.de RecoveryActionsEnabled Active MSX2013.netatwork.de AutoDiscoverProxy Active MSX2013.netatwork.de ActiveSyncProxy Active MSX2013.netatwork.de EcpProxy Active MSX2013.netatwork.de EwsProxy Active MSX2013.netatwork.de ImapProxy Active MSX2013.netatwork.de OabProxy Active MSX2013.netatwork.de OwaProxy Active MSX2013.netatwork.de PopProxy Active MSX2013.netatwork.de PushNotificationsProxy Active MSX2013.netatwork.de RpsProxy Active MSX2013.netatwork.de RwsProxy Active MSX2013.netatwork.de RpcProxy Active MSX2013.netatwork.de UMCallRouter Active MSX2013.netatwork.de XropProxy Active MSX2013.netatwork.de HttpProxyAvailabilityGroup Active
Es kann durchaus sei, dass eine Installation eines Servicepack oder Rollup oder ein Admin hier eine Komponente administrativ "inactive " gestellt hat und am Ende das ein oder andere Vergessen hat. Das gilt insbesondere, wenn die Installation nicht komplett durchgelaufen ist. Zurückstellen geht per PowerShell:
set-ServerComponentState ` -Identity $env:computername ` -Component umcallrouter ` -State active ` -Requester Maintenance
Mögliche Werte für "Requester" sind "HealthApi, Maintenance, Sidelined, Functional, Deployment". Und hier lauert eine Falle!
Ich habe am eigenen Server erlebt, dass eine Komponente auf "Maintenance" gestellt war aber meine Versuche es per PowerShell zu lösen haben erst nicht funktionieren. Also musste ich hinter die Kulissen schauen.
Die Einstellungen landen u.a. in der Registrierung und hier wird jeder Requester getrennt gespeichert. Dank Regmon war der Pfad schnell gefunden:
HKLM\Software\Microsoft\ExchangeServer\v15\ServerComponentStates\
Und hier kann es durchaus mehrere Einträge geben. Es ist nämlich möglich, dass eine Komponente durch verschiedene Prozesse gleichzeitig auf "Maintenance" gestellt wurde. Die Komponente geht aber erst dann wieder in den aktiven Zustand, wenn alle Sperren entfernt sind.
Ich habe keine Details zum Format und es könnte sein, dass die Ziffer zwischen den beiden Doppelpunkten den Status angibt, d.h. 1=aktiv und 0=inaktiv und dahinter eine Art "Zeitstempel" ist.
Achtung:
Wenn auch nur ein Eintrag auf "0" steht, ist
diese Komponente Inaktiv. Es müssen also alle
Komponenten auf 1 stehen.
Einen anderen Weg um zu sehen, wer die Komponente auf "Inactive" gesetzt hat, konnte ich bislang nicht ermitteln.
ich würde dennoch nicht in der Registrierung etwas ändern, sondern besser diese Infos nutzen, um die passende Aktivierung auszulösen.
Folgender Einzeiler kann da helfen alles wieder auf "aktiv" zu setzen:
Get-ServerComponentState -Identity $env:Computername `
| where {$_.state -ne "active"} `
| foreach{ `
Set-ServerComponentState `
-identity $_.serverfqdn `
-component $_.component `
-State active `
-Requester healthapi
Set-ServerComponentState `
-identity $_.serverfqdn `
-component $_.component `
-State active `
-Requester Maintenance
Set-ServerComponentState `
-identity $_.serverfqdn `
-component $_.component `
-State active `
-Requester Sidelined
Set-ServerComponentState `
-identity $_.serverfqdn `
-component $_.component `
-State active `
-Requester Functional
Set-ServerComponentState `
-identity $_.serverfqdn `
-component $_.component `
-State active `
-Requester Deployment`
}
Anscheinend hat Microsoft hier fünf Klassifizierungen vorgesehen, die einen Service auf "Inactive" setzen können.
Mit Ausnahme des Requestor "Healthapi" können sie die anderen gerne in Absprache mit den Serververantwortlichen wieder zurück setzen. Die HealthAPI können Sie auch aktiv setzen, aber die Ursache, warum Exchange die Komponente auf inactive gesetzt hat, sollten Sie dennoch ermitteln.
- Set-ServerComponentState
http://technet.microsoft.com/en-us/library/jj218699(v=exchg.150).aspx
Test-Commandlets
Natürlich gibt es auch bei Exchange 2013 weiterhin die verschiedenen Commandlets zum "TEST" von einzelnen Funktionen. Einen schnellen Überblick, ob alle Dienste gestartet sind, bekommt man z.B.: mit "Test-ServiceHealth"
[PS] C:\>Test-ServiceHealth | ft role,req*,servicesnotrunning
Role RequiredServicesRunning ServicesNotRunning
---- ----------------------- ------------------
Mailbox Server Role True {}
Client Access Server Role True {}
Unified Messaging Server Role True {}
Hub Transport Server Role True {}
Solange hier alles auf "RequiredServicesRunning" steht, ist dieser Punkt abgehakt.
- Using Test-ServiceHealth für Exchange Server Health Checks
http://exchangeserverpro.com/exchange-2010-test-servicehealth/
Analyse Eventlog
Natürlich ist auch ein Blick in das Eventlog eines Server einer meiner ersten Aktionen, um Probleme genauer einzukreisen. Auch hier hat sich mit jeder Version von Windows und Exchange etwas getan. Beachten Sie dazu auch die weitergehenden Informationen auf Ex2013 Heathcheck.
Logfiles
Mit jeder Exchange Version wurden auch die Protokolldateien umfangreicher. Gerade Exchange 2013 zeichnet schon fast unverschämt viele Performance Counter und Client Zugriffe auf "Vorrat" mit. Das hat aber auch den Vorteil dass nach einem Problem ein Administrator nicht erst die Counter aktivieren und auf den nächsten Ausfall warten muss, sondern ein Consultant oder Supporter sehr schnell anhand der Protokolle der letzten Tage den Sachverhalt genauer untersuchen kann.
Sie können aber gerne mal selbst in ihr Verzeichnis "Logging" von Exchange 2013 schauen.
C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Eas
Dimensionieren Sie daher die Partition für die Installation nicht zu knapp. Exchange 2010 hat ja schon damit angefangen (Siehe CAS-Logging) aber Exchange 2013 legt hier noch mal nach.
Exchange "drüber installieren"
Über die GUI kann man Exchange installieren, deinstallieren aber nicht "reparieren". Dazu bedarf es dann einer Kommandozeile.
Achten Sie darauf, dass Sie das Setup nicht aus C:\Program Files\Microsoft\Exchange Server\V15\Setup\ starten. Diese Installation kann ja selbst auch defekt sein.
REM Exchange Setup von den Installationquelle starten. c:\install\ex2013\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms
Weitere Links
- Ex2013 Heathcheck
- CAS-Logging
- Using Test-ServiceHealth für Exchange Server Health Checks
http://exchangeserverpro.com/exchange-2010-test-servicehealth/
