MoveRequest und MigrationBatch

Der Umzug von Mailboxen zwischen Servern, Datenbanken und mittlerweile auch zwischen Organisationen und in die Cloud hat sich von Exchange Version zu Exchange Version weiterentwickelt. Hat früher der Admin mit seinem Client die Daten von der Quelle ins Ziel übertragen, macht die mittlerweile der Exchange Server auf Anweisung des Administrators. Seit Exchange 2013 wurde mit „New-MigrationBatch“ ein zusätzliches Commandlet addiert.

Migration mit MRS

Seit Exchange 2010 werden Postfächer zwischen Exchange Server durch den „Mailbox Replication Service“ (MRS) verlagert. Dieser Prozess ist auf jedem CAS-Server vorhanden. Alle CAS-Server  überwachen eine „Job-Warteschlange“ mit Migrationsaufträgen, die die dann Abarbeiten. Über Locking wird sichergestellt, dass immer nur ein Prozess eine Mailbox verarbeitet. Der Prozess achtet dabei auch auf die Auslastung der Quelle und des Ziels, um keinen Server zu überlasten. Aber auch der Ausfall eines MRS wird dahingehend abgefangen, dass die anderen Instanzen einen abgebrochenen Job fortsetzen können. Alle MRS-Instanzen in der gleichen AD-Site arbeiten dahingehend zusammen.

Wenn in dem Zusammenhang von einem „Online Mailbox Move“ gesprochen wird, hat das aber nichts mit Office 365 zu tun, sondern bedeutet vielmehr, dass der Anwender auch während der Migration seines Postfachs weiter arbeiten kann. Der MRS repliziert die Mails von der Quelle in das Ziel und nur am Ende beim „Umschalten“ wird der Anwender kurz ausgesperrt um die letzten Änderungen zu replizieren und dann den Verweis auf die Mailbox umzusetzen.

Die globale Konfiguration einer MRS-Instanz liegt in der XML-Datei „MSExchangeMailboxReplicationService.exe.config“ bzw „MsExchangeMailboxReplication.exe.config“, die sich im Verzeichnis „$($env:ExchangeInstallPath)bin“  befindet. Die Aktionen des MRS werden natürlich in Protokolldateien abgelegt. Per Default ist dies „C:\Program Files\Microsoft\Exchange Server\V15\Logging\MailboxReplicationService\”. Die Logs werden nach 30 Tagen alleine gelöscht und haben das Namensschema MRSyyyymmddhh-n.LOG, d.h. für jede Stunden gibt es mindestens eine Protokolldatei. Die eigentlichen Aufträge und damit verbundenen Reports hingegen liegen in der System-Mailbox. Sie finden die Jobs als nicht in der Registrierung oder in einem AD-Container oder am Benutzerobjekt.

Migration mit MRS Proxy und Exchange Online

Die Migration ohne Mithilfe des Administrator-PCs ist wichtig für die Verlagerung von Daten in die Cloud. Wenn Sie ein Postfach zu Office 365 verschieben, dann senden Sie die Daten nicht in die Cloud, sondern Sie erstellen einen Migrationsauftrag in Office 365 und die MRS-Dienste in der Cloud holen Sich die Daten von ihrer On-Prem-Umgebung über HTTPS. Da Sie natürlich nicht alle On-Prem-Server direkt per HTTPS von Office 365 erreichbar machen wollen, muss dazu der MRS Dienst in der Cloud über einen „Helfer“ auf einem Hybrid-Server in ihrer lokalen Umgebung den Zugriff erhalten. In der Regel ist daher ein Server öffentlich erreichbar, der als MRSProxy arbeitet. Der MRSProxy ist per Default nicht eingeschaltet. Der Hybrid Configuration Wizard übernimmt dies aber für Sie.

Hinzu kommt die Konfiguration eines „Migrationsendpunkts“ im Ziel, damit der dortige MRS weiß wie er an die Quelle kommt.

Was ist ein Migration Batch?

Die Verwaltung von größeren Umzügen, bei der jede Mailbox einer einzelnen Mailbox entspricht, kann speziell in einer GUI unübersichtlich werden. Mit Exchange 2013 wurde das Commandlet „New-MigrationBatch“ addiert, welches die Anlage und Verwaltung von Verschiebeanforderungen mehrerer Postfächer vereinfacht. Der größte Vorteil ist dabei aber, dass Exchange am Ende des MigrationBatch einen Statusbericht versenden kann. So können Sie quasi eine Migration anstoßen und müssen diese nicht permanent überwachen. Zudem können Sie einen MigrationBatch auch per WebBrowser im Exchange 2013/2016 ECP sehen und verwalten, während ein einer Move-Request nicht mehr sichtbar ist.

Sie können mit "Remove-MigrationUser" so einen Migrations-Request eines Users aus dem entsprechende Migrationbatch entfernen. Der eigentliche "Move-Request" bleibt aber bestehen und wird auch weiter ausgeführt.

MoveRequest erstellen

Neben der Verwaltung per ECP oder Exchange 2010 MMC ist natürlich die Steuerung per PowerShell aus meiner Sicht der bequemste Weg. Mit ganz wenige Code lassen sich Verschiebeaufträge erstellen, überwachen, und steuern. Dreh und Angelpunkt zum, Anlegen von Verschiebaufträgen ist das Commandlet „New-MoveRequest“. Ein Move bezieht sich erst einmal auf genau eine Mailbox und über verschiedene Optionen kann die Zieldatenbank, der Start und Umschaltzeitpunkt und andere Dinge vorgegeben werden.

Hinweis:
Bei allen Commandlets kommt der „Default Scope“ zum Tragen. Wenn ihr Forest also mehrere Domänen und ADSites hat, dann sehen Sie nur Requests für ihre Benutzer. Ein „Set-ADServerSettings -ViewEntireForest:$true“ erweitert den Scope auf die komplette Organisation.

Ein Beispiel ist:

get-mailbox  `
   | New-MoveRequest `
     -BatchName "Userbatch1" `
     -CompleteAfter (get-date 22:00) `
      -BadItemLimit 10

Natürlich kann und sollte man bei „Get-Mailbox“ mit Filtern arbeiten, wenn man nur Teilmengen verschieben will. Ich habe hier die Zieldatenbank leer gelassen. Exchange sucht sich dann selbst Datenbanken für die Anwender aus. Das funktioniert so natürlich nur bei einer Migration von einem vorherigen System zu einer neuen Version. Bei einer Verlagerung von Postfächern in andere Datenbanken auf der gleichen Version muss man schon das Ziel angeben.

Interessant ist hier auch der Schalter „CompleteAfter“, der das frühere „SuspendWhenReadyToComplete“ ersetzen kann. Früher konnten Sie mehrere Mailboxen schon zu 95% in das Ziel verschieben aber dann die Replikation anhalten. Exchange hat dann zwar immer wieder mal „nachsynchronisiert“ aber die Verschiebung nicht abgeschlossen. So konnten Sie nacheinander Mailboxen je nach Bandbreite auf dem WAN in eine Zentrale konsolidieren. Wichtiger war dabei aber, dass der Abschluss der Migration in eine Zeit verlegt werden kann, in der die Anwender gar nicht arbeiten. Bis Exchange 2010 musste der Administrator dann abends noch ein „resume-Moverequest“ nachschieben.
MoveRequest verwalten

Bestehende Jobs können mit „Get-Moverequest“ ermittelt und angezeigt werden.

[PS] C:\>Get-MoveRequest "zzno-Mailbox, mnregnskap" | fl
 
ExchangeGuid               : 00919d46-e6f4-4087-9353-12345678437d
SourceDatabase             : EX2010DB1
TargetDatabase             : EX2016DB1
SourceArchiveDatabase      :
TargetArchiveDatabase      :
Flags                      : IntraOrg, Pull
RemoteHostName             :
BatchName                  : Userbatch1
Status                     : InProgress
RequestStyle               : IntraOrg
Direction                  : Pull
IsOffline                  : False
Protect                    : False
Suspend                    : False
SuspendWhenReadyToComplete : False
AdministrativeUnits        : {}
Alias                      : room1
ExtensionCustomAttribute1  : {}
ExtensionCustomAttribute2  : {}
ExtensionCustomAttribute3  : {}
ExtensionCustomAttribute4  : {}
ExtensionCustomAttribute5  : {}
DisplayName                : Room1
ExternalDirectoryObjectId  :
LastExchangeChangedTime    :
RecipientType              : UserMailbox
RecipientTypeDetails       : SharedMailbox
Identity                   : msxfaq.net/Resources/Exchangeroom/room1
IsValid                    : True
ExchangeVersion            : 0.10 (14.0.100.0)
Name                       : Room1
DistinguishedName          : CN=Room1,OU=Exchangeroom,OU=Resources,DC=msxfaq,DC=net
Guid                       : e67c8010-2e3b-4ac9-98ee-e12345678ad5
OrganizationId             :
Id                         : msxfaq.net/Resources/Exchangeroom/room1
OriginatingServer          : dc1.msxfaq.net
ObjectState                : Changed

Sie sehen hier aber auch, dass nicht alle Properties vorhanden sind. Insbesondere die Information, dass diese Migration „InProgress“ ist, sagt noch nichts, wie weit diese ist und wann diese vielleicht automatisch abgeschlossen wird. Dazu müssen wir noch einen Befehl „Get-Moverequeststatistics“ dranhängen:

[PS] C:\>Get-MoveRequest "zzno-Mailbox, mnregnskap" | Get-MoveRequestStatistics | fl *

PSComputerName                           : ex2016.msxfaq.net
RunspaceId                               : 00919d46-e6f4-4087-9353-1234567837d
PSShowComputerName                       : False
MailboxIdentity                          : msxfaq.net/Resources/Exchangeroom/room1
DistinguishedName                        : CN=Room1,OU=Exchangeroom,OU=Resources,DC=msxfaq,DC=net
DisplayName                              : Room1
Alias                                    : Room1
ExchangeGuid                             : 9a3f5486-9445-48a6-9d10-1123456786fc
ArchiveGuid                              :
Status                                   : Synced
StatusDetail                             : StalledDueToSource_LocalServerCapacityExceeded
SyncStage                                : IncrementalSync
Flags                                    : IntraOrg, Pull
RequestStyle                             : IntraOrg
Direction                                : Pull
IsOffline                                : False
Protect                                  : False
DoNotPreserveMailboxSignature            : True
Priority                                 : Normal
WorkloadType                             : Local
Suspend                                  : False
SuspendWhenReadyToComplete               : False
IgnoreRuleLimitErrors                    : False
RecipientTypeDetails                     : SharedMailbox
SourceVersion                            : Version 14.3 (Build 319.0)
SourceDatabase                           : EX2010DB1
SourceServer                             : EX2010.msxfaq.net
TargetVersion                            : Version 15.1 (Build 544.0)
TargetDatabase                           : EX2016DB1
TargetServer                             : EX2016.msxfaq.net
SourceArchiveDatabase                    :
SourceArchiveVersion                     :
SourceArchiveServer                      :
TargetArchiveDatabase                    :
TargetArchiveVersion                     :
TargetArchiveServer                      :
RemoteHostName                           :
RemoteGlobalCatalog                      :
BatchName                                : Userbatch1
StartAfter                               :
CompleteAfter                            : 2/23/2016 10:00:00 PM
EffectiveIncrementalSyncInterval         :
ConfiguredIncrementalSyncInterval        :
RemoteCredentialUsername                 :
RemoteDatabaseName                       :
RemoteDatabaseGuid                       :
RemoteArchiveDatabaseName                :
RemoteArchiveDatabaseGuid                :
TargetDeliveryDomain                     :
ArchiveDomain                            :
BadItemLimit                             : 10
BadItemsEncountered                      : 0
LargeItemLimit                           : 0
LargeItemsEncountered                    : 0
AllowLargeItems                          : True
QueuedTimestamp                          : 2/23/2016 11:29:03 AM
StartTimestamp                           : 2/23/2016 11:29:09 AM
LastUpdateTimestamp                      : 2/23/2016 1:59:27 PM
LastSuccessfulSyncTimestamp              : 2/23/2016 1:59:26 PM
InitialSeedingCompletedTimestamp         : 2/23/2016 11:29:35 AM
FinalSyncTimestamp                       :
CompletionTimestamp                      :
SuspendedTimestamp                       :
OverallDuration                          : 00:07:27.9484861
TotalSuspendedDuration                   : 00:00:00
TotalFailedDuration                      : 00:00:00
TotalQueuedDuration                      : 00:00:00
TotalInProgressDuration                  : 00:00:00
TotalStalledDueToContentIndexingDuration : 00:00:00
TotalStalledDueToMdbReplicationDuration  : 00:00:00
TotalStalledDueToMailboxLockedDuration   : 00:00:00
TotalStalledDueToReadThrottle            : 00:00:00
TotalStalledDueToWriteThrottle           : 00:00:00
TotalStalledDueToReadCpu                 : 00:00:00
TotalStalledDueToWriteCpu                : 00:00:00
TotalStalledDueToReadUnknown             : 00:00:00
TotalStalledDueToWriteUnknown            : 00:00:00
TotalTransientFailureDuration            : 00:00:00
TotalIdleDuration                        : 00:00:00
MRSServerName                            :
TotalMailboxSize                         : 1.705 MB (1,787,509 bytes)
TotalMailboxItemCount                    : 34
TotalArchiveSize                         :
TotalArchiveItemCount                    :
BytesTransferred                         : 2.12 MB (2,222,858 bytes)
BytesTransferredPerMinute                : 0 B (0 bytes)
ItemsTransferred                         : 34
PercentComplete                          : 95
CompletedRequestAgeLimit                 : 3650.00:00:00
PositionInQueue                          :
InternalFlags                            : SkipFolderPromotedProperties
FailureCode                              :
FailureType                              :
FailureSide                              :
Message                                  : Informational: The move request for mailbox 9a3f5486-9445-48a6-9d10-12345678bc6fc has reached synced state. Next
                                           incremental sync is scheduled at 2/23/2016 1:14:26 PM.
FailureTimestamp                         :
IsValid                                  : True
ValidationMessage                        :
RequestGuid                              : c0148d01-19db-486b-a04b-12345678
MigrationMailboxGuid                     :
SourceEndpointGuid                       :
Identity                                 : msxfaq.net/Resources/Exchangeroom/room1
DiagnosticInfo                           :
Report                                   :
RequestExpiryTimestamp                   :
ObjectState                              : New

Hier ist dann auch das „CompleteAfter“ zusammen mit einigen anderen Werten zu finden.

SuspendWhenReadyToComplete vs CompleteAfter

Ein unkontrolliertes Umschalten der Mailboxen am Ende der Migration fördert nur die Schweißperlen bei einem Administrator. Der Exchange Mailbox Replication Service kennt daher die Funktion die Inhalte der Postfächer erst auf ca. 95% zu replizieren und dann immer wieder die Änderungen in das Ziel zu übertragen aber die Mailbox nicht umzustellen. So können viele Postfächer schon mal in das Ziel übertragen werden und erst wenn alle Postfächer eine Gruppe im Ziel sind, kann die Migration an einem engeren Zeitraum abgeschlossen werden. So werden alle Postfächer quasi zur gleichen Zeit umgestellt, was speziell das Troubleshooting einfacher macht und die Koexistenz-Probleme (Free/Busy, Delegate, Räume etc.) reduziert. Das gilt insbesondere für Migrationen über WAN-Leitungen in die Cloud aber auch bei internen Konsolidierungsprojekten. Sowohl die verfügbare Bandbreite als auch die Postfachgrößen schwanken doch. Und wenn 95% geschafft sind, können mit hoher Wahrscheinlichkeit auch Fehler bei den letzten 5% ausgeschlossen werden.

# Ein angehaltenen Job wieder fortsetzen bis kurz vor dem Ziel
Get-MoveRequest | Resume-MoveRequest -SuspendWhenReadyToComplete

Angenommen ein Move steht mit “suspendwhenreadytocomplete” bei 95%, dann kann man ihn nicht mit folgendem Befehl Selbst ein Aufteilen geht aktuell nicht.

# Zuerst den Suspend wegnehmen
Get-MoveRequest "mailbox" | Set-MoveRequest -SuspendWhenReadyToComplete:$false

#Und dann das Ende vorgebenb
Get-MoveRequest "mailbox" | Set-MoveRequest -CompleteAfter (get-date 20:00)

Wenn Sie einen Resume gemacht haben und der Job dann aktiv ist, dann kann er auch nicht mehr angehalten werden. Die Fehlermeldung lautet dann:

StartAfter or CompleteAfter must not be set when the job is completinStartAfter 
or CompleteAfter must not be set when the job is completing.

Sie sollten sich also beim Erstellen eines Move-Request genau überlegen, wie und wann Sie am Ende weiter machen wollen

Status und Statistik per Powershell

Wer nicht nur ein paar Postfächer migriert sondern eine komplette Umgebung, der wird auf jeden Fall ein Monitoring wünschen. Das ist insbesondere dahingehend wichtig, um den Durchsatz und den aktuellen Status ermitteln zu können. Hier gibt es gleich mehrere Datenquellen, die Sie anzapfen können. Am einfachsten ist zuerst mal eine Exchange PowerShell:

# Anzeige aller Moverequests gruppiert nach dem Status
Get-MoveRequest | group status -NoElement

Count Name
----- ----
158  AutoSuspended
2232 Completed
1    StalledDueToTarget

Folgende Statusmeldungen habe ich schon gesehen.

AutoSuspended
Completed
CompletedWithWarning
CompletionInProgress
Failed
InProgress
Queued
ReadyToComplete
Suspended
WaitingForJobPickup
Synced

Etwas mehr Daten erhalten Sie, wenn Sie die Move-Requests mit "Get-MoveRequestStatistics" verketten. Dann erhalten wir auch Daten zu der übertragenen Datenmenge.

Get-MoveRequest | Get-MoveRequestStatistics | ft displayname,status,BytesTransferred -autosize

DisplayName                                                Status BytesTransferred
-----------                                                ------ ----------------
Mailbox1                                           AutoSuspended 1.033 GB (1,108,730,334 bytes)
Mailbox2                                           AutoSuspended 2.001 GB (2,148,254,929 bytes)
Mailbox3                                               Completed 138.7 MB (145,483,384 bytes)
Mailbox4                                               Completed 9.552 MB (10,015,869 bytes)
Mailbox5                                      StalledDueToTarget 357.6 MB (374,957,773 bytes)

Hier habe ich schon folgende Statusmeldungen gesehen. Die Liste ist vermutlich nicht komplett:

StalledDueToSource_DiskLatency
StalledDueToSource_Processor
StalledDueToSource_MailboxCapacityExceeded
StalledDueToTarget_ContentIndexing
StalledDueToTarget_Processor
StalledDueToTarget_DiskLatency
StalledDueToTarget_MdbAvailability
StalledDueToTarget_MdbCapacityExceeded 
StalledDueToTarget MdbReplication
StalledDueToTarget_MailboxCapacityExceeded
StalledDueToTarget_DataGuaranteeWait
CopyingMessages
InitialSeeding
CreatingFolderHierarchy
TransientFailureSource
CreatingInitialSyncCheckpoint
Finalization
Completed
StalledDueToMRS_CapacityExceeded
MapiExceptionFolderHierarchyChildrenCountQuotaExceeded
MapiExceptionFolderHierarchyDepthQuotaExceeded
FailedOther

Die Liste können Sie natürlich auch weiter verarbeiten. Allerdings dauert die Abfrage etwas länger. Es ist also nur bedingt für regelmäßige Abfragen geeignet. Zudem sind es nur die Summen aber keine aktuelle Übertragung.

Fehleranalyse

Dennoch sollten Sie schon genauer hinschauen. Ich habe auch schon Move-Requests gesehen, bei denen ich zuerst einen "permanenten Fehler" gesehen habe, der aber doch nur transient war.

[PS] C:\>Get-MoveRequest "problemmailbox"  | ft name,status,flags,suspend

Name                Status    Flags                   Suspend
----                ------    ----------------------- -------
zzde Mailbox Shop   Failed    IntraOrg, Pull, Suspend    True

In der Statistik ist dann aber

[PS] C:\>Get-MoveRequestStatistics "problemmailbox"  | fl failure*,status,message

FailureCode      : -2146233088
FailureType      : TooManyMissingItemsPermanentException
FailureSide      :
FailureTimestamp : 2/18/2022 2:57:02 PM
Status           : Failed
Message          : Error: This mailbox exceeded the maximum number of corrupt 
                   or missing items that were specified for this request.

Allein mit der Information würde ich aus dem Teil "PermanentException" denken, dass der Job nicht weiter geht. Das stimmt aber nicht, denn der Job ist nur erst mal "zurückgestellt".

(Get-MailboxStatistics "problemmailbox" -IncludeMoveReport).MoveHistory[0].report.failures.message

The long running job has been temporarily postponed. It will be retried again when resources become available.

Zuletzt möchte ich noch auf die Statistiken eines MoveRequests hinweisen, in denen zu den häufigen Status auch Zeiten protokolliert werden.

[PS] C:\>Get-MoveRequestStatistics "20GBMailbox" | fl total*

TotalSuspendedDuration                   : 00:00:00
TotalFailedDuration                      : 14:49:35.7847714
TotalQueuedDuration                      : 00:00:01.4405497
TotalInProgressDuration                  : 05:10:31.0208059
TotalStalledDueToContentIndexingDuration : 00:12:21.1750219
TotalStalledDueToMdbReplicationDuration  : 00:00:00
TotalStalledDueToMailboxLockedDuration   : 00:00:00
TotalStalledDueToReadThrottle            : 00:30:05.1483358
TotalStalledDueToWriteThrottle           : 00:43:56.0421139
TotalStalledDueToReadCpu                 : 02:40:16.1526032
TotalStalledDueToWriteCpu                : 00:29:30.1951102
TotalStalledDueToReadUnknown             : 00:00:00
TotalStalledDueToWriteUnknown            : 00:00:00
TotalTransientFailureDuration            : 00:00:00
TotalIdleDuration                        : 15.12:39:13.1265472
TotalMailboxSize                         : 17.54 GB (18,831,710,522 bytes)
TotalMailboxItemCount                    : 139224
TotalArchiveSize                         :
TotalArchiveItemCount                    :

Dieser Move war wohl einigen Zeit blockiert, weil die Server belastet waren.

Get-MailboxStatistics -IncludeMoveReport

Wen ein Move mit einem "Fehler" stehen bleibt oder nicht abgeschlossen wird, dann reichen die Daten aus dem MoveRequestStatistics nicht mehr aus. Der Move hinterlegt aber die Ergebnisse der Verschiebungen im Postfach.

$stats = Get-MailboxStatistics "mailboxid" -IncludeMoveReport -IncludeMoveHistory

Im Feld MoveHistory stehen dann die Details. Dies kann ein Array sein, so dass Movehistory[0] die letzte Verlagerung anzeigt:

# Ausgabe der Anzahl bisherige Migrationen
$stats.MoveHistory.Count
1

# Anzeige der letzten Migration
$stats.MoveHistory[0]

Schon diese Antwort liefert viele Properties, die sie weiter analysieren können. Weit interessanter ist aber der Report.

# Anzeige des Report der letzten Migration
$stats.MoveHistory[0].Report

# Oder das Logfile als Textformat
$stats.MoveHistory[0].Report.ToString()

# Weitere Liste der Fehler
$stats.MoveHistory[0].Failures

$stats.MoveHistory[0].report.failures.message
The long running job has been temporarily postponed. It will be retried again when resources become available.

Ich habe hier nur einen Teil der Ausgaben protokolliert, da die Details schon sehr umfangreich sind, bis herunter zum Stacktrace.

MRS Statistik und Perfmon

Einen echten Echtzeitstatus erhalten sie aber direkt vom Mailbox Replication Service, der sich auch über Performance Counter verewigt.

(Get-Counter "\MSExchange Mailbox Replication Service\*").countersamples | ft path,CookedValue -AutoSize

Path                                                                                                             CookedValue
----                                                                                                             -----------
\\EX2016\msexchange mailbox replication service\unreachable databases                                                0
\\EX2016\msexchange mailbox replication service\last scan timestamp (utc)                               20170313221616
\\EX2016\msexchange mailbox replication service\last scan duration (msec)                                            0
\\EX2016\msexchange mailbox replication service\transfer rate: read (kb/sec)                                         0
\\EX2016\msexchange mailbox replication service\transfer rate: write (kb/sec)                                        0
\\EX2016\msexchange mailbox replication service\transfer rate: transmission (kb/sec)                                 0
\\EX2016\msexchange mailbox replication service\resource health: local cpu (high priority)                           1
\\EX2016\msexchange mailbox replication service\dynamic capacity: local cpu (high priority)                        100
\\EX2016\msexchange mailbox replication service\resource health: local cpu (customer expectation)                    1
\\EX2016\msexchange mailbox replication service\dynamic capacity: local cpu (customer expectation)                 100
\\EX2016\msexchange mailbox replication service\resource health: local cpu (internal maintenance)                    1
\\EX2016\msexchange mailbox replication service\dynamic capacity: local cpu (internal maintenance)                 100
\\EX2016\msexchange mailbox replication service\resource health: local cpu                                           1
\\EX2016\msexchange mailbox replication service\dynamic capacity: local cpu                                        100
\\EX2016\msexchange mailbox replication service\resource health: ad replication (high priority)                      1
\\EX2016\msexchange mailbox replication service\dynamic capacity: ad replication (high priority)            2147483647
\\EX2016\msexchange mailbox replication service\resource health: ad replication (customer expectation)               1
\\EX2016\msexchange mailbox replication service\dynamic capacity: ad replication (customer expectation)     2147483647
\\EX2016\msexchange mailbox replication service\resource health: ad replication (internal maintenance)               1
\\EX2016\msexchange mailbox replication service\dynamic capacity: ad replication (internal maintenance)     2147483647
\\EX2016\msexchange mailbox replication service\resource health: ad replication                                      1
\\EX2016\msexchange mailbox replication service\dynamic capacity: ad replication                            2147483647
\\EX2016\msexchange mailbox replication service\utilization: mrs jobs (high priority)                                0
\\EX2016\msexchange mailbox replication service\utilization: mrs jobs (customer expectation)                         0
\\EX2016\msexchange mailbox replication service\utilization: mrs jobs (internal maintenance)                         0
\\EX2016\msexchange mailbox replication service\utilization: mrs jobs                                                0
\\EX2016\msexchange mailbox replication service\utilization: read jobs (high priority)                               0
\\EX2016\msexchange mailbox replication service\utilization: read jobs (customer expectation)                        0
\\EX2016\msexchange mailbox replication service\utilization: read jobs (internal maintenance)                        0
\\EX2016\msexchange mailbox replication service\utilization: read jobs                                               0
\\EX2016\msexchange mailbox replication service\utilization: write jobs (high priority)                              0
\\EX2016\msexchange mailbox replication service\utilization: write jobs (customer expectation)                       0
\\EX2016\msexchange mailbox replication service\utilization: write jobs (internal maintenance)                       0
\\EX2016\msexchange mailbox replication service\utilization: write jobs                                              0
\\EX2016\msexchange mailbox replication service\pst read bytes/sec                                                   0
\\EX2016\msexchange mailbox replication service\pst write bytes/sec                                                  0
\\EX2016\msexchange mailbox replication service\pst read operations/sec                                              0
\\EX2016\msexchange mailbox replication service\pst write operations/sec                                             0
\\EX2016\msexchange mailbox replication service\pst read messages/sec                                                0
\\EX2016\msexchange mailbox replication service\pst write messages/sec                                               0
\\EX2016\msexchange mailbox replication service\pst heap cache bytes                                                 0
\\EX2016\msexchange mailbox replication service\pst block btree cache bytes                                          0
\\EX2016\msexchange mailbox replication service\pst node btree cache bytes                                           0
\\EX2016\msexchange mailbox replication service\pst amap cache bytes                                                 0
\\EX2016\msexchange mailbox replication service\named property cache entries.                                        0

Allerdings sind hier nicht alle Counter auch wirklich hilfreich. Einige Counter verstehe ich so, dass Sie nur die aktuell konfigurierten Grenzwerte ausgeben, was an sich nicht schlecht ist. So könnte eine Auswertung bei Bedarf auch ermitteln, wie "nahe" der Messwert schon an den Grenzen liegt. Aber von all den Werten habe ich nur drei Werte als "interessant" herauskristallisiert:

\\EX2016\msexchange mailbox replication service\transfer rate: read (kb/sec)                                         0
\\EX2016\msexchange mailbox replication service\transfer rate: write (kb/sec)                                        0
\\EX2016\msexchange mailbox replication service\transfer rate: transmission (kb/sec)                                 0

Es gibt noch einen zweiten Countersatz, der "MSExchange Mailbox Replication Service per MDB" heißt, aber nur Daten für die Datenbanken liefert, die auf dem Server auch aktiv sind. passive Kopien in einer DAG liefern prinzipiell keine Daten.

Monitoring mit PRTG

Wer kein System Center Operation Manager einsetzt, kann durchaus mit PRTG eine stabile Überwachung erreichen. Natürlich sind solche Performance Counter gefundene Quellen, um diese mit PRTG zu ermitteln und zu visualisieren. Wer allerdings mehrere Server hat, muss auch mehrere MRS-Instanzen überwachen und das alles funktioniert natürlich nur On-Premises. Anstatt nun für jeden Exchange Server einen PRTG-Sensor zur Ermittlung der Performance Counter zu nutzen und die Daten dann zu addieren, habe ich kurzerhand ein PowerShell-Skript gebaut, was die Daten sammelt und an PRTG weiter gibt

Siehe dazu auch PRTG MRS-Counter

Weitere Links