Dieses Howto erhebt keinen Anspruch auf Richtigkeit. Ausführung auf eigenes Risiko! Dieses Szenario ist beispielhaft eine Exchange 2010/2013 Installation im KMU Umfeld, wobei alle Rollen auf einem Server präsent sind, ein passendes SAN-Zertifikat vorhanden ist, die externe ZugriffsURL und die interne ZugriffsURL wie üblich identisch sind und der interne Zugriff durch eine passende Forward-Lookup-Zone im DNS geregelt ist.
Vorab einige, deutliche Warnungen:
Ihr solltet Euch ausdrücklich Gedanken über die Zeitplanung machen. Hierzu eignet sich sehr gut die Checkliste bei Frank Carius: Link.
Insbesondere die Migration der öffentlichen Ordner führt bei ungeübten, die diese Migration zum ersten Mal sehen, doch zu einem nicht unerheblich größeren Zeitaufwand, wie bei üblicheren Migrationen in der Vergangenheit. Plant lieber Reserve ein und informiert die Anwender vorab, wenn öffentliche Ordner vermehrt genutzt werden. Wenn auf Euch Administratoren jemand mit dem Wunsch „mal eben“ für die Migration zugetreten ist, solltet Ihr mit Nachdruck Zeit einfordern. Weiterhin sind die Transportregeln, die Ihr in 2010 hinterlegt habt, auch zu bedenken.
Nach der vierten Installation und der zweiten Migration in den letzten 3 Monaten kann ich sagen, dass es zwar schon relativ rund läuft, dennoch gibt es auch für mich hier und da einige Verständnisprobleme und so einige Kopfschüttler. Erst ab dem Neuausrollen von CU1 für Exchange 2013 SP1 habe ich angefangen, ein wenig mehr Vertrauen in den Nachfolger meines Lieblingsmailservers, Exchange 2010 zu fassen. Doch erst nach CU2 hat’s für mich erstmals halbwegs zufriedenstellende Ergebnisse gegeben. Dazu schrieb auch Nils Kaczenski (MVP) vor einiger Zeit ein paar Zeilen: Link. Peter Bruzzese (MVP) hat für Euch übrigens einen anschaulichen Webcast bereitgestellt, den ich Euch – sofern Ihr Euch mit dem Thema noch nicht beschäftigt habt – wirklich wärmstens an’s Herz legen darf: Link. Ich bin wirklich erstaunt, wie sehr ich mich vom Technet wegbewege und wieder mehr auf die Artikel der Community und deren MVP’s verlasse, denn hier ist die Qualität und Verständlichkeit viel mehr gegeben, als in den knappen, teilweise auch irreführenden Erklärungen im Technet – leider – Die Qualität hat dort doch deutlich nachgelassen.
Menschen und Sites, an die Ihr Euch grundsätzlich immer halten könnt:
Frank Carius – Link
Nuno Mota – Link
Andy Grogan – Link
MSExchange.org – Link
Deutlicher: Ihr habt keine EMC mehr in 2013, aus der die Powershellkommandos mal eben mit ein paar Mausklicks initiiert werden! Und: Bei 2013 kommt es auf eine „“kleinlichere““ Schreibweise in der Powershell an. Das ist für viele eine Umgewöhnung. Spätestens jetzt kommt Ihr ohne Powershell sowieso nicht mehr umhin. Und auch diejenigen, die vorher ihren „eigenen Jargon“ in der Powershell gepflegt haben: Ihr habt einen Knoten in den Fingern. Spätestens nach einer Stunde. Viele Eurer Scripte, die Ihr Euch in der Vergangenheit zurecht geschrieben habt, müssen ggf. angepasst werden. Teilweise hat sich ja auch die technische Grundlage geändert. Hilfe gibt’s aber, denn Ihr könnt wie immer die Powershell mit (TAB) fragen, so bekommt Ihr schnell mit, dass mancher Syntax nun doch hier und da mal anders geschrieben wird.
Solltet Ihr Server 2012 von einer älteren Remotedesktopversion oder von Fremdanbietertools aus administrieren, kann es ebenfalls dazu kommen, dass falsche Werte (Zusätzliche Sonderzeichen) per Copy & Paste aus der Zwischenablage geliefert werden. Gerade hierbei ist es schnell möglich, die gesamte Organisationskonfiguration in den Himmel zu schicken. Schaut Euch die Zeile in der Powershell unbedingt an, bevor Ihr sie abschickt!
Ich empfehle Exchange Server 2013 auf mindestens 12GB RAM für Umgebungen bis 10 Anwender (Mehr ist hier deutlich mehr, da z.B. der von Sharepoint übernommene Suchdienst „noderunner“ sich einen erheblich größeren Schluck RAM nimmt, als bei Exchange 2010) und mindestens 4VCPU’s, sofern Ihr beide (noch verbliebenen) Rollen auf einer Hütte installiert. Ihr solltet die Hütte komplett durchpatchen, bevor Ihr mit der Installation beginnt. Ihr müsst beim alten LegacyServer 2010/2007 unbedingt darauf achten, die wirklich letzten Servicepacks und Rollups für Exchange (Kompatibilität für die Koexistenz 2010/2007 zu 2013) installiert habt. Vorab ist keine Koexistenz möglich! Einen Überblick über die Exchange Serverversionsnummern bekommt Ihr unter diesem Link.
Es ist nicht schädlich, sich vorab ein kleines, virtuelles Testszenario aufzubauen. Insbesondere für Personen, die vorab mit dem ECP von Exchange nicht gearbeitet haben. Auch hilfreich, wenn Ihr die Powershell noch nie benutzt habt. Übt damit Postfächer anlegen usw. Eure geliebte Exchange-Konsole ist in 2013 definitiv futsch!
Beispiel für 2010 EMC Benutzer: Viele Funktionen der alten, bekannten Konsole sind im ECP von 2013 definitiv nicht verfügbar. Das ECP bietet lediglich rudimentäre Funktionen. Wolltet Ihr in der Vergangenheit z.B. eine Weiterleitung einrichten, wobei die Email dann im Weiterleitungspostfach und im Zielpostfach aufschlägt, so war es komfortabel möglich, dieses einfach mit einem Haken in der EMC Konsole von Exchange 2010 setzen. In Exchange 2013 ist das nur noch mit der Powershell möglich: Set-Mailbox -Identity „Max Mustermann“ -ForwardingAddress „chefvonmax@mustermann.com“ -DeliverToMailboxAndForward $true. Da müsst Ihr Euch noch dran gewöhnen.
Vorbereitung
Vorab empfehle ich die Installation der privaten Zertifikate des Clientzugriffsservers. Startet dazu die MMC und öffnet das SnapIn für lokale Computerzertifikate und installiert Euren privaten Schlüssel für den Computer.
Bei der Installation sollten vorab die folgende Features installiert werden: (Powershell mit administrativer Berechtigung)
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, Server-Media-Foundation, RSAT-ADDS
Anschließend benötigt Ihr folgende Komponenten:
Unified Communications Managed API 4.0 Runtime – Link
Microsoft Office 2010 Filter Packs: Link
Service Pack für Microsoft Office Filter Pack 2010 (KB2460041), 64-Bit Edition: Link
Installation
Dann könnt Ihr das Exchange 2010 Setup starten. Ihr solltet entsprechend wählen, ob Ihr während des Setups „Drittanbietervirenscanner“, wie z.B. GFI Mailessentials unterstützen wollt: In diesem Fall müsst Ihr unbedingt die Frage nach der integrierten Funktion zum Schutz von Malware entsprechend verneint antworten. Es wird eine Warnung über die Schemaerweiterung angezeigt, sofern bei Euch tatsächlich alles in Ordnung ist.
Nach dem Setup solltet Ihr den Datenbanknamen der Mailbox überprüfen und ggf. korrigieren über PS: Get/Set-MailboxDatabase; Passt mit der Identität der Datenbank auf, so dass Ihr Euch aus Versehen nicht andere Mailboxdatenbanken umbenennt! So ist es bei der Migration anschließend leichter und Ihr kommt nicht aus Versehen auf die verkehrte Datenbank.
Migration
Nachfolgendes hat sich bei mir inzwischen bewährt. Ich empfehle in etwa diese logische Reihenfolge, so dass Du erfolgreich zum Ziel kommst. Noch einmal, es dauert deutlich länger. Wenn Du der Meinung bist, dass Du einen Knoten in den Fingern hast, frage die Powershell mit der TAB-Taste.
Los geht’s:
a) Bewegen eines Postfachs eines Benutzers aus der Gruppe Exchange-Organisationsadmins auf den neuen Server mittels ECP. Die neue ECP könnt Ihr am neuen Server aufrufen mittels folgender URL: „https://<<euerexchangeserverurl>>/ecp?ExchClientVer=15“. Nach Migration des Postfachs auf die neue Datenbank ist das nicht mehr notwendig.
b) Aktivieren Eures Zertifikats mittels Enable-ExchangeCertificate – Wie das geht steht hier: Link
c) Setzen der ZugriffsURL’s des neuen Servers. Da bei fast allen Installationen, die ich kenne, aus Kostengründen u.a. wg. eines SAN-Zertifikats und wegen möglicher Fehler bei der Ermittlung von Zonenumgebungen die interne und die externe Zugriffsurl identisch sind, könnt Ihr, sofern das bei Euch auch so ist, folgendes Script als PS1 abspeichern und in der Exchange-Powershell ausführen:
Powershellscript zum Setzen der Uris für den internen und externen Zugriff (Als ex2013vdir.ps1 abspeichern und in der Dateisicherheit zulassen), Credits Scott Jaworksi
#
# Author: Scott Jaworski
# Website: jaworskiblog.com
# Version: 1.0
# Description: This script sets internal and external URL’s on the specified Exchange 2013 Client Access Server
# then displays the results of all the urls that have been set.
# How to Use: Copy the text file to a location on the Exchange server. Change the .txt extension to .ps1,
# Open Exchange Management Shell, Browse to the location of the script in EMS, Run .\Set-Exchange2013Vdirs
#
Function Set-Exchange2013Vdirs
{
$ExServer = Read-Host “Please enter the Exchange 2013 Server Name you’d like to set Vdirs ”
$InternalName = Read-Host “Input the internal domain name eg.. IntMail.domain.com ”
$ExternalName = Read-Host “Input the external domain name eg. ExtMail.domain.com ”
Write-Host “Configuring Directories for $ExServer..” -Foregroundcolor Green
Get-WebservicesVirtualDirectory -Server $ExServer | Set-WebservicesVirtualDirectory -InternalURL https://$InternalName/EWS/Exchange.asmx -ExternalURL https://$externalName/EWS/Exchange.asmx
Get-OwaVirtualDirectory -Server $ExServer | Set-OwaVirtualDirectory -InternalURL https://$InternalName/owa -ExternalURL https://$ExternalName/owa
Get-ecpVirtualDirectory -Server $ExServer | Set-ecpVirtualDirectory -InternalURL https://$InternalName/ecp -ExternalURL https://$ExternalName/ecp
Get-ActiveSyncVirtualDirectory -Server $ExServer | Set-ActiveSyncVirtualDirectory -InternalURL https://$InternalName/Microsoft-Server-ActiveSync -ExternalURL https://$ExternalName/Microsoft-Server-ActiveSync
Get-OABVirtualDirectory -Server $ExServer | Set-OABVirtualDirectory -InternalUrl https://$InternalName/OAB -ExternalURL https://$ExternalName/OAB
Set-ClientAccessServer $ExServer -AutodiscoverServiceInternalUri https://$internalName/Autodiscover/Autodiscover.xml
Set-OutlookAnywhere -Identity “$ExServer\Rpc (Default Web Site)” -InternalHostname $internalName -ExternalHostName $ExternalName -InternalClientAuthenticationMethod ntlm -InternalClientsRequireSsl:$True -ExternalClientAuthenticationMethod NTLM -ExternalClientsRequireSsl:$True
Write-Host “Vdirs have been set to the following..” -Foregroundcolor Green
Write-Host “$ExServer EWS”
Get-WebservicesVirtualDirectory -Server $ExServer |Fl internalURL,ExternalURL
Write-Host “$ExServer OWA”
Get-OWAVirtualDirectory -Server $ExServer | Fl internalUrl,ExternalURL
Write-Host “$ExServer ECP”
Get-ECPVirtualDirectory -Server $ExServer | Fl InternalURL,ExternalURL
Write-Host “$ExServer ActiveSync”
Get-ActiveSyncVirtualDirectory -Server $ExServer | Fl InternalURL,ExternalURL
Write-Host “$ExServer OAB”
Get-OABVirtualDirectory -Server $ExServer | Fl InternalURL,ExternalURL
Write-Host “$ExServer Internal Autodiscover URL”
Get-ClientAccessServer $ExServer | Fl AutodiscoverServiceInternalUri
Write-Host “$Exserver Outlook Anywhere Settings”
Get-OutlookAnywhere -Identity “$ExServer\rpc (Default Web Site)” |fl internalhostname,internalclientauthenticationmethod,internalclientsrequiressl,externalhostname,externalclientauthenticationmethod,externalclientsrequiressl
Write-Host “The Powershell URL have not been set as part of this script. Set it if you choose” -ForegroundColor Yellow
}
Set-Exchange2013Vdirs d) Setzen der Outlook Anywhere externen Zugriffsurl im ECP, hab ich im Script vergessen
e) Testen des Zugriffs, nachdem Ihr die Firewall(s) korrekt konfiguriert habt, mittels folgendem Link
f) Bewegen der Clientpostfächer auf die neue Postfachdatenbank des neuen Servers über neues ECP
g) Bewegen der Systemmailboxen auf neue Postfachdatenbank des neuen Servers über das ECP
h) OBACHT!!! Migration der Exchange Public Folders – Finger weg vom Technet-Artikel!!!
-> Hierbei empfehle ich ausdrückliches Lesen dieses 2-teiligen Artikels bei MSExchange.org, da das zugehörige Tutorial im Technet nicht mal ansatzweise für die breite Masse ausgereift ist und m.E. Fehlkonfigurationen provoziert, insbesondere was Variablen Namen/Identities usw. betrifft. Er ist – gelinde gesagt – richtig (ich sag’s lieber nicht)… Insbesondere Neulinge dürfte eben dieser Technet-Artikel doch so einige Fettnäpfchen vor die Füße legen, deswegen verlinke ich ihn hier ausdrücklich nicht, sondern warne lediglich davor. Der o.g., alternative Artikel bei MSExchange.org zeigt Dir dagegen auch, warum Du das eben genau so machen solltest und gibt Dir dafür sehr gute Beispiele. PS-Kommandos, welche bei Copy & Paste fehlschlagen können, sind gar nicht erst enthalten. Du solltest den Artikel durchgehen und in exakt der beschriebenen Reihenfolge abarbeiten, ausdrücklich Schritt für Schritt!
Aus „Faulheit“ habe ich meine Öffentlichen Ordner nicht immer so stark unterteilt, wie im Artikel beschrieben, ich hatte bis jetzt noch nicht so große öffentliche Ordner vor der Nase. Die Beispiele selbst in diesem Fall (große Öffentliche Ordner) sind jedoch sehr gut und auch sehr einfach zu verstehen. Insbesondere bei größeren Installationen macht das erläuterte absolut Sinn. Weiterhin darf ich Euch empfehlen, die erwähnten Powershell-Scripts, genau wie im Artikel von Nuno Mota beschrieben, ausdrücklich nicht von der Microsoft Website herunterzuladen, sondern vom Exchange 2013 Installationsordner zu verwenden.Zur Sicherheit einmal archiviert, weil viel zu wichtig: Teil 1 und Teil 2.
Credits: Nuno Mota @ msexchange.org
i) Testen der Funktionen inklusive Public Folders mit einem oder mehreren Testbenutzern
j) Auf der alten Exchange Hütte mittels Exchange PS
Get-MailboxDatabase MBDB01 | Get-Mailbox Get-MailboxDatabase MBDB01 | Get-Mailbox -Arbitration
nachschauen, ob noch Müll liegengeblieben ist, diesen möglicherweise migrieren. Bei Problemen siehe hierzu Abschnitt „Mögliche Probleme“
k) Postfach&Public Folder Datenbanken vom alten Server dismounten und entfernen mittels Exchange PS:
Dismount-Database Datenbankname Remove-MailboxDatabase Datenbankname
l) OAB vom alten Server entfernen
m) Alten Server vom Sendeconnector entfernen
n) Alten Exchange Server Rolle für Rolle über //Systemsteuerung/Software deinstallieren und aus dem AD herausnehmen.
o) OAB überprüfen, mittels
Get-OfflineAdressbook | fl
hierbei seht Ihr, dass das OAB nicht mehr standardmäßig auf einem Server festgetackert ist, wie zuvor. Dennoch wurde das OAB nicht mehr aktualisiert, siehe $LastTouchedTime. Also müsst Ihr am neuen Server noch mal die OAB-Generierung anwerfen, mittels
Update-OfflineAddressbook -Identity <Eure OAB-Identity>
die ist üblicherweise „\Standard-Offlineadressbuch“.
Funktioniert das nicht, so solltet Ihr in Erwägung ziehen, das OAB zu löschen, eine neue, funktionierende Adressliste zu erstellen, und diese dann für das von Euch neu erstellte OAB zu verwenden. Hinweis: Der Syntax für 2013 enthält wg. o.g. Gründen nicht mehr die Variable „-Server“. Dass OABs nicht mehr über öffentliche Ordner verteilt werden und vieles mehr lernt Ihr unter anderem hier: Link.
p) Macht Abschlusstests!
— Ende der Reise —
Mögliche, mir in Exchange 2013SP1 CU2 bekannte Probleme:
1.) Sollten vor der Public Folder Migration noch Postfächer vergessen worden sein, und anschließend der User für die Migration im ECP nicht mehr nutzbar sein, so kann mittels Exchange PS auf dem 2013er Exchange
Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" Set-Mailbox "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" -Arbitration –Management:$true
das Ding wieder scharfgeschalten werden, ich gehe fast davon aus, dass Dir das auch passieren wird.
2.) Hatte z.B. Euer Chef vorher über EMC gewährten Vollzugriff und das „Send on behalf“/“Im Auftrag von“-Recht auf das Postfach seiner halbtags angestellten Sekretärin, und ist das Postfach bei ihm weiterhin eingebunden, so kann dieser jetzt keine Emails mehr versenden. Es wird eine Fehlermeldung 0x80040115 angezeigt und die Mails verbleiben im Posttausgang Eures Chefs. Der Fehler kann nicht mit KB2277593 behoben werden! Dafür habe ich derzeit leider keine Lösung außer eines Workarounds: Setzen einer Weiterleitung mit der Option DeliverToMailboxAndForward $true und Entfernen des Zugriffs auf das Postfach der Sekretärin.
Dieser Fehler kann durch Deaktivieren der fehlerhaften Automapping Funktion gelöst werden, indem Ihr das Recht manuell vergebt:
Add-MailboxPermission -Identity <username> -User <username> -AccessRight FullAccess -Automapping $false
3.) Es kommt während des Setups vor der Schemaerweiterung zu einem Fehler während der Überprüfung Eurer Domäne, das Fenster schließt sich ohne Meldung. Lösung: Ihr habt den Server 2012 versehentlich nicht vollständig durchgepatcht. Insbesondere fehlt Microsoft KB2756872.
Rollback der Installation
Sollte es bei der Installation von Exchange 2013 zu Problemen kommen, könnt Ihr vor der Migration die Datenbanken wie folgt rausschmeissen und anschließend Euer Glück erneut versuchen:
Get-Mailbox -Database "Datenbank <id>" | Disable-Mailbox Get-Mailbox -Database "Datenbank <id>" -Archive | Disable-Mailbox - Archive Get-Mailbox -Database "Datenbank <id>" -Arbitration | Disable-Mailbox -Arbitration -DisableLastArbitrationMailboxAllowed
Das wär’s soweit. Jetzt Kaffee holen und freuen.