Archiv für Juni 2012

Exchange 2010 DAG: Datenbankkopie mit Status „Failed and Suspended“ aktivieren

Ich teste gerade eine Exchange 2010 Database Availability Group mit zwei Servern. Ein Server hostet dabei die aktiven Datenbanken, der zweite Server dient ausschließlich als Backup und hostet nur passive Datenbankkopien.

Um einen automatischen Failover der Datenbanken zu verhindern, habe ich auf dem zweiten Server die DatabaseCopyAutoActivationPolicy auf Blocked gesetzt:

[PS] C:\Windows\system32>Set-MailboxServer 2010-mig-ex02 -DatabaseCopyAutoActivationPolicy Blocked

Name            DatabaseAvailab MAPIEncryptionRequired        AutoDatabaseMountDial        DatabaseCopyAutoActivationPo
                ilityGroup                                                                 licy
----            --------------- ----------------------        ---------------------        ----------------------------
2010-MIG-EX02   DAG001          False                         GoodAvailability             Blocked

In diesem Fall müssen die Datenbankkopien bei einer Downtime des primären Servers manuell aktiviert werden. Dabei gilt zu beachten, dass es sich bei diesem Vorgang um einen Switchover handelt und der Parameter MountDialOverride entscheidenen Einfluss auf den Erfolg der Aktion hat.

Wie auf folgendem Screenshot zu sehen ist, befindet sich die Kopie der Datenbank DB001 auf dem Server 2010-MIG-EX02 im Status „Healthy“ und die Queues sind leer, sprich die Kopie ist up to date:

Eine Überprüfung mit dem Cmdlet Get-MailboxDatabaseCopyStatus sieht ebenfalls gut aus:

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus

Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime                       ContentIndex
                                                              Length    Length                                                 State
----                                          ------          --------- ----------- --------------------                       ------------
DB001\2010-MIG-EX02                           Healthy         0         0           15.06.2012 15:11:38                        Healthy

Und auch ein Test mittels Test-ReplicationHealth auf beiden Servern fördert keine Auffälligkeiten zu Tage:

[PS] C:\Windows\system32>Test-ReplicationHealth

Server          Check                      Result     Error
------          -----                      ------     -----
2010-MIG-EX02   ClusterService             Passed
2010-MIG-EX02   ReplayService              Passed
2010-MIG-EX02   ActiveManager              Passed
2010-MIG-EX02   TasksRpcListener           Passed
2010-MIG-EX02   TcpListener                Passed
2010-MIG-EX02   DagMembersUp               Passed
2010-MIG-EX02   ClusterNetwork             Passed
2010-MIG-EX02   QuorumGroup                Passed
2010-MIG-EX02   FileShareQuorum            Passed
2010-MIG-EX02   DBCopySuspended            Passed
2010-MIG-EX02   DBCopyFailed               Passed
2010-MIG-EX02   DBInitializing             Passed
2010-MIG-EX02   DBDisconnected             Passed
2010-MIG-EX02   DBLogCopyKeepingUp         Passed
2010-MIG-EX02   DBLogReplayKeepingUp       Passed

In einem Test simuliere ich auf dem Server 2010-MIG-EX01 den Ausfall des Storagesystems, auf dem sich die aktive Datenbank befindet. Dazu schalte ich die entsprechende Disk im Windows Disk Manager einfach auf „Offline“, so dass das entsprechende Laufwerk mit den Datenbankdateien von DB001 nicht mehr verfügbar ist.

Kurze Zeit später wechselt der Status der aktiven Datenbank auf „Dismounted“, die Kopie dagegen bleibt wie erwartet weiterhin „Healthy“:

Die Datenbankkopie kann danach problemlos aktiviert werden, indem man sie mit der rechten Maustaste anklickt, „Activate Database Copy“ wählt und eine der drei Optionen GoodAvailability, BestAvailability oder BestEffort für den Parameter MountDialOverride verwendet.

Bei der Auswahl von „GoodAvailability“ wird die Datenbank aktiviert, wenn die Copy Queue weniger oder gleich 6 ist, also sechs oder weniger Transaktionslogs fehlen. Wählt man „BestAvailability“, können 12 oder weniger Transaktionslogs fehlen. BestEffort hingegen aktiviert die Datenbank unabhängig von der Anzahl fehlender Logdateien.

Problematisch hingegen wird es, wenn die Option „Lossless“ gewählt wird. Dazu heißt es im Technet:

    If you specify this value, the database doesn’t automatically mount until all logs that were generated on the active copy have been copied to the passive copy.

Am Anfang dachte ich, dass die Option durchaus gewählt werden kann, solange die Copy Queue Length auf 0 steht. Tatsächlich erhielt ich beim Versuch, die Datenbank mit der Option „Lossless“ zu aktivieren, aber folgende Fehlermeldung:

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
Cannot activate database copy 'Activate Database Copy...'.

Activate Database Copy...
Failed
Error:
An Active Manager operation failed. Error The database action failed.
Error: The database was not mounted because it has experienced data
loss as a result of a switchover or failover, and the attempt to copy
the last logs from the source server failed. Please check the event
log for more detailed information. Specific error message: Attempt to
copy remaining log files failed for database DB001\2010-MIG-EX02
Error: The log copier was unable to continue processing for database
'DB001\2010-MIG-EX02' because the source server '2010-MIG-EX01.layer9.local'
returned an error: Invalid file path (-1023) [HResult: 0x80131501]. The
copier will automatically retry after a short delay.

. [Database: DB001, Server: 2010-mig-ex02.layer9.local]

An Active Manager operation failed. Error The database was not mounted
because it has experienced data loss as a result of a switchover or
failover, and the attempt to copy the last logs from the source server
failed. Please check the event log for more detailed information.
Specific error message: Attempt to copy remaining log files failed for
database DB001\2010-MIG-EX02. Error: The log copier was unable to continue
processing for database 'DB001\2010-MIG-EX02' because the source server
'2010-MIG-EX01.layer9.local' returned an error: Invalid file path (-1023)
[HResult: 0x80131501]. The copier will automatically retry after a short
delay.

. [Server: 2010-MIG-EX02.layer9.local]

Unmittelbar danach schlitterte die Datenbank in den wenig erfreulichen Status „Failed and Suspended“:

Äußerst negativ daran ist, dass sich eine Datenbank in diesem Status über die GUI nicht mehr aktivieren lässt. Das ist natürlich sehr schlecht, wenn der primäre Server gerade ausgefallen ist und die Kopie der Datenbank dringend benötigt wird.

Zum Glück gibt es aber für das Cmdlet Move-ActiveMailboxDatabase weitere Optionen, die über die GUI nicht verfügbar sind. Interessant für das aktuelle Problem ist der Parametet SkipHealthChecks:

    The SkipHealthChecks parameter specifies whether to bypass passive copy health checks. With the SkipHealthChecks parameter, you can move the active copy to a database copy that’s in the Failed state. This parameter should be used only if the initial attempt to move the active database has failed. This is because SkipHealthChecks performs additional validation to ensure that the log files are consistent, which can take a considerable amount of time.

Das klingt schon mal gut. Also ab in die PowerShell und folgenden Befehl abfeuern:

[PS] C:\Windows\system32>Move-ActiveMailboxDatabase -Identity "DB001" -ActivateOnServer "2010-mig-ex02" -MountDialOverride "BestAvailability" -SkipHealthChecks

Confirm
Are you sure you want to perform this action?
Moving mailbox database "DB001" from server "2010-MIG-EX01.layer9.local" to server "2010-MIG-EX02.layer9.local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

…was aber leider aufgrund fehlerhafter Content Index Catalog Files ebenfalls fehlschlägt; obwohl der Content Index State bei der letzten Überprüfung (siehe oben) noch Healthy war:

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
DB001           2010-mig-ex01   2010-mig-ex01   Failed                                      Dismounted  Dismounted
An Active Manager operation failed. Error The database action failed. Error: An error occurred while trying to validate the specified datab
ase copy for possible activation. Error: Database copy 'DB001' on server '2010-MIG-EX02.layer9.local' has content index catalog files in the f
ollowing state: 'Failed'.. [Database: DB001, Server: 2010-mig-ex02.layer9.local]
    + CategoryInfo          : InvalidOperation: (DB001:ADObjectId) [Move-ActiveMailboxDatabase], AmDbActionWrapperException
    + FullyQualifiedErrorId : 53570C59,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveActiveMailboxDatabase

Zum Glück gibt es aber mit SkipClientExperienceChecks einen Parameter, mit dem sich auch die Überprüfung des Content Index deaktivieren lässt:

    The SkipClientExperienceChecks parameter specifies whether to skip the search catalog (content index) state check to see if the search catalog is healthy and up to date. If the search catalog for the database copy you’re activating is in an unhealthy or unusable state and you use this parameter to skip the search catalog health check and activate the database copy, you will need to either re-crawl or reseed the search catalog.

Also noch mal zurück in die PowerShell und den entsprechenden erweiterten Befehl anwenden:

[PS] C:\Windows\system32>Move-ActiveMailboxDatabase -Identity "DB001" -ActivateOnServer "2010-mig-ex02" -MountDialOverride "BestAvailability
" -SkipClientExperienceChecks -SkipHealthChecks

Confirm
Are you sure you want to perform this action?
Moving mailbox database "DB001" from server "2010-MIG-EX01.layer9.local" to server "2010-MIG-EX02.layer9.local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
DB001           2010-mig-ex01   2010-mig-ex02   Succeeded  1                  15.06.2012... Dismounted  Mounted

Damit klappt es dann endlich: Die Datenbank ist aktiviert und wieder online. In der Exchange Management Console wird die Änderung entsprechend sichtbar:

Der Status des Content Index ist interessanterweise auch wieder Healthy:

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus

Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime                       ContentIndex
                                                              Length    Length                                                 State
----                                          ------          --------- ----------- --------------------                       ------------
DB001\2010-MIG-EX02                           Healthy         0         0           15.06.2012 15:11:38                        Healthy

Nachdem das Storage des primären Servers wieder verfügbar ist, kann mittels Rechtsklick auf die dortige Datenbank und einem „Resume Database Copy“ die Datenbank wieder aktualisiert werden. Anschließend kann Sie über die GUI auch wieder aktiv geschaltet werden. Dabei kann auch problemlos Lossless verwendet werden – schließlich steht die Quelle in diesem Fall zur Verfügung und alle Logs können entsprechend kopiert werden.

Man lerne daraus: Bei einem manuellen Switchover sollte keinesfalls die Option „Lossless“ gewählt werden, wenn die Quelle nicht erreichbar ist.

Warum der Fehler bei einem automatischen Failover nicht auftritt, ist auch klar: Der Standardwert des Parameters AutoDatabaseMountDial steht auf GoodAvailability – d.h. solange die Copy Queue nicht größer als 6 ist, funktioniert alles problemlos. Würde der Standardwert dagegen auf Lossless stehen, käme es zum beschriebenen Problem.

Evtl. ist es sogar eine gute Idee, die AutoDatabaseMountDial auf einen etwas toleranteren Wert zu setzen, z.B. BestAvailability. In diesem Fall dürfen 12 Logdateien fehlen, was aber wiederum auch nur 12MB sind und in der Regel verkraftbar sein dürfte.

Exchange 2010 und Veröffentlichung von Outlook Anywhere über TMG: Abwesenheitsassistent funktioniert nicht

Aktuell bin ich mit diversen Vorbereitungen zur Migration von Exchange 2003 auf 2010 beschäftigt und teste in diesem Zusammehang viele Funktionen, unter anderem auch Outlook Anywhere.

Nach der Aktivierung von Outlook Anywhere auf dem entsprechenden CAS kann die Funktion im Thread Management Gateway über einen entsprechenden Assistenten sicher veröffentlicht werden:

Nachdem es mit dem Assistenten für ActiveSync und Outlook Web Access keinerlei Probleme gab und alles auf Anhieb funktionierte, war die Veröffentlichung von Outlook Anywhere über den Assistenten von weniger Erfolg gekrönt.

Zwar funktionierte die Verbindung grundsätzlich, allerdings ließen sich von einem entsprechend verbundenen Client aus weder das Offline Adressbuch herunterladen, die Frei-/Gebucht-Zeiten anzeigen oder der Abwesenheitsassistent öffnen. Beim Anklicken der Option „Automatische Antworten“ erschien jedes Mal folgende Fehlermeldung:

Zunächst muss man wissen, dass die Frei-/Gebucht-Zeiten und der Abwesenheitsassistent von den Exchange Web Services abhängig sind, die auf Client Access Servern im virtuellen IIS Verzeichnis /EWS/ abgebildet sind. Ähnliches gilt für das Offline Adressbuch, das über den Pfad /OAB/ bereitgestellt wird.

Auf Client Access Servern werden die Verzeichnisse auch als WebServicesVirtualDirectory bzw. OabVirtualDirectory bezeichnet. Sind diese Verzeichnisse nicht verfügbar, funktionieren o.g. Dienste nicht, da die Daten schlicht nicht abgerufen werden können.

Beim Blick in die entsprechende Veröffentlichungsregel auf dem TMG fiel auf, dass der Assistent die entsprechenden Pfade überhaupt nicht mit veröffentlicht hatte:

Tatsächlich werden die Pfade nur dann mit freigegeben, wenn bei der Erstellung der Regel zusätzlich die Option „Publish additional folders on the Exchange Server for Outlook 2007 clients“ mit aktiviert wird. Das ist, wenn man bereits Outlook 2010 einsetzt, etwas irreführend, da man die Option auch so interpretieren kann, als wäre sie nur für Outook 2007 relevant.

Wird die Option mit aktiviert, werden auch die restlichen notwendigen Pfade mit veröffentlicht:

Darüberhinaus gibt es noch einen weiteren wichtigen Punkt zu beachten, der für eine vollständig funktionierende Verbindung ebenfalls notwendig ist [1]:

    Mit dem Einsatz von Outlook 2007 wird die Funktion „Autodiscover“ auch für die Verbindung per Internet mit RPC over HTTP wichtig, da Outlook den Exchange 2007 Server „erkennt“ und dann immer per Autodiscover arbeitet. Entsprechend muss man Autodiscover, aber auch EWS und OAB aus dem Internet per SSL und Anmeldung erreichbar machen.

Dabei ist wichtig zu wissen, dass sich Outlook bei der Suche nach der Autodiscover URL nicht nach der Domäne des in Outlook konfigurierten RPC over HTTP Proxys bzw. TMG richtet, sondern nach der primären E-Mail-Adresse des in Outlook aktiven E-Mail-Kontos.

Lautet die E-Mail-Adresse im Outlook Profil z.B. layer9@wordpress.com, wird während der Suche nach der URL folgende Reihenfolge abgearbeitet:

Existiert eine der beiden URLs, baut Outlook eine HTTPS-Verbindung auf. Hier kann es ein Problem geben, wenn sich die Autodiscover URL von der URL des RPC over HTTP Proxys bzw. TMG unterscheidet.

Ist Outlook Anywhere beispielsweise über den Namen tmg.layer9.com veröffentlicht, lautet so auch der Name des an den SSL Listener gebundenen SSL Zertifikats. Baut Outlook nun aber eine HTTPS Verbindung zu einer der o.g. URLs mit dem Namen wordpress.com auf, gibt es ein Mismatch beim Namen des Zertifikats und damit eine SSL Sicherheitswarnung für den Anwender.

Zum Glück hat Microsoft hier schon zu Zeiten von Outlook 2007 nachgebessert und eine dritte Möglichkeit zur URL-Suche implementiert. Alternativ zur o.g. Methode können im DNS SRV-Records erstellt werden, die Outlook zur Adresse des RPC over HTTP Proxys bzw. TMG und damit zum veröffentlichten Autodiscover Directory weiterleiten. Das läuft wie folgt ab:

Bringt die Suche nach o.g. URLs kein Ergebnis, sucht Outlook in der Zone der SMTP Domäne des konfigurierten E-Mail-Kontos nach folgendem SRV Eintrag:

    _autodiscover._tcp.wordpress.com.

Der Eintrag sollte wie in Artikel KB940881 beschrieben folgendermaßen aussehen:

    Service: _autodiscover
    Protocol: _tcp
    Port Number: 443
    Host: Hostname, für den das Zertifikat gültig und wo Autodiscover veröffentlicht ist.

Lautet der Hostname wie in diesem Beispiel tmg.layer9.com, für den auch das Zertifikat gültig ist, wird die Verbindung zum Autodiscover Directory ohne Sicherheitswarnung aufgebaut. Es erscheint lediglich ein vom Anwender zu bestätigender Hinweis, dass eine Umleitung stattfindet.

Neben der Einrichtung von Autodiscover gibt es noch zwei weitere Punkte zu beachten. Punkt 1 ist, dass für das virtuelle Verzeichnis /EWS/ auf dem CAS die Standardauthentifzierung aktiviert werden muss. Das ist deshalb erforderlich, weil die Fallback-Authentifizierung der formularbasierten Authentifizierung auf dem TMG immer die Standardauthentifzierung ist. Die Authentifizierung kann im IIS Manager auf dem CAS angepasst werden:

Punkt 2 ist das Setzen der externen URLs für die entsprechenden Webdienste auf dem CAS. Die URLs für Outlook Web Access, ActiveSync und das Exchange Control Panel können alle in der GUI angepasst werden, für die Verzeichnisse /OAB/ und /EWS/ muss die Powershell verwendet werden. Die externen URLs müssen dabei dem Namen entsprechen, über den die Dienste extern erreichbar sind. Mit folgendem Befehl können die URLs angezeigt werden:

[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory | fl

InternalUrl                     : https://ex01.layer9.local/EWS/Exchange.asmx
ExternalUrl                     : https://tmg.layer9.de/EWS/Exchange.asmx

[PS] C:\Windows\system32>Get-OabVirtualDirectory | fl

InternalUrl                     : http://ex01.layer9.local/OAB
ExternalUrl                     : https://tmg.layer9.de/OAB

Angepasst wird die ExternalURL mit folgendem Befehl:

[PS] C:\Windows\system32>Set-OABVirtualDirectory EX01\* -ExternalURL https://tmg.layer9.de/OAB
[PS] C:\Windows\system32>Set-WebServicesVirtualDirectory EX01\* -ExternalURL https://tmg.layer9.de/EWS/Exchange.asmx

Mit diesen Einstellungen sollte der Zugriff auf Outlook Anywhere vollständig funktionieren. Hilfreich in diesem Zusammenhang ist außerdem das Whitepaper Publishing Exchange Server 2010 with Forefront Unified Access Gateway 2010 and Forefront Threat Management Gateway 2010 aus diesem Eintrag vom Exchange Team Blog.

Ebenfalls hilfreich zum Testen ist der Microsoft Remote Connectivity Analyzer.

[1] Exchange AutoDiscover in der MSXFAQ: http://www.msxfaq.de/e2007/autodiscover.htm