E2013 Troubleshooting

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-

  1. Fehlerbild beschreiben lassen und hinterfragen
  2. Objekt untersuchen und Ursache feststellen
  3. 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

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.

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.

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