Migration zu Exchange 2010

Eine Migration nach Exchange 2010 ist von Exchange 2003 und 2007 möglich. Aufgrund der Änderungen in der Datenbank wird es wieder kein "InplaceUpdate" geben, sondern auch hier ist eine "Swing-Server" Migration angesagt, bei der ein neuer Server in die Organisation installiert wird und dann die Postfächer zu migrieren sind.

Achtung Exchange 2003 Administratoren:
Exchange 2010 ändert das Schema und wenn ihre aktuelle Exchange Organisation immer noch rein Exchange 2003 ist (also noch nie ein Exchange 2007 Server installiert war), dann können Sie nach der Exchange 2010 Installation nie mehr einen Exchange 2007 Server nachinstallieren. Damit verbauen Sie sich den Weg z.B. weiter einen Notes Connector einzusetzen. Auch eine spätere Konsolidierung anderer Firmen könnte erschwert sein. Es kann daher sinnvoll sein, mindestens einen Exchange 2007 Server zu installieren.
Das trifft natürlich nicht für kleine Firmen mit einem Server zu, die solche Probleme ausschließen können.

Diese Seite ist keine vollständige Beschreibung einer Exchange 2010 Migration. Microsoft selbst hat eine sehr gute und umfangreiche Online-Hilfe, die das Vorgehen beschreibt. Ich beschränke mich hier auf die Dinge, die bei meinen Migrationen aufgefallen sind.

Achtung
Exchange 2010 aktiviert per Default die RPC Verschlüsselung, welche alte Clients aussperrt Siehe auch Outlook 2003

Folgende Links sind daher lesenswert:

Vorarbeiten Server und Dienste

Ehe Sie Exchange 2010 installieren können, sind die ein oder anderen vorarbeiten zu leisten:

  • Exchange 2003 SP2 Voraussetzung
    Sie müssen vor der Installation von Exchange 2010 in eine bestehende Umgebung auf jeden Fall alle Exchange 2003 Server auf SP2-Level bringen.
  • Exchange 2007 SP2 Voraussetzung
    Sie müssen vor der Installation von Exchange 2010 in eine bestehende Umgebung auf jeden Fall das Exchange 2007 SP2 installieren. Dadurch wird schon das Schema auf Exchange 2010 erweitert. (Siehe auch MSXFAQ.DE - E2007 SP2)
  • Active Directory Windows 2003 Forest Level
    Exchange 2010 erfordert den Windows 2003 Level für den Forest. Das bedeutet dass alle DCs im gesamten Forest schon Windows 2003 nutzen.
  • Windows 2003 SP2 GCs
    Zudem müssen die GCs in jeder Site mit Exchange 2010 Servern auf Windows 2003 SP2 sein.
  • Windows 2008 oder Windows 2008 R2
    Exchange 2010 lässt sich nicht mehr auf Windows 2003 Servern installieren. Sie benötigen daher zwingend Windows 2008 Server oder Windows 2008 R2.

Exchange Berechtigungen
Exchange 2010 setzt verschiedene Exchange Berechtigungen wieder neu. Wer also z.B.: das "DENY" der Domänen Administratoren entfernt hat, damit auch Konten, die in der Gruppe sind, auf Postfächer zugreifen können, wird dies danach wieder neu setzen dürfen. Exchange 2010 setzt das DENY wieder.

Aus meiner Sicht benötigen nur ganz wenige Benutzer überhaupt in die Gruppe der "Domänen Administratoren". Sie können nahezu alle Berechtigungen sauber delegieren, so dass diese Probleme nicht immer wieder für Unsicherheit sorgen müssten. Siehe auch AdminSDHolder und Adminkonzept.

  • SMTP Relay
    Ich habe es mir angewöhnt sehr früh das Logging für die SMTP-Dienste einzuschalten (IIS ist ja meist eh an). Wenn man nach ein paar Wochen den alten Exchange Server abschalten will, sollte man sicher sein, dass alle anderen Clients, die vielleicht noch per SMTP Mails einliefern (Drucker, Scanner, Swiches, Batchjobs mit Blat o.ä.) auch entdeckt und umgestellt sind. Natürlich kann man dem neuen Exchange Server die alte Adresse einfach zusätzlich geben, aber auf Dauer sollten Sie vielleicht statt Rechnernamen oder IP-Adressen schlicht einen Alias (z.B. smtp.firma.intern) verwenden, der auch die nächsten Jahre einfach umgelenkt werden kann.

Vorarbeiten bei Empfängern

Wer die MSXFAQ schon länger liest, kennt meine Ausführungen zum Thema Exchange RUS und Empfängerrichtlinien.. Mit Exchange 2010 gilt die gleiche Regel wie bei Exchange 2007, dass die Commandlets die Richtlinien "durchsetzen". Wer also bislang bei Exchange 2003 bei den Benutzern z.B. manuell die SMTP-Adressen geändert hat und dabei die Checkbox "Pflege durch den RUS" nicht deaktiviert hat, wird sehr bald ein böses Erwachen erleben:

Wenn Sie sich nicht sicher sind, dann gibt es zwei Optionen:

  • Pflege durch den RUS abschalten.
    Nutzen Sie ein Programm wie z.B. ADModify.NET, um einfach bei allen Benutzern die Checkbox zu entfernen. Dann sind sie sicher, dass ihre Mailadressen nicht verändert werden. Leider nehmen Sie sich dann auch eine effektive Verwaltung aller Benutzer durch die Empfängerrichtlinien.
  • Export und Vergleich
    Sie können natürlich Exchange 2007/2010 die Änderungen vornehmen lassen und mit Tools vergleichen, ob sich die primäre Adresse geändert hat. SMTP Backup Restore ist ein Skript, welches die aktuelle primäre SMTP-Adresse in ein andere AD-Feld "rettet" und ihnen später die Option gibt, die betroffenen Objekte heraus zu finden und sogar wieder "fixen" zu lassen.

ähnliches gilt auch für alte Adresstemplates wie MSMail, cc:Mail etc., für die es schon lange keine Adress-Generatoren mehr gibt. Die gesamte Funktion der Empfängerrichtlinien müssen Sie überdenken, da Exchange 2007/2010 hier andere OPATH (statt LDAP)-Filter anlegt. Tipp: Legen Sie die Mailadressen einfach anhand der Firma oder Abteilung fest.

WinHTTP-Proxy und PowerShell

Mehrere Male bin ich nun auf die "Fall" gelaufen, dass die bestehende Konfiguration mit Internet Proxy-Einstellungen das Setup oder den Betrieb gestört haben. Denn seit Einführung der Remote PowerShell (RBAC) und WinRM ist es wichtig, wie die PowerShell Clients mit WinRM kommunizieren. Und wer hier z.B. au "Local System" beim Proxy etwas falsches eingetragen hat, wird Exchange selbst auf "Localhost" verwalten können. Hier die relevanten Befehle:

# Eintragen des Proxy und Ausnahmen
netsh winhttp set proxy proxy.msxfaq.net:8080 bypass-list="*.msxfaq.net"

# Import der Einstellungen aus dem aktuellen IE nach LocalSystem
netsh winhttp import proxy source=ie

# Anzeige der aktuellen Einstellungen
netsh winhttp show proxy

Wenn die Konfiguration nicht vorgegeben wird, dann kommt die "Automatische Konfiguration" zum Tragen

Schema Update durch doppelte LinkIDs blockiert

Ich selbst bin bei meiner ersten produktiven Exchange 2010 Installation gleich auf das Problem gestoßen, dass das Schemaupdate nicht möglich war. Das Problem waren bereits vergebene LinkIDs, die man durch eine Änderung der Schemadateien umgehen kann.

Sie gesonderte Seite LinkID.

Schema Update blockiert Exchange 2003 Routing

Mindestens einmal ist es bei einer Firma passiert, dass ein "PrepareAD" den Mailfluss der gesamten Exchange Organisation "angehalten" hat. Die Mails sind in der Warteschlange verblieben. Hier ein Auszug aus dem Posting:

Problem: Mail started to queue up in the deferred delivery queue and would not deliver as expected.
 
Cause: This is due to the way that the Prepare Schema and Prepare Domain switches work when prepping the Exchange Organization für installation of Exchange 2010. When these commands are sent Exchange temporarily suspends usage of the Exchange mail domain. This primärily affects internal mail delivery. Once the domain preparation and active directory replication has completed Exchange then has to Update its own Metabase information für mail routing. The amount of time that this takes varies on the configuration of the Org, dependencies such as number of Domain Controllers, Global Catalog Servers, Exchange Servers and Network Latency. As such we only recommend running these commands typically on a weekend after hours.
 
Resolution: There is no recommended method of accelerating the Directory Replication. As attempting to speed up the replication will result in the restarting the process. The replication process was monitored with the Repelmon utility. As Directory Replication was complete customer then systematically rebooted the Exchange Servers. This was to force the Metabase Update on the Exchange Server so that additional Time would not be needed für mail Delivery.

Quelle: EXUSG  http://www.exusg.de/

Das Problem dürfte nur in großen verteilen Exchange 2003 Umgebungen auftreten und es kann nicht ausgeschlossen werden, dass es ein Einzelfall war. Vermutlich werden es die meisten Firmen gar nicht bemerken und die ganz großen Firmen werden es dann auch "durchstehen" müssen. Ich bin nur überrascht, weil der gleiche Effekt ja auch schon beim Update zu Exchange 2007 aufgetreten sein musste.

PrepareDomains und Berechtigungen

Die Installation von Exchange 2010 setzt natürlich wieder einige Berechtigungen neu. Das kann besonders auf Dienstkonten durchschlagen, die Zugriff auf alle Postfächer haben müssen (z.B. Blackberry o.ä.) und aus mir nicht immer nachvollziehbaren Gründen Mitglied in Administrativen Gruppen sind. Es sollte sich schon herumgesprochen haben, dass seit Exchange 2000 die Gruppe der Administratoren, Domänen Administratoren, Organisationsadministratoren ein explizites "DENY" auf Postfachinhalte haben. Viele Administratoren "ändern" dies aber leichtsinnig, indem Sie die "DENY"-ACL entfernen und damit als Administrator auch in alle Postfächer kommen. Besser, und aus revisionsgründen einfacher nachvollziehbar, ist aber die explizite Vergabe der Berechtigungen auf Postfachebene oder Datenbankebene. Diese expliziten Berechtigungen können sogar ein vererbtes "DENY" aushebeln.

Kurz: Wer in so einer Konfiguration die Exchange 2010 Berechtigungen anwendet, wird einige Berechtigungen verlieren.

Besonderheiten um den CAS

Ein Exchange 2010 CAS-Server kann im Bezug auf OWA leider nicht auf Exchange 2003 Postfachserver zugreifen. Während der Phase der Koexistenz ist es daher erforderlich, zwei "Zugänge" für Outlook Web Access bereit zu stellen. Microsoft plant dies so, dass Sie dem neuen Exchange 2010-Zugang die bisherige URL zuweisen, damit die Anwender sich nicht umgewöhnen müssen. Der Exchange 2010-Server wird aber Clients, die noch nicht migriert sind, auf eine zu definierende URL umlenken. (Client redirect). Die Einstellungen ist nur er PowerShell möglich

Set-OWAVirtualDirectory -Exchange2003URL https://owa2003.msxfaq.de/exchange

Der Zugriff für andere Protokolle (POP3, IMAP4, ActiveSync und Outlook Anywhere ist aber weiter möglich.

Knifflig wird es für Firmen, die OWA etwas umfangreicher z.B. mit Token-Lösungen oder Portalseiten abgesichert haben. Hier ist im individuellen Fall zu prüfen, wie die Migration umgesetzt werden kann. Bei einer Portallösung wäre es noch denkbar, dass die Portalsoftware abhängig von Benutzer bzw. dem Wert in HomeMDB dem Benutzer individuelle Links anzeigt, die er nutzen kann.

Kleinen Firmen werden diese Doppelkonfiguration, die ja auch ein weiteres Zertifikat, eine offizielle IP-Adresse und eine Regel in der Firewall erfordert, vielleicht damit umgehen, dass alle relevanten Postfächer auf einen Schlag umgezogen werden. Firmen mit einem ISA-Server könnten sich behelfen, indem Sie auf der gleichen Webseite einfach die URL "/owa" nach Exchange 2010 umlenken und die anderen URLs nach Exchange 2003. Allerdings funktioniert dies nicht mehr so einfach, wenn Exchange 2007 schon mit im Spiel ist. Und die Anwender müssen nach der Migration eben "lernen", dass Sie "/owa" eingeben.

RPC Verschlüsselung und Outlook 2003

Exchange 2010 erzwingt per Default eine RPC Verschlüsselung, die aber Outlook 2003 nicht per Default aktiviert. Wenn sie vorab nicht die Profileinstellungen in Outlook 2003 anpassen wollen, dann sollten Sie nach der Installation des CAS-Servers dort den Zwang zur Verschlüsselung abschalten.

Set-RpcClientAccess -Server Exchange_server_name -EncryptionRequired $False

Achtung:
Wenn sie "öffentliche Ordner" verwenden, dann müssen Sie die Encryption auch auf dem Postfachserver zulassen, da Outlook solche Zugriffe nicht über den CAS durchführt sondern direkt gegen den Mailboxserver, auf dem die öffentlichen Ordner liegen.

Folgende KB-Artikel liefern weitere Infos:

Remote PowerShell und Exchange 2007 Server

Dieses Problem tritt nur auf, wenn Exchange 2007 Server in der gleichen Exchange Organisation vorhanden sind

Wenn Sie im Exchange 2010 System Manager in der CAS-Rolle eine Fehlermeldung erhalten und letztlich nur das Exchange Control Panel per GUI administrieren können, dann liegt dies daran, dass die Gruppe "Exchange Trusted Subsystem", mit welcher die PowerShell Commandlets arbeiten, keine Leserechte auf vorhandene Exchange 2007 Server hat (Genauer die IIS Metabase).

Lösung: Addieren Sie die Gruppe "Exchange Trusted Subsystem" auf den Exchange 2007 Servern zu den lokalen Administratoren.

Get-OwaVirtualDirectory und Zugriffsfehler

Ein anderer Bug des IIS hindert Sie ebenfalls an der Konfiguration der CAS-Rolle. Wenn Sie bei Get-OwaVirtualDirectory einen -2147024891 erhalten, dann liegt das oft an einem "leeren" Feld in der Metabase.

Es ist sehr wohl ein unterschied, ob ein Feld samt Inhalt vorhanden ist, oder "leer" ist oder nicht definiert ist. Wenn Sie im IIS z.B.: mit IP-Beschränkungen gearbeitet oder an der Authentifizierung gedreht haben, dann kann es passieren, dass dies dann die Exchange Commandlets stören. Allerdings ist es kein Exchange Fehler sondern ein WMI-Fehler auf die IIS Metabase. Und einen Fix für den IIS gibt es natürlich auch:

  • 939573 FIX: Error message in Internet Information Services 6.0 when you use the Active Directory Service Interfaces to enumerate the metabase properties of a virtual directory: "Error 0x80005008"

Alternativ können Sie selbst mal den IIS stoppen in einen Blick in die "METABASE.XML" werfen und dort nach einen Eintrag "IpSecurity=""“ " suchen und löschen (wenn er leer ist). Beim IIS6 hilft ihnen METAEDIT dabei.

Besonderheiten zum Hub/Transport und Edge

Hier habe ich bislang noch keine signifikanten Änderungen feststellen können, die von Exchange 2007 abweichen. Exchange 2010 installiert sich in die gleiche neue administrative Gruppe "Exchange Administrative Group (FYDIBOHF23SPDLT)" mit einer eigenen Routinggruppe "Routing Group (DWBGZMFD01QNBJR)". Natürlich müssen größere Umgebungen einen Blick auf "Link State" werfen bzw. dieses deaktivieren und auch das Messagetracking hat sich von Exchange 2003 nach 2010 geändert, so dass Sie nicht mehr "durchgehend" verfolgen können.

Da ich bislang einen Edge-Server nur in als virtuelle Maschine installiert und betrachtet habe, kann ich dazu nicht viel sagen. Als effektiven Spamschutz ziehe ich hier NoSpamProxy n natürlich vor.

Mailboxrolle DAG und CAS

Das sicher interessanteste Feature ist die Konfiguration der Postfachspeicher in einer hochverfügbaren Konfiguration. Die Database Availability Group ist fast komplett über die grafische Konsole einzurichten und zu verwalten. Das ist alles so schrecklich einfach geworden, dass man gerne man übersieht, dass für ein CAS-Array dann doch wieder die PowerShell erforderlich ist:

New-ClientAccessArray -Name CAS -Fqdn cas.msxfaq.de -Site Paderborn
Get-MailboxDatabase | Set-MailboxDatabase -RpcClientAccessServer cas.msxfaq.de

Über weitere "Besonderheiten berichte ich später. 

Zertifikate

Auch Exchange 2010 benötigt "Zertifikate". Neu ist, dass die beiden Funktionen "New-ExchangeCertificate" und "Import-Certificate" nun in die GUI gewändert sind. Die Auswahlfunktionen werden aber den ein oder anderen Admin erst mal überfordert.

Irritierend ist auch, dass der Assistent durchaus eine Anforderung erstellt, die Sie bei einer offiziellen Zertifizierungsstelle einreichen können, aber das Zertifikat dennoch sofort als "lfSigned" im Zertifikatsspeicher auftaucht. Bekommt man dann von der Zertifizierungsstelle die passende CER-Datei, dann kann man NICHT das "Import-Certificate"-Commandlet oder Menü nutzen. Ich habe die CER-Datei dann über die MMC für Zertifikate in den Zertifikatspeicher des Computers importiert. Ohne weiteres Zutun war das Zertifikat dann "offiziell". Ich nutze aber mittlerweile doch wieder lieber meine Kommandozeilen (Siehe E2K7:Zertifikate). Dann habe ich diese auch gleich in der Dokumentation und weiß, was ich letztlich anfordere.

Inhalte Verschieben

Wie auch in den vorherigen Migrationen müssen sie die Postfächer verschieben und die öffentlichen Ordner replizieren. Im Bereich der Postfächer hat sich etwas getan. Bei Exchange 2007 SP1 oder älter sperrt Exchange den Benutzer mit dem Beginn der Migration aus und verschiebt die Daten (1-4 GB/Stunde). Erst nach dem Move kann der Anwender wieder arbeiten. Mit Exchange 2007 SP2 oder Exchange 2010 als Quelle und Exchange 2010 als Ziel werden die Inhalte kopiert, während die Benutzer noch auf der Quelle arbeiten und erst am Ende für kurze Zeit ausgesperrt, um die letzten Änderungen zu übertragen.

Outlook und Updates

Auch bei einer "Swing"-Migration kann es zu einer Unterbrechung des Betriebs für die betroffenen Postfächer kommen. Wenn ein Postfach von Exchange 2010 nach Exchange 2010 verschoben, wird, dann kann das "Online" erfolgen, d.h. der Inhalt wird auf das Zielsystem übertragen während der Anwender weiter arbeiten kann und nur am Ende wird kurz der Benutzer ausgesperrt, um die letzten Änderungen nachzuholen und dann den Zugriff auf dem neuen Server zu erlauben.

Aber bei der Migration von Exchange 2003 oder 2007 nach Exchange 2010 kommt diese Funktion noch nicht zum Tragen, so dass hier wieder abhängig von der Outlook Betriebsart die ein oder andere "Störung" zu erwarten ist:

  • Outlook im ONLINE-Betrieb
    Sobald der "Complete-MoveRequest" gestartet wird, wird Outlook "ausgesperrt" und einen Neustart anfordern. Aber erst nach dem Anschluss der Migration ist ein neu Verbinden möglich. Dieses Verhalten entspricht auch den bisherigen Migrationen.
  • Outlook im Cached Mode
    Die Aufforderung für den Neustart von Outlook kommt durch die Replikation mit Verzögerung, nachdem der "Complete-MoveRequest" gestartet wurde. Der Benutzer kann weiter mit Outlook und der OST-Datei arbeiten. Aber erst nach Abschluss der Verschiebeoperation und dem Neustart von Outlook kann der Anwender wieder eine Verbindung herstellen und weiter arbeiten..

Wenn sie später Postfächer zwischen Exchange 2010-Servern verschieben, werden diese Pausenzeiten stark minimiert werden, da während der Migration die Benutzer weiter auf dem alten Postfach arbeiten können.

Exchange Lizenzanzeige

Neu in Exchange 2010 ist nun auch ein Assistent der ermittelt, wie viele Exchange Server in der Organisation vorhanden sind, wie viele davon lizenziert sind und auch wie viele Postfächer davon vorhanden und lizenziert sind. dabei werden ihnen zwei Dinge auffallen

  • Viele Enterprise CALs
    Noch nicht ganz geklärt ist die Methode, mit der die Exchange Management Shell die erforderlichen Lizenzen ermittelt. Hier ein Beispiel eines Server, auf dem nur ein Testbenutzer angelegt ist:

    Obwohl definitiv keine Funktionen genutzt werden, die eine Enterprise CAL erfordern, wird diese gezählt.
  • Exchange Installateur zählt mit
    Das Konto, welches Exchange 2010 installiert hat, bekommt auch ein Postfach. Dies sollten Sie auch nicht löschen, da diese Anmeldedaten z.B. benötigt werden, um RBAC zu verwalten. Allerdings ist dies auch zu lizenzieren.

Bestätigung:
Anscheinend zählt das in Exchange 2010 enthaltene PowerShell Skript die Benutzer und deren Notwendigkeit einer eCAL nicht korrekt. Es wird daher irrtümlich auch dann eine eCAL angezeigt, selbst Sie nicht erforderlich ist.

Microsoft hat mittlerweile ein alternatives Skript bereit gestellt
Report Exchange Server 2010 Client Access Licenses (CALs)
http://gallery.technet.microsoft.com/ScriptCenter/en-us/acdcb192-f226-4517-b3f9-005dce6f4fc3

Es ist sicher nur eine Frage der Zeit bis auch das Skript im Produktumfang durch ein RollupFix aktualisiert wird.

Weitere Links