Exchange 2019: Maximale Größe der Datenbank überwachen

Ich hatte in einem früheren Artikel schon einmal über das 1TB Limit für Exchange Server 2019 Standard Server berichtet. Exchange Server Standard Edition mountet eine Datenbank ab einer Größe von 1 TB nicht mehr. leider fällt dies oft erst auf, wenn es zu spät ist.

Erreicht beispielsweise eine Datenbank die 1TB Grenze während des normalen Betriebs, dann fällt das Problem meist erst nach einem Neustart des Servers auf, denn eine gemountete Datenbank wird nicht einfach beendet.

Wie in dem älteren Artikel beschrieben, lässt sich die maximale Größe für Datenbanken in der Registry anpassen. Dazu enthält der Artikel auch ein Script, welches den nötigen Registry Schlüssel erstellt.

Das Script muss auf allen Exchange Servern ausgeführt werden, da sonst insbesondere bei einer DAG Probleme auftreten können. Wird die maximale Größe für die Datenbanken nur auf dem Server mit den aktiven Datenbankkopien angepasst, kann der passive Server die Datenbanken bei Ausfall des aktiven Servers aufgrund der Größe nicht mounten.
Ich habe daher noch ein weiteres Script erstellt, welches den Wert „Database Size Limit in GB“ und die aktuelle Größe für jede Datenbank von jedem Exchange Server abruft. Die Werte werden dann mit den entsprechenden Registry Pfaden in einem PowerShell Objekt gespeichert.

Das Script kann in größeren Umgebungen mit mehreren Datenbanken und Exchange Servern nützlich sein um die entsprechenden Werte und Konfigurationen zu überwachen. Bei Bedarf lassen sich die ausgelesenen Werte weiter mit der PowerShell weiter verarbeiten:

$MailboxDatabases = Get-MailboxDatabase -status | select name,guid,servers,DatabaseSize
$DatabaseMaxSizes = @()
foreach ($MailboxDatabase in $MailboxDatabases) {
$MailboxDatabaseSize = $MailboxDatabase.databasesize.ToGB()
foreach ($Server in $MailboxDatabase.Servers) {
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Services\MSExchangeIS\"
$DatabaseRegPath = "HKLM:\SYSTEM\CurrentControlSet\Services\MSExchangeIS\" + $Server.Name + "\Private-" + $MailboxDatabase.Guid
if ($env:computername -match $Server.Name) {
$DBSizeRegKey = Get-ItemProperty -Path: $DatabaseRegPath -Name "Database Size Limit in GB"
}
else {
$DBSizeRegKey = Invoke-Command -Computer $Server.Name -ScriptBlock {Get-ItemProperty -Path: $Using:DatabaseRegPath -Name "Database Size Limit in GB"}
}
if ($DBSizeRegKey) {
$RegDatabaseSize = $DBSizeRegKey."Database Size Limit in GB"
}
else {
$RegDatabaseSize = 1024
}
$DatabaseMaxSizes += @(
[pscustomobject]@{
Servername = $Server.Name
MailboxDatabasename= $MailboxDatabase.Name
RegistryMaxSizeInGB=$RegDatabaseSize;
CurrentDatabaseSizeInGB = $MailboxDatabaseSize
DatabaseGUID = $MailboxDatabase.Guid
DatabaseRegPath = $DatabaseRegPath
}
)
}
}
$DatabaseMaxSizes
Exchange 2019: Maximale Größe der Datenbank überwachen

Das folgende Beispiel liefert alle Server und Datenbanken bei denen das Limit nicht auf 10240 GB gesetzt wurde:

$DatabaseMaxSizes | where {$_.RegistryMaxSizeInGB -ne 10240} | ft

Dieses Beispiel zeigt alle Datenbenken welche aktuell über 5000 GB groß sind:

$DatabaseMaxSizes | where {$_.CurrentDatabaseSizeInGB -gt 5000} | ft

Bei Bedarf lassen sich die Informationen auch einfach exportieren:

$DatabaseMaxSizes | Export-Csv D:\Export\db.csv -NoTypeInformation

Wenn das Script die entsprechenden Registry Einträge nicht findet, geht es vom Standardwert 1TB aus (auch wenn es auf einen Fehler läuft). Wenn das Limit angehoben werden soll, müssen die Registry Keys erstellt werden:

Hier noch mein neues Lieblingszitat (aus dem verlinkten Artikel):

Exchange 2019: Maximale Größe der Datenbank überwachen

1 Gedanken zu „Exchange 2019: Maximale Größe der Datenbank überwachen“

  1. Ja, in die Falle bin ich auch schon reingelaufen und damals hab ich echt geschwitzt, weil das direkt nach einem Exchange Update aufgetreten ist. Hab dann das letzte Backup zurückgespielt, was natürlich nicht half. Zu dem Zeitpunkt kannte ich diese Grenze nicht und habe ein halbes WE damit verbracht, den Kübel wieder ans Laufen zu kriegen, bis ich dann glücklicherweise auf den Tipp mit dem Registryeintrag gestoßen bin.
    Ich habe dann später unsere DB in zwei gesplittet, um dem Problem aus dem Weg zu gehen.

    Antworten

Schreibe einen Kommentar