Exchange 2010 SP2 und Exchange 2007 Coexistenz über TMG 2010 veröffentlicht

Meine Überlegungen zur Coexistenz Ex2007/Ex2010 und OWA Zugriffe.

Exchange 2010 und Exchange 2007 existieren während einer Migrationsphase parallel. OWA Zugriffe werden über den TMG direkt an den Exchange 2010 CAS Server geroutet.

Durch Redirect am CAS Server besteht die Möglichkeit, die Client Zugriffe von OWA auf den Exchange 2007 umzuleiten, wenn das Postfach noch nicht migriert wurde. Der Exchange 2010 CAS Server liefert dem TMG dann einen 302 (Permanent redirect) und liefert den URL String zurück, wohin der Client sich connecten soll an den Browser. (ExternalURL am Exchange 2007 kann gesetzt werden, diese URL muss aber auch öffentlich erreichbar sein.)
Beispiel: Public OWA URL lautet: https://owa.firma.tdl/owa Am TMG werden diese Anfragen an den Exchange 2010 CAS geroutet. Der Exchange 2010 CAS stellt fest, dass das Postfach auf Exchange 2007 liegt und sucht den Exchange 2007 CAS Server, der die gleiche Authentifizierung hat um die Anfrage dorthin umzuleiten. Wenn in am Exchange 2007 CAS in der ExternalURL kein Eintrag steht, wird der InternalURL Eintrag verwendet.
Problem: Dieser ist typischerweise nicht veröffentlicht, weil es der Hostname des CAS Servers ist.
Problem2: In der ExternalURL kann eine öffentliche URL angegeben werden, die dann auch über den TMG geroutet werden müssen. Der User sieht in seinem Browser dann auch die „alte“ URL und nicht die von ihm eingegebene OWA-Adresse.
Problem3: Im Zertifikat muss auch die „alte“ URL eingetragen sein.

Lt. diesem Artikel: http://technet.microsoft.com/en-us/library/bb310763.aspx wird Proxying zwischen Exchange 2010 CAS und Exchange 2007 CAS nicht unterstützt.

Important:
An Exchange 2010 Client Access server will never proxy Outlook Web App requests to an Exchange 2007 Client Access server in the same Active Directory site. All requests within the same Active Directory site are redirected to an Exchange 2007 Client Access server, using either the InternalURL or ExternalURL properties for Client Access server, depending on which properties are configured.

 

Das gefällt mir so nicht, weshalb ich am TMG gerne zwei Regeln für OWA eintrage. Eine Regel für Exchange 2010 Mailboxen, eine weitere Regel für Exchange 2007 Mailboxen.

Die Reihenfolge der Regeln ist wichtig. Erst die Exchange 2010 Mailbox-Regel, danach die Exchange 2007 Mailboxregel. In der Exchange 2010 Mailboxregel wird dann eine Gruppenmitgliedschaft abgefragt. Trifft die Mitgliedschaft zu, dann zieht die Exchange 2010 Mailboxregel, trifft die Mitgliedschaft nicht zu, dann zieht die Exchange 2007 Regel.

Ja, dazu ist es nötig, migrierte User in die Gruppe für Exchange 2010 Mailboxen aufzunehmen. Da ich zu 90% Migrationen mache, die per Script ablaufen, ist es kein Problem, beim Erzeugen des Move-Requests auch die Gruppenmitgliedschaft zu pflegen.

Vorteil1: Der User sieht in seiner Adresszeile immer „seine“ OWA-URL die er auch eingegeben hat,
Vorteil2: Das Zertifikat kann weiterverwendet werden.
Vorteil3: Der interne Name des Exchange 2007 Servers muss nicht veröffentlicht werden.

Wenn die Migration erledigt ist, lösche ich einfach die Exchange 2010 Mailbox-Gruppe und passe die Regel am TMG an.
Teilweise verwenden die Kunden jedoch die Gruppe weiter, um den Active-Directory-Administratoren eine einfache Möglichkeit zu bieten, den Zugriff auf OWA per Gruppenmitgliedschaft zu steuern. Es muss dann keine Exchange Konsole gestartet werden um OWA zu regelemntieren.

Es gibt sicherlich auch weitere/andere Lösungen, aber mit dieser Lösung bin ich bisher ganz gut gefahren.

Matthias

Exchange 2007 nach Exchange 2010 Migration FreeBusy-View-Option-Fehlermeldungen

Im Anwendungslog steht folgender Fehler:

Details
Product: Exchange
Event ID: 4002
Source: MSExchange Availability
Version: 8.0
Symbolic Name: ProxyWebRequestFailed
Message: Process %1: %2 failed. Caller SIDs: %3. The exception returned is %4. Make sure that Active Directory site/forest containing the user mailbox has at least one local Exchange 2007 server running Exchange Availability service. Turn up logging for MSExchange Availability service and test basic network connectivity.
 

Im Text kommt zus. folgender Text vor: FreeBusyViewOptions.TimeWindow is too long.

Auf den CAS 2007 Servern muss im IIS folgender Eintrag hinzugefügt werden:

Expand the Default Website
Select the EWS virtual directory.
Double click Applciation Settings
Add a new application value:
Name: maximumQueryIntervalDays
Value: 62
Click OK..

Make the change on all the 2007 CAS servers. You should see the 4002 event go away.

Exchange 2010 Restore Mailbox Step by Step

Als Gedächtnisstütze hier mal die vorgehensweise wie ein Postfach oder Postfachinhalte aus der RDB (Recovery Datenbank) wiederhergestellt wird:

  • Recovery DB anlegen:

http://technet.microsoft.com/en-us/library/ee332321.aspx

New-MailboxDatabase -Recovery -Name RDB2 -Server EX2010MBXServer  -EdbFilePath „D:\MDBDATA\RDB\DB\RDB2.EDB“ -LogFolderPath „D:\MDBDATA\RDB\LOG“

  • Restore der Datenbank mit dem Backup-Programm in die RDB durchführen (dauert je nach DB Größe sehr lange)

Vorgehen bei TSM:
Beim TSM muss das Restore-Ziel ausgewählt werden, sonst steht nämlich die original Datenbank drinnen, was nicht so gut ist. Passiert nichts, geht aber auch nicht und die Zeit kann man sich sparen.
Restore mit Logfiles (das TSM macht den RollForward in der RDB) und den ESEUtil um einen Cleantshutdown zu haben.
Andere Backuplösungen:
<wird bei Erfahrung gefüllt, bzw. lasst mich wissen, worauf bei anderen Lösungen geachtet werden muss>

  • Daten wiederherstellen

Restore Data Using a RDB:
http://technet.microsoft.com/en-us/library/ee332351.aspx
New-MailboxRestoreRequest: http://technet.microsoft.com/de-de/library/ff829875.aspx

Wichtig:
The database must be in a clean shutdown state. Because an RDB is an alternate restore location for all databases, all restored databases will be in a dirty shutdown state. You can use Eseutil /R to put the database in a clean shutdown state.
Get-MailboxStatistics -Database RecoveryDB.
–> Das hat TSM für uns erledigt, ansonsten von Hand die DB in einen Clean Shutdown versetzen.

  • Inhalt der RDB ansehen/Mailbox GUID ermitteln

Die Mailbox-GUID ermitteln mit: Get-MailboxStatistics -Database „Archiving Database 1“ | list displayname,identity
(MailboxGUID in Zwischenablage kopieren)

  • Komplettes Postfach zurückspielen

New-MailboxRestoreRequest -SouceDatabase DB1 -SourceStoreMailbox 1d20855f-fd54-4681-98e6-e249f7326ddd -TargetMailbox Scott
(Hier die Mailbox GUID eintragen)

  • Oder Teile aus einem Postfach zurückspielen (Unterordner, Kalender, o.ä.)

New-MailboxRestoreRequest -SourceDatabase Recoverydb -SourceStoreMailbox „GUID for DB“ -TargetMailbox „usern name“ -TargetRootFolder „foldertorestoreto
Mailboxguid “801f870d-1ef2-4326-97f9-7bc475df055b”
(Exchange 2010 RTM:
Restore-Mailbox -Identity „Alex Heyne“ -RecoveryDatabase RecoveryDB -RecoveryMailbox „Alex Heyne“ -TargetFolder Restore
)

  • Beispiel um den Inhalt des Postfaches in einen Unterordner zurückspielen (Mailbox Limits beachten!)

New-MailboxRestoreRequest -SourceDatabase RDB2 -SourceStoreMailbox 801f870d-1ef2-4326-97f9-7bc475df055b –TargetMailbox thomas.mustermann@parmalat.nz.com -TargetRootFolder „Restore vom 27.01.2012“
“801f870d-1ef2-4326-97f9-7bc475df055b”