Best practices für die Inbetriebnahme zusätzlicher Exchange Server

Nach der Installation eines neuen zusätzlichen Servers wird dieser von den Clients normalerweise früher oder später erkannt und auch verwendet. Kümmert man sich nicht rechtzeitig um Zertifikate, URLs für vDirs und die AutoDiscoverServiceInternalUri, dann beschweren sich die Clients zurecht über den nicht fertigen Server. Nun gibt es mehrere Möglichkeiten, um nicht in Hektik verfallen zu müssen:

• Server außerhalb der Geschäftszeiten installieren und in Betrieb nehmen. Wenn kein Client aktiv ist, kann sich auch niemand beschweren.
• Dafür sorgen, dass Clients den neuen Server nicht kontaktieren

Dummerweise ist letzteres gar nicht so einfach. Exchange erstellt beim Setup einen SCP und trägt standardmäßig als Ziel https://servername/Autodiscover/Autodiscover.xml ein. Diesen Wert muss man nach dem Setup so bald wie möglich „neutralisieren“ – also auf $null setzen.

Set-ClientAccessService -Identity $env:COMPUTERNAME -AutoDiscoverServiceInternalUri $null

So ist für die Clients erst einmal Zeit gewonnen. Trotzdem ist es empfehlenswert, zusätzlich den Server in den Wartungsmodus zu versetzen.

Set-ServerComponentState -Identity $env:COMPUTERNAME -Component ServerWideOffline -State Inactive -Requester Maintenance

Nachteil hierbei: Da die beiden Befehle am besten direkt nach Installationsende abgefeuert werden sollten, muss man sich auf die Lauer legen. So ein Exchange Setup dauert je nach Umgebung 30 Minuten oder mehr und da will man in der Regel nicht daneben stehen und zuschauen.

Lösung: Die Schritte automatisieren. Hier ein Beispiel-Skript dazu:

function Write-Log {
    param (
        [string]$message,
        [string]$logFilePath=$logfile
    )
    Add-Content -Path $logFilePath -Value "$(Get-Date): $message" -Force
    Write-Output $message
}

$logFile = "C:\ExchangeSetupLogs\_SetupHelper.log"

# 1. Start Exchange setup 

$setupArgs = @(
  '/Mode:Install',
  '/Roles:Mailbox',
  '/TargetDir:"D:\Exchange"',  # Install path
  '/InstallWindowsComponents',  # (optional) install Windows roles/features automatically
  '/IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF'
) -join ' '

Write-Log "Starting setup"
Start-Process -FilePath "E:\setup.exe" -Wait -ArgumentList $setupArgs 
Write-Log "Setup finished"

# 2. As soon as setup.exe is finished: set SCP to $null
Write-Log "Adding Exchange SnapIn"
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Write-Log "Setting SCP for [$env:COMPUTERNAME] to NULL"
Set-ClientAccessService -Identity $env:COMPUTERNAME -AutoDiscoverServiceInternalUri $null

# 3. Put server into manintenance mode
write-Log "Enabling Exchange maintenance mode"
Set-ServerComponentState $env:COMPUTERNAME -Component ServerWideOffline -State Inactive -Requester Maintenance

# 4. (Optional) IIS stop or block 443 temporarily 
# Stop-Service W3SVC -Force

Write-Log "Finished."

Nun kann man ganz in Ruhe die Voraussetzungen schaffen, um die Server in Betrieb zu nehmen, also z.B.

• Zertifikat importieren, für IIS, SMTP und ggf. IMAP und POP3 aktivieren – nutzt Import-ExchangeCertificate, siehe auch hier
• URLs für vDirs setzen, AutoDiscoverServiceInternalUri setzen – hier hilft ggf. mein Skript
• DNS A record für den neuen Server zum „shared name“ hinzufügen (-> internal/externalUrl)

Frühestens jetzt kann man den Wartungsmodus für den Server aufheben.

Set-ServerComponentState -Identity $env:COMPUTERNAME -Component ServerWideOffline -State Active -Requester Maintenance

Dann kann es weitergehen, hier eine vermutlich unvollständige Liste:

• Sicherstellen, dass alle Receive Connectors vorhanden sind – auch hierfür gibt’s ein Helferlein
• Scope der Send Connectors erweitern um den neuen Server. Sicherstellen, dass ein etwaiger Smart host auch Mails vom neuen Server entgegennimmt. Möglicherweise muss man dazu den Server auf dem Smart host „bekannt“ machen
• Bei Hybridumgebungen den Hybrid Wizard ausführen und den neuen Server bei den Connectors hinzufügen
• Etwaiges Publishing und/oder Firewall-Regeln erweitern
• IMAP / POP3 aktivieren (wenn es denn unbedingt sein muss, besser aber alte Zöpfe abschneiden :))
• Standard DB leeren und löschen, neue DBs gemäß Konvention anlegen, ggf. neue DAG erstellen, second copy einrichten…
• Wenn der neue Server einen alten ersetzen soll: Mailboxen migrieren
• Backup umstellen/anpassen
• Ggf. IP Adresse „recyclen“
• …

Viel Erfolg! 🙂