Autovervollständigung von Outlook 2010 auf Outlook 2013

Die Autovervollständigung bei der Eingabe der E-Mail Adresse wird seit Outlook 2010 nicht mehr in einer .nk2-Datei gespeichert, Sondern in dem Format Stream_Autocomplete_XXXXX.dat, wobei XXXXX einen eindeutigen Hashwert darstellt. Um diese nun von einem Benutzer auf einen anderen zu übertragen gehen Sie wie folgt vor:

  1. Backup der alten Autocomplete-Datei:
    C:\Users\$OldUser\AppData\Local\Microsoft\Outlook\RoamCache\Stream_Autocomplete_XXXXX.dat
  2. Backup der neuen Autocomplete-Datei:
    C:\Users\$NewUser\AppData\Local\Microsoft\Outlook\RoamCache\Stream_Autocomplete_YYYYY.dat
  3. Kopieren der alten Autocomplete-Datei in das RoamCache-Verzeichnis des neuen Benutzers.
  4. Löschen der neuen Autocomplete-Datei in das RoamCache-Verzeichnis des neuen Benutzers.
  5. Diese Datei muss nun umbenannt werden. Der Hashwert der alten Stream_Autocomplete-Datei muss den der neuen Stream_Autocomplete-Datei entsprechen, dies bedeutet aus Stream_Autocomplete_XXXXX.dat wird Stream_Autocomplete_YYYYY.dat.

Wenn man nun Outlook startet ist die alte Autovervollständigung mit allen Einträgen wiederhergestellt.

 

Exchange 2007/2010 Connector-Size abfragen

Exchange-Verwaltungsshell

Abfrage der globalen Nachrichtengröße
Um die globale Einstellung der Nachrichtengröße anzuzeigen:

Get-TransportConfig | ft MaxSendSize, MaxReceiveSize

Es wir ihnen nun eine MaxSendSize und eine MaxReceiveSize gezeigt, was die globalen Einstellungen darstellen. Alle Mails, die größer als diese Angabe sind,werden abgelehnt! Um nun die gewünschte Größe zu ändern:
(hier mit einer Größe von 20 MB)

Set-TransportConfig –MaxSendSize 20MB –MaxReceiveSize 20MB

RECEIVE-Connectoren
Um die Nachrichtengröße der RECEIVE-Connectoren abzufragen:

Get-ReceiveConnector | ft name, MaxMessageSize

Nachrichtengrößen der Connectoren verändern.

Set-ReceiveConnector “Connectorname” –MaxMessageSize 20MB

SEND-Connectoren
Um die Nachrichtengröße der SEND-Connectoren abzufragen:

Get-SendConnector | ft name, MaxMessageSize

Nachrichtengrößen der Connectoren verändern:

Set-SendConnector “Connectorname” –MaxMessageSize 20MB

 

Exchange 2010 – store.exe Speicher begrenzen

Exchange Server 2007/2010 gehen mit Arbeitsspeicher nicht gerade zimperlich um.
Sobald der Server läuft nimmt er sich gleich mal was er bekommen kann.

Durch einen kleinen Eintrag im Schema kann man die max. Cachegröße
des Exchange aber verringern.

Man ruft dazu auf dem Exchange ADSIEDIT.msc auf.
Dann stellt man eine Verbindung zum Server her und wählt in der Auswahl
„Bekannte Namenskontext auswählen“ die Konfiguration aus.
adsiedit

Dann hangelt man sich durch folgende Punkte durch.
-> Configuration -> Services -> Microsoft Exchange -> Exchange ->Administrative Groups
-> Exchange Administrative Groups -> Servers -> -> Name des Servers ->

Dann auf Information Store die Eigenschaften aufrufen.

Hier sucht man sich den Wert: msExchESEParamCacheSizeMax raus
und trägt den passenden Wert ein.
adsiedit2

store
ACHTUNG!!
Die Berechnungsgrundlage ist bei Exchange 2007 und 2010 unterschiedlich
Hier 2 Beispiele bezogen auf eine max. Cache Größe von 2GB

Exchange Server 2007 (2GB x 1024 = 2048MB x 1024 = 2097152 KB / 8 = 262144 Blöcke
Exchange Server 2010 (2GB x 1024 = 2048MB x 1024 = 2097152 KB /32 = 65536 Blöcke

Wichtig ist hier, dass der Exchange 2010 seine Daten in 32kb Blöcken ablegt statt in 8kb Blöcken
wie der Exchange 2007.

WICHTIG!!
1. Wenn der Wert msExchESEParamCacheSizeMax verändert wird, dann muss auch ein Wert für msExchESEParamCacheSizeMin eingetragen werden. Dieser muss kleiner sein als der SizeMax Wert.
2. Nach der Aktion muss man unbedingt den Information Store Dienst neu starten dass die Änderungen wirksam werden.

In meinem Fall (siehe letzten Screenshot) habe ich den Exchange 2010 auf 2.5GB Cachegröße
reduziert.

Exchange 2007/2010 – Wiederherstellung aus NTBackup

Restoring Mailbox Data from a Recovery Database in Exchange 2010 SP1

by Mike Pfeiffer on July 9, 2011

In this post I am going to outline this process of restoring mailbox data from a recovery database in Exchange 2010 SP1. This is kind of a long overdue follow up to my previous post on backing up Exchange 2010 using Windows Server Backup (WSB), which you can find right over here. What I am going to do here is restore an old database backup that was created using the steps in that post. Then I’ll show you how to mount it as a recovery database, and then we’ll take a look at several methods used to restore mailbox data from it using the Exchange Management Shell.

So here’s the scenario; I’ve got a mailbox server called MBX1 with the following disk layout:

  • C:\ – System Drive
  • E:\ – Exchange Database
  • F:\ – Database backups

The MBX1 server has a single database called DB01 and the database file (along with the logs) are stored on the E:\ drive. I am doing regular backups using WSB and storing them on the F:\ drive. I basically need to do a point in time restore and retrieve some data from about seven months ago. Even though I have more recent backups, they don’t have the data I need. I am going to create a Recovery database from a previous backup so I can selectively restore mailbox data from it into the production database.

Restoring the Backup

The first thing I’ll do is start WSB on the MBX1 server and select Recover from the Action menu:

As I mentioned earlier, the backups are stored on the F:\ drive on MBX1. On the Getting Started screen I’ll select This server (MBX1) to specify the location of the backups and then I’ll click Next:

I need to go back to the end of last year to retrieve the data I’m interested in. You can see that on the Select Backup Date screen that the oldest successful backup I have within this time frame is from December 9th of 2010. I’ll select that date and click Next:

On the Select Recovery Type screen I’ll select Applications and then click Next:

On the Select Application screen I’ll select Exchange for the application to recover, then I’ll click Next:

On the Specify Recovery Options screen, I want to leave my existing database alone and restore the backup to an alternate location. Then I can create a Recovery Database later using these files and restore only specific mailbox data from the backup. I am going to set the restore location to E:\RecoveryDB since I know the E:\ drive has plenty of space. After that, I’ll click Next:

At this point I am ready to restore the data, so on the Confirmation screen I’ll hit the Recover button and the restore will begin immediately:

I can monitor the status of the restore on the Recovery Progress screen. As long as the status comes back as Completed I am in good shape:

As you can see from the above screen shot, the restore was successful, so I can click Close. I can navigate out to the E:\ drive to view the files:

Everything looks good so far, I just need to make a note of a couple things before I move on. Notice the directory structure in the above screen shot. The database was restored to a sub folder of the recovery location specified during the restore. It restored the database in a folder called DB01 (which was the original folder name) in a sub directory called E_ since it was originally stored on the E:\ drive. I need to remember the path and the log generation prefix for the database, which is e01, as shown above. These details will be important for getting the database into consistency in the next step.

Getting the Database into a Clean Shutdown State

In order for Exchange to mount a database, it needs to be in a clean shutdown state. I’ll use the eseutil tool to play any outstanding transactions into the database to get it clean. Before I begin, I’ll open a command prompt, switch to the directory that contains the database and logs, and use the following command to view the status:

eseutil /mh DB01.edb

When reviewing the output, the database state will be reported as Dirty Shutdown:

What I will do next is perform a soft recovery to get the database consistent. I’ll run the following command to do this:

eseutil /r e01 /d

The /r specifies that I’m doing a soft recovery. The e01 is the log generation prefix for the database. I’m using the /d switch without any arguments to specify the database path, which is in the current directory. Since the logs are also located here, I don’t need to use the /l switch, as it defaults to the current path. Once the operation has completed successfully, I can run eseutil again with the /mh switch to verify the database is clean shutdown:

Now that my database has been restored and brought to a clean shutdown state I can create the Recovery Database.

Creating the Recovery Database

The next step in the process is to create the Recovery database using the database files restored from the backup. To do this, I’ll use the New-MailboxDatabase cmdlet with the following syntax:

New-MailboxDatabase -Name RecoveryDB -EdbFilePath E:\RecoveryDB\E_\DB01\DB01.edb -LogFolderPath E:\RecoveryDB\E_\DB01 -Recovery -Server mbx1

Notice that I’ve specified the path to the database and log files using the location where the database was restored. Also, the key to creating the Recovery database is to make sure you use the -Recovery switch parameter, as shown above. You can see I got a warning message after running the command stating the Recovery database was created using an existing file, and that I need to ensure that the database is in a clean shut down state before I try to mount it. I already did this in the previous step, so I can safely ignore this message and mount the database using the following command:

Mount-Database RecoveryDB

The Recovery database is now mounted, and I’m ready to restore mailbox data.

Finding Mailboxes and Performing a Simple Mailbox Restore

Now that my Recovery database is online, I need to be able to see what mailboxes are available for restores. I can use the Get-MailboxStatistics cmdlet to do this:

Get-MailboxStatistics -Database RecoveryDB

If you’re looking for a specific mailbox, you can filter the results using the following syntax:

Get-MailboxStatistics -Database RecoveryDB | ?{$_.DisplayName -like 'Mike*'}

You can see in this command I’ve used the ? alias for the Where-Object cmdlet. I’m using the -like operator to filter the results and only show me the mailboxes that start with Mike.

When restoring mailbox data from a Recovery database in Exchange 2010 SP1, we use the New-MailboxRestoreRequest cmdlet. When running this cmdlet, the source mailbox in the recovery database needs to be identified using one of three possible values; the DisplayName, MailboxGUID, or LegacyExchangeDN values. Keep in mind that you cannot reference the source mailbox using the Exchange Alias when performing a restore.

So, let’s take a look at the restore process. Based on the previous commands I can see that there is a copy of my mailbox in the Recovery database. To do a complete restore of the mailbox data to the original mailbox that is currently active in the production database I’ll use the following command:

New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 'Mike Pfeiffer' -TargetMailbox mpfeiffer

Depending on the size of the mailbox, it may take quite some time to perform the restore. I can keep tabs on the progress using the following one-liner:

Get-MailboxRestoreRequest | Get-MailboxRestoreRequestStatistics

Dealing with Multiple Mailboxes with the same DisplayName

It’s possible that a Recovery database will have multiple mailboxes with the same display name. This can happen if there were one or more disconnected versions of a mailbox, in addition to an active mailbox, in the same database during the time of the back up. In this case, you can use the MailboxGuid value to identify the source mailbox when doing a restore. Consider the following:

Get-MailboxStatistics -Database RecoveryDB | ?{$_.DisplayName -like 'Isabel*'} | fl DisplayName,MailboxGuid,DisconnectDate

Here you can see that there are two mailboxes with the same display name in the Recovery database. One has a DisconnectDate defined, meaning it is a disconnected mailbox, and the other one does not which means it was the active mailbox in the database at the time of the backup. If you run into a scenario where there are multiple mailboxes in a database with the same display name, use the above command to determine the MailboxGuid of each mailbox. You can then use this value to identify the correct mailbox when performing a restore.

New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 4a1d2118-b8cc-456c-9fd9-cd9af1f549d0 -TargetMailbox ihill

Restoring Individual Mailbox Folders

Here you can see that I am using the -IncludeFolders parameter to specify that only data from the Inbox should be restored from the mailbox in the recovery database:

New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox administrator -TargetMailbox administrator -IncludeFolders '#Inbox#'

The -IncludeFolders will accept a list of one or more mailbox folders. You can specify well-known folder names as well as personal folders using this parameter. Notice that the value needs to be enclosed in hash marks (#). For example, if you wanted to restore only the contacts folder, use #Contacts#, or #Tasks# for the Tasks folder, and so on. For more details, check out the help for this parameter in the TechNet documentation for the New-MailboxRestoreRequest cmdlet. If you simply want to restore a single root folder, check out the -SourceRootFolder parameter.

Restoring to an Archive Mailbox

Restoring a mailbox to a users archive is as simple as tacking on the -TargetIsArchive switch parameter to our original restore command. Here’s the command and output:

New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 'Mike Pfeiffer' -TargetMailbox mpfeiffer -TargetIsArchive

Obviously, you’ll need to ensure that the target mailbox has been archive enabled for this to work.

Restoring to an Alternate Mailbox

By default, the New-MailboxRestoreRequest cmdlet looks for a matching LegacyExchangeDN on the source and destination mailbox, or checks to see that an X500 proxy address on the target mailbox corresponds to the LegacyExchangeDN on the source mailbox. This ensures that you do not accidentially restore mailbox data to the wrong location. If you need to restore data to an alternate mailbox, you can use the -AllowLegacyDNMismatch switch parameter:

New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox 'Mike Pfeiffer' -TargetMailbox administrator -TargetRootFolder Restore -AllowLegacyDNMismatch

In this example, I am restoring the data from my mailbox in the recovery database to a sub-folder of the administrator mailbox called Restore. Here’s a screen shot of the administrator mailbox after running the above restore command:

Be careful when restoring to alternate mailboxes. If you omit the -TargetRootFolder parameter, the data will be restored and merged into the existing folders in the target mailbox. On the other hand, that might be exactly what you want — if so, just remove the -TargetRootFolder parameter.

Bulk Restores

You might find yourself in a situation where you need to restore data from all mailboxes in a recovery database. For example, let’s say you need to restore the Contacts folder for all of your mailboxes. In this case, you could use a foreach loop to iterate through each mailbox in the recovery database and restore that particular folder to the active mailboxes:

foreach($mailbox in Get-MailboxStatistics -Database RecoveryDB) {
  New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox $mailbox.DisplayName -TargetMailbox $mailbox.DisplayName -SourceRootFolder Contacts
}

This might take a while; you can monitor the progress using the Get-MailboxRestoreRequest with the -Status parameter:

Get-MailboxRestoreRequest -Status Queued

As you’ve seen, there are a lot of steps and multiple options when it comes to restoring data from a recovery database. Obviously, this is not something you want to learn on the fly when a disaster strikes. I’d highly recommend documenting and testing your restore procedure on a regular basis.

iPhone/iPad Kennwortabfrage für Exchange 2007/2010 deaktivieren

Wenn man iPhone oder iPad in Kombination mit einem Exchange 2007/2010 Server benützt, wird man gezwungen ein Kennwort zu hinterlegen. Dies Eigenheit kann man am Exchange 2007/2010 Server deaktivieren.

  • Exchange Verwaltungskonsole öffnen
  • Organisationskonfiguration
  • Clientzugriff > Exchange ActiveSync-Postfachrichtlinien (es sollte hier nur einen Filter geben)
  • „Windows SBS Mobile Mailbox Policy“ oder „Default“  markieren und Eigenschaften öffnen
  • Register Kennwort > „Kennwort anfordern“ deaktivieren
  • alle Fenster schliessen
  • iPhone/iPad > Einstellungen > Allgemein > Code-Sperre > Code deaktivieren (kann notwendig sein, dass zuvor der Code einmal geändert werden muss)

Exchange 2003 aus AD entfernen

Es gibt eigentlich immer nur drei Gründe, warum Sie einen Exchange Server aus dem ADSI-Edit entfernen müssen.

  1. Die Installation von Exchange ist fehgeschlagen aber der Exchange Server ist schon tief im AD integriert.
  2. Die Deinstallation von Exchange hat nicht alle Informationen aus dem AD bereinigt.
  3. Der Exchange Server existiert nicht mehr und es besteht keine Möglichkeit, dass er wieder online kommt.

Sollten Sie nur Probleme mit dem Betrieb von Exchange haben, bitte niemals etwas auf dem ADSI-Edit entfernen. Für eine Wiederherstellung von Exchange werden diese Einträge benötigt. Des Weiteren ist ein manueller Eingriff immer mit Vorsicht zu genießen und sollte niemals ohne eine Sicherung durchgeführt werden.

Wenn Sie alles berücksichtigt haben und den Exchange Server manuell entfernen möchten gehen Sie folgendermaßen vor:

  • Starten Sie den ADSI-Editor auf einem Server wo die AD Tools installiert sind  (Start -> Ausführen -> ADSIEDIT.MSC)
  • Klicken Sie mit der rechten Maustaste auf ADSI-Editor und auf “Verbindung herstellen”
  • Wählen Sie die “Konfiguration” aus dem Drop-down Menü aus

  • Klicken Sie auf OK.
  • Navigieren Sie zu folgenden Container

  • Im Container CN=Servers finden Sie für jeden weiteren Exchange Server einen Container. Darunter gliedern sich weitere Containter, wie z.B. CN=InformationStore auf. Hier können Sie auch nur die Exchange Datenbank entfernen, falls es hierbei Probleme geben sollte. Wenn Sie den kompletten Exchange server aus dem AD entfernen möchten. löschen Sie bitte den Container CN=Server_Name (In dem Fall “MSBLOG-EXCH2003 – Roter Kreis)

Danach ist der Exchange Server nicht mehr in der Domäne verfügbar.

Es sollte danach in der Exchange Shell folgendes Kommando ausgeführt werden:

Get-Mailbox | Update-Recipient

ACHTUNG:

Es kann passieren, dass nach der Deinstallation oder entfernen des Exchange 2003 Servers aus dem AD, die öffentlichen Ordner unter Exchange 2010 keine E-Mails mehr empfangen können. Dieses Problem habe ich in folgenden Artikel beschrieben:
http://www.msblog.eu/offentliche-ordner-konnen-nach-migration-auf-exchange-2010-keine-e-mails-empfangen/

Migration Exchange 2003 > Exchange 2010

Hinweis:
Der angeführte Blog ist im Original von Frank Zöchling. Er hat diesen auf seinem Blog http://www.frankysweb.de veröffentlicht.

Immer mehr Unternehmen wollen inzwischen zu Exchange 2010 migrieren. Der meiner Einschätzung nach häufigste Fall ist die Migration von Exchange 2003 zu Exchange 2010. Exchange 2007 wurde von vielen Unternehmen ausgelassen. Wie Exchange 2003 zu Exchange 2010 migriert wird beschreibe ich in diesem Artikel.

Die Testumgebung
FWDC01 ist ein Windows Server 2003 R2, dieser Server fungiert als Domain Controller (frankysweb.local) und DNS-Server. FWEX2003 ist ein Windows Server 2003 mit installiertem Exchange 2003. Auf dem Exchange 2003 befinden sich 3 Postfächer (Bart, Lisa, Maggie) und  ein öffentlicher Ordner mit 3 Kontakten (Homer, Marge, Mr. Burns).

Auf dem Server FWEX2010 ist aktuell nur das Betriebssystem Windows Server 2008 R2 installiert. Außerdem ist der Server der Domäne frankysweb.local als Member Server beigetreten.

Vorbereitung Exchange 2003 für die Migration

Zunächst erledigen wir die Vorbereitungen für die Migration. Wenn noch nicht geschehen muss das Service Pack 2 für Exchange 2003 installiert werden. Das Service Pack 2 ist Voraussetzung für die Migration. Wenn das SP2 installiert ist, bringen wir Exchange 2003 in den “Einheitlichen Modus”. Dieser Vorgang ist vergleichbar mit dem Anheben des Funktionslevels einer Domäne oder Gesamtstruktur und kann nicht rückgängig gemacht werden. Für den “Einheitlichen Modus” dürfen sich nur Exchange 2000 Server oder höher in der Organisation befinden. Für die Migration auf Exchange 2010 dürfen sich allerdings nur noch Exchange 2003 Server in der Organisation befinden. Ältere Exchange Versionen müssen zunächst auf Exchange 2003 migriert werden.

Um Exchange in den Einheitlichen Modus zu bringen, klicken wir im Systemmanager mit der rechten Maustaste auf die Exchange Organisation und wählen im Kontext Menü “Eigenschaften”.

Um den Betriebsmodus zu ändern klicken wir dann auf “Modus ändern”

Die Warnung wird mit “Ja” bestätigt. Danach sollte der Betriebsmodus “Einheitlicher Modus” angezeigt werden

 

Installation Exchange Server 2010

Auf dem Server FWEX2010 der aktuell als Member Server fungiert, installieren wir zunächst die Voraussetzungen für Exchange 2010. In diesem Artikel habe ich beschrieben welche Voraussetzungen für die 3 Exchange Rollen (Mailbox, Hub-Transport, ClientAccess) installiert werden müssen. Eine komplette Übersicht, welche Windows Rollen/Features für welche Exchange Rollen benötigt werden gibt es hier:

http://technet.microsoft.com/de-de/library/bb691354.aspx

Wenn die nötigen Windows Rollen installiert sind, führen wir das Exchange 2010 Setup aus. Wir führen also zunächst ein ganz normales Exchange Setup aus, an einer Stelle allerdings wählen wir den Exchange 2003 Server aus.

Mit einem Klick aus “Durchsuchen” können wir hier den Exchange 2003 Server angeben. Dies hat zur Folge dass die Routinggruppenconnectoren zwischen Exchange 2010 und Exchange 2003 automatisch erstellt werden. Die Connectoren lassen sich auch nachträglich manuell anlegen. Dies funktioniert über die Exchange Management Shell

New-RoutingGroupConnector -Name “MigrationConnector” -SourceTransportServers “FWEX2010.frankysweb.local” -TargetTransportServers “FWEX2003.frankysweb.local” -Cost 100 -Bidirectional $true

Nach erfolgreichen Exchange 2010 Setup führen wir noch folgenden Befehl von der Exchange 2010 DVD aus:

Setup.com /PrepareLegacyExchangePermissions

Der Befehl bewirkt das nach dem Schema Update für Exchange 2010 (welches bei der Installation automatisch aktualisiert wird) der RUS-Dienst (Recipient Update Service, Empfängeraktualisierungsdienst) während der Migration weiterhin funktioniert.

 

Kontrolle und Konfiguration Exchange 2010

Exchange 2010 wurde installiert und die Routinggruppenkonnektoren zwischen Exchange 2003 und Exchange 2010 sollten durch das Setup angelegt worden sein. Wir können das mit dem Exchange 2003 System Manger überprüfen

Natürlich können wir das auch über die Exchange 2010 Management Shell überprüfen

Get-RoutingGroupConnector


Jetzt steht die Konfiguration von Exchange 2010 an. Ich führe nur kurz auf, welche Punkte nötig sind:

  • Konfiguration der Exchange 2010 Datenbanken
  • Konfiguration Exchange 2010 Sendeconnector
  • Konfiguration Exchange 2010 Empfangsconnector
  • Konfiguration OWA, Outlook Anywhere

Die Konfiguration von Exchange 2010 unterscheidet sich dabei nicht von der Konfiguration einer normalen Exchange 2010 Installation. Ein entsprechender Artikel für die Exchange 2010 Basiskonfiguration befindet sich in Arbeit J

Wir sollten nun in der Lage sein Mails zwischen Exchange 2003 und Exchange 2010 zu senden. Um das zu Prüfen legen wir einen neuen Benutzer an, dessen Postfach auf dem Exchange 2010 gespeichert wird. Ich lege zum Test den Benutzer “Frank” an.

Zum Test des Mailroutings können wir OWA auf den beiden Servern verwenden. Ich sende also eine Mail von Frank an Bart und antworte dann von Bart aus auf diese Mail. Wenn das Mailrouting funktioniert geht es mit dem nächsten Schritt weiter.

Einrichten der Öffentlichen Ordner Replikation

Ich habe in meiner Testumgebung 2 Öffentliche Ordner angelegt (Kontakte und Kalender”. Der Ordner “Internet Newsgroups” wird bei der Installation von Exchange 2003 angelegt, alle Öffentlichen Ordner müssen nun auf den Exchange 2010 repliziert werden.

Wenn es nur wenige Öffentliche Ordner gibt, kann die Replikation manuell für jeden Ordner konfiguriert werden, dies geschieht per Exchange 2003 System Manager unter dem Punkt “Öffentliche Ordner” im Informationspeicher:

Mit einem Rechtklick können die Eigenschaften des Öffentlichen Ordners geöffnet werden, unter dem Reiter “Replikation” wird dann die Öffentliche Ordner Datenbank auf dem Exchange 2010 Server hinzugefügt

Diese Schritte werden nun für alle Öffentlichen Ordner wiederholt. Einfacher funktioniert das allerdings mit der Exchange 2010 Management Shell. Zunächst wird in das Script Verzeichnis des Exchange 2010 Servers gewechselt:

Cd C:\Program Files\Microsoft\Exchange Server\V14\Scripts

Jetzt kann das Script “AddReplicaToPFRecursive” ausgeführt warden:

.\AddReplicaToPFRecursive.ps1 -TopPublicFolder \ -ServerToAdd FWEX2010


Damit der Replikationspartner im Exchange 2003 System Manager sichtbar wird, muss der System Manager einmal geschlossen und wieder geöffnet werden. Das Replizieren der Inhalte der Öffentlichen Ordner kann je nach Datenmenge recht lange dauern. Darum empfliehlt es sich Geduld zu haben. Um zu prüfen ob alle Elemente der Öffentlichen Ordner repliziert wurden, können  die Spalten “Objekte gesamt” und “ItemCount” miteinander verglichen werden:

Der Befehl zum Anzeigen der Elemente auf Exchange 2010 Servern lautet:

Get-PublicFolderStatistics | ft Name,itemcount

Ein paar Öffentliche Ordner existieren nur auf dem jeweiligem Exchange Server, daher unterscheidet sich die Anzahl der Öffentlichen Ordner auf beiden Exchange Severn. Beide Listen lassen sich als CSV-Datei exportieren und zum Beispiel mit Excel vergleichen. Da sich die CSV-Dateien in Ihrer Struktur unterscheiden ist allerdings händische Arbeit nötig um die Dateien zu vergleichen. Spezielle Tools können einem diese Arbeit abnehmen.

Nachdem die Öffentlichen Ordner repliziert wurden, können die Adressbücher und der RUS-Dienst verschoben werden.

Verschieben des Empfängeraktualisierungsdienstes und der Adresslisten

Um den Empfängeraktualisierungsdienst auf Exchange 2010 zu verschieben wird Exchange 2010 als Server für die Adresslistengenerierung festgelegt. Diese Einstellung kann über den Exchange 2003 System Manager getätigt werden:

Mit einem Doppelklick auf die beiden RUS (Recipient Update Service) Einträge kann der neue Server festgelegt werden

Mit einem Klick auf “Durchsuchen” wird das Computer Konto des Exchange 2010 Servers ausgewählt. Jetzt kann das Offline Adressbuch verschoben werden.

Auch hier kann mit einem Doppelklick auf “Standard-Offlineadressliste” als Server Exchange 2010 festgelegt werden.

Nun können die Adresslisten auf Exchange 2010 aktualisiert werden, die folgenden Befehle sind dafür auf der Exchange 2010 Management Shell einzugeben:

Set-AddressList “Alle Benutzer” -IncludedRecipients MailboxUsers

Set-AddressList “Alle Gruppen” -IncludedRecipients MailGroups

Set-AddressList “Alle Kontakte” -IncludedRecipients MailContacts

Set-AddressList “Öffentliche Ordner” -RecipientFilter { RecipientType -eq “PublicFolder” }

Set-GlobalAddressList “Globale Standardadressliste” -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq “user” -or ObjectClass -eq “contact” -or ObjectClass -eq “msExchSystemMailbox” -or ObjectClass -eq “msExchDynamicDistributionList” -or ObjectClass -eq “group” -or ObjectClass -eq “publicFolder”))}

Jetzt können alle Postfächer von Exchange 2003 nach Exchange 2010 verschoben werden

Verschieben der Postfächer

Um die Postfächer zu verschieben kann entweder die Exchange 2010 Management Konsole oder die Shell verwendet werden, dazu wird eine Verschiebungsanforderung für jedes Postfach erstellt

Als Ziel Datenbank wird die Postfach Datenbank auf dem Exchange 2010 Server angegeben. Bei Bedarf lassen sich die Postfächer so auch wieder auf den Exchange 2003 Server verschieben.

Im nächsten Dialog kann angegeben werden ob ein Postfach trotz fehlerhafter Nachrichten verschoben werden soll. Die fehlerhaften Nachrichten werden dann ausgelassen und nicht verschoben.

Das Postfach wird nun verschoben

Um ein Postfach mit der Shell zu verschieben kann der folgende Befehl verwendet werden:

Get-Mailbox “Bart” | New-MoveRequest -TargetDatabase “Name der Exchange 2010 Datenbank”

Um alle Postfächer zu verschieben kann dieser Befehl verwendet werden:

Get-Mailbox | New-MoveRequest -TargetDatabase “Name der Exchange 2010 Datenbank”

Um den Status der Verschiebeanforderungen zu prüfen genügt dieser Befehl:

Get-MoveRequest

Nun heißt es “Warten” bis alle Postfächer verschoben sind. Je nach Größe und Anzahl der Postfächer dauert es seine Zeit. Meine Erfahrung hinsichtlich Dauer sind etwa 100MB/min.

Verschieben aller Öffentlichen Ordner Replikate auf Exchange 2010

Wenn alle Postfächer auf den Exchange 2010 Server verschoben wurden, dann kann Exchange 2003 als Replikationspartner für Öffentliche Ordner entfernt werden. Die Replikate können per Exchange 2003 System Manager oder per Management Shell verschoben werden:

Management Shell:

.\MoveAllReplicas.ps1 -Server FWEX2003 -NewServer FWEX2010

Wie auf dem Bild zu sehen ist, liegt das Script wieder im Ordner “C:\Program Files\Microsoft\Exchange Server\V14\Scripts”. Damit die Replikation vollständig durchgeführt werden kann empfiehlt es sich hier auch wieder etwas zu warten.

Deinstallation Exchange 2003

Um die Migration abzuschließen entfernen wir nun zunächst die Exchange 2003 Sendeconnectoren und die beiden Routinggruppenconnectoren. Mit einem Rechtsklick auf die betreffenden Connectoren öffnet sich das Kontextmenü, mit “Löschen” werden die Connectoren entfernt.

Jetzt kann Exchange 2003 via Systemsteuerung -> Software deinstalliert werden

Für die Deinstallation von Exchange 2003 ist die Installation CD erforderlich. Nachdem Exchange 2003 deinstalliert wurde kann der Server aus der Domäne genommen werden (wenn keine anderen Rollen mehr installiert sind) und abgeschaltet werden.