Archive for the ‘Exchange 2007’ Category

Exchange 2007 Cluster Documentations

July 3, 2007

 

Using Standby Clusters

Using Geo-Cluster:

How to activate RPC over HTTPs for Exchange 2007

July 3, 2007

This is a very short step by step guide of how to configure your Exchange 2007 CAS to provide RPC over HTTPs.

 

1- Install RPC over HTTP Proxy component (windows component)

2- Install a certificate on your CAS server (E2K7: How to generate and install a certificate for a CAS server) –

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

3- Enable Outlook Anywhere via console (server configuration/client access /select your server / right-click on your server / enable Outlook AnyWhere) –

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

4- External host Name should match the name issued to the certifcate installed on your CAS

5- Autodiscover should configure your OL 2007 proxy authentication settings

 

Exchange Server 2007 RTM – Setup GUI Walkthrough

January 26, 2007
 

Exchange 2007 introduces a completely rewritten Setup GUI experience, designed to match the Administrative experience you’ll get with Exchange 2007 Management Console once the installation is completed. Like the Exchange 2007 Management Console, the new Exchange Setup is written on top of the Windows PowerShell cmdlets and is therefore completely scriptable with one-liners!

In the rest of this blog post, I’ll show you the new GUI and talk about the various options available throughout the setup process.

The Auto launch Screen

Above is the "auto launch" screen which is presented upon inserting the DVD disc. If this program does not run automatically, you can access it by double-clicking on setup.exe on the DVD. By clicking on the links, you can read about Exchange Server 2007, Hosted Services, Forefront Security, and install all the prerequisites before installing Exchange. Once installed, each prerequisite will indicate that it has been met by graying out the option and indicating "Installed" at the end of the text. Click on "Step 4: Install Microsoft Exchange" when you have completed installing the required programs.

Introduction

This is the introduction screen in Exchange Server 2007. Click "Help" to find out more, or click "Next" to continue. At any point of the installation, click on the "Help" button will bring up the relevant help section. Also, throughout the Setup wizard, the "Back" button can be used to go back to the previous page. The "Cancel" button can be used to abort the installation.

License Agreement

Please read through the end user license agreement (EULA). If you accept, please click "I accept the terms in the license agreement" and then click "Next". If you do not accept, you may click "Cancel" to exit.

Error Reporting

Error reporting will allow Exchange Server to send error information to Microsoft without user intervention. This will help us improve the quality of the software and also suggest solutions that may help with any errors encountered. Note that any personal information submitted in reports, if present, will not be used. If you would like to enable error reporting, please select "Yes"; otherwise click "No". To continue, click "Next".

Installation Type

Please select the installation type by clicking on the "Typical Exchange Server Installation" or the "Custom Exchange Server Installation" button. A typical installation will include the Hub Transport, Client Access and Mailbox roles, and Management Tools. If "Custom" is selected, you will be presented with page to customize the Exchange Server roles to install. To change the default installation path for Exchange, click "Browse" and select a path. By default it will be installed in "[Program Files directory]\Microsoft\Exchange Server". To continue, click "Next".

Server Role Selection

This page will be presented only if "Custom Exchange Server Installation" was selected from the last page. Click on the checkbox beside each role name to install the corresponding Exchange Server role. The Mailbox, Client Access, Hub Transport, and Unified Messaging server role can be installed together if desired. However, please note that each of the Edge Transport Server Role, Active Clustered Mailbox Role, and Passive Clustered Mailbox Role cannot be installed with another role on the same Exchange server. The Management Tools are installed with any selected role, or can be installed independently for an "Admin Only" configuration.

Exchange Organization

Please specify the name of the Exchange organization by typing in the text box. Note that this page is not presented if the Organization Name has already been specified by the first Exchange 2007 Server install or if you are installing in a preexisting Exchange 2003 organization.

Client Settings

This page is presented if the Mailbox role has been selected for installation and if this will be the first one in the organization. It is asking if you want public folders enabled for any Outlook 2003 or Entourage clients in your organization. This is the same as the "/EnableLegacyOutlook" switch when running setup from the command line. Select "Yes" or "No", then click "Next" to continue.

Mail Flow Settings

This page is presented if the Hub Transport has been selected for installation and if this will be the first install of the Exchange 2007 Hub Transport role in the organization. Please click "Browse" to select a legacy routing server (this server will be the target of the routing group connector, which will be automatically created).

Cluster Settings

This page is presented if you are installing the Active Clustered Mailbox Role. For the cluster type radio button, please select either "Cluster Continuous Replication" (CCR) or "Single Copy Cluster" (SCC). The CMS (Clustered Mailbox Server, previously called an "Exchange Virtual Server" – EVS) name is the name which will be created for the Exchange resource group. Please do not use the Windows cluster name or the name of any node that is in the cluster. The IP Address is the static IP address for the CMS, and it needs to be unique to the CMS.

Readiness Checks

The installation prerequisites for each role are checked here. Please wait for the checks to complete then click "Install" to start the installation. If there are errors, a detailed error message will be given on how to resolve the problem. If there are warnings, please take note and take appropriate action. The same prerequisite may show up more than once across the server roles (such as a required software update), but fixing the problem will satisfy the prerequisite. Note: if you wish to collapse the information area under each role, click once on the double up arrows on the right. To expand the information, click on that arrow (double down arrows) again.

Completion

The installation progress is shown in this screen and will be updated as the installation continues to each step. The installation can take a number of minutes to complete while at this stage. After everything is done, click Finish and the Exchange Management Console will open if the checkbox at the bottom remains checked. After this point, the auto launch screen is again presented and you should continue to "Step 5: Get critical updates for Microsoft Exchange" to get the latest updates.

Exchange Management Console – Finalize Deployment

The screenshot below shows the Exchange Management Console after Exchange Server 2007 is installed. The console helps you start configuring the newly installed server using the Exchange Server 2007 Finalize Deployment and End-to-End scenario guidance. Please click on the thumbnail to see a bigger version!

(Quelle : Jimmy Wong)

Exchange 2007 – Continuous Replications and Exchange Backups

January 18, 2007

In Microsoft Exchange Server 2007, continuous replication, also known as log shipping, is the process of automating the replication of closed transaction log files from a production storage group (called the "active" storage group) to a copy of that storage group (called the "passive" storage group) that is located on a second set of disks (Local Continuous Replication, or LCR) or on another server altogether (Cluster Continuous Replication, or CCR). Once copied to the second location, the log files are then replayed into the passive copy of the database, thereby keeping the storage groups in sync with a slight time lag.

In simple terms, log shipping follows these steps at the storage group level, with each storage group containing a maximum of one database:

  • Seed the passive copy database directory with a current copy of the active database.
  • When there is a new log file in the active copy log directory, copy it to the passive copy log directory.
  • Replay the log file from the passive copy log directory into the passive database.

One of the benefts of using continuous replication is the ability to offload Volume ShadowCopy Service (VSS)-based backups from the active storage groups to the passive storage groups. Exchange-aware VSS backups are supported for both the active and passive storage groups and databases. The passive copy backup solution we provide is VSS-only, and its implemented by the Exchange Replica VSS Writer that is part of the Replication service. Streaming backups are only supported from the active storage groups. You cannot use streaming backup APIs to backup the database on the passive side. You also need to use a third-party backup application that supports Exchange VSS, as NT Backup is not Exchange VSS-aware.

When you’re making a VSS backup off the passive copy, what happens to the transaction logs?  A common task during Exchange-aware backups is the truncation of transaction log files after the backup has completed successfully. The replication feature in Exchange 2007 guarantees that logs that have not been replicated are not deleted.

The challenges with taking a backup on the passive is that backups modify the header of the database. For example, they add information about the time of the last backup of the database. The VSS backup is made by possible by the Exchange Replica VSS Writer in the Replication service, and the Replication service has a copy of the data, but it can only get its data and modifications from the store. It can’t independently modify its copy of the database; that would produce divergence. Therefore, it can’t modify the header of its database copy.

The solution is to have the Replication service coordinate its backups with the store. As soon as you start a backup on the passive, the Replication service contacts the store on the active and tells it that a backup is about to start. This is done to prevent the same storage group on both the active and the passive from being backed up simultaneously. Once the backup is finished, the Replication service contacts the store and lets it know that the backup completed.

The database header modifications resulting from the backup are then made by the store on the active. This action generates a log record, which through continuous replication is copied to the passive. When it is replayed, the database header on the passive is then updated.

This is a little more complex than traditional backups. And it has some interesting side effects. For example, if you backup the passive and then immediately after the backup has finished you look at the database on the passive, it will not reflect the backup. The database on the active node, will however, reflect it.

So if you are backing up databases in a continuous replication environment, looking at the database on the active is the most accurate way to determine what the last backup is.

Another side effect is that, if the store is not running, you can’t backup the passive. Running the store is required so that backups can be coordinated and so the database header can be updated.

With log files being copied around and required by the Replication service, it becomes a little more complicated when it comes to getting rid of them. Right now the conventional way to get rid of log files is to run a backup. Backups runs, and on successful completion, it deletes the logs you don’t need any more.

The challenge now is that the definition of "need" is different because now it takes into account the state of replication. If a log file has not been copied, then you still need it (even though the store might not need it). So now a log file should not be deleted until (1) it isn’t needed for crash recovery, (2) it has been replayed on the passive, and (3) it has been backed up.

To coordinate all of this, whenever the Replication service finishes a replay, it contacts the store and says that it replayed storage group X up to Y generation number. At that point, the store knows that log files up to that generation number are no longer needed by the Replication service. It can then analyze the state of the last backup and the state of crash recovery and work out which log files are no longer needed on the active.

Fortunately, on the passive, things are a lot simpler. The passive can analyze its own log files and determine which ones are needed for recovery, and which ones are needed for backup.

Exchange 2007 – Disaster Recovery

December 13, 2006

This article outlines how to correctly back up Exchange 2007, restore Exchange 2007, and repair corrupt databases when no backups are available. These resources show how to prepare for disaster recovery, recover items and mailboxes from backup, and rebuild a destroyed Exchange 2003 Server. They also outline best practices for backing up your Exchange server and introduce alternate server recovery procedures.

More Infos here

Exchange 2007 – Disaster Recovery Planning Guide

December 13, 2006

Learn about basic Exchange Server disaster recovery strategies, using Exchange on a Windows cluster, recovering Exchange databases, and the new recovery features in Exchange Server 2007.

More Infos here

Free Secure Messaging Solution Advisor Now Available

December 13, 2006

The Solution Advisor is a tool that outlines a high-level Microsoft multi-layered solution for your infrastructure and messaging needs. The tool uses information you provide about such factors as company size, current messaging infrastructure, and the level of control you prefer over your messaging to create a customized response.

More infos here

Updated Exchange 2007 Tools

December 11, 2006

Die Exchange Tools wurden überarbeitet und haben dabei auch ein neues Facelifting bekommen. Einige davon sind bereits zum Download verfügbar, denke aber das innerhalb den nächsten Wochen neue Exchange 2007 Tools veröffentlich werden.

Weitere Informationen hier

Exchange 2007 und 64bit = Rock’n Roll

December 11, 2006

Die hier gemachten Aussagen sind keine Zusicherung von Funktionen, sondern beziehen sich auf öffentlich zugängliche Informationen zu einem noch nicht verfügbaren Produkte. Änderungen vorbehalten.

Exchange 2007 wird "NUR" auf 64bit Windows laufen.
Planen Sie daher heute schon bei der Beschaffung dafür.

Exchange 2003 hingegen läuft nur mit Windows 2003 32-bit.
Dies kann aber auch auf den meisten Systemen mit 64bit CPU installiert und betrieben werden.

64bit unterstützt keine "MS-DOS" und keine 16-bit Windows Anwendungen.

Nicht erst seit dem näher kommen des Itanium Prozessors rollt die Welle der 64bit Begeisterung. Nach der 8bit 6502/Z80 Welt und dem 16bit 8086/8088 hat uns die 32bit Welt lange Zeit gereicht. Allerdings ist mit 32bit nur maximal ein Hauptspeicher von 4 Gigabyte direkt adressierbar. Alles darüber muss wieder wie in alten DOS-Zeiten "eingeblendet" werden. Früher nannten wir was EMS Speicher, heute wird ein ähnliches Verfahren mit PAE (Physical Address Extension) genannt.

Letztlich entfesselt erst die 64bit Technik, wie sie mit dem Intel Itanium und den neuen AMD Prozessoren möglich wird, die Begrenzungen im Hauptspeicher. Und neben SQL ist Exchange ein wichtiger Kandidat für die Nutzung dieser neuen Möglichkeiten. Noch sind wir an den Anfängen der 64bit Stufe. Für die Nutzung der neuen Technik ist nämlich ein neu kompiliertes und angepasstes Betriebsystem erforderlich. Windows 2003 und Windows XP gibt es schon als 64bit Versionen, aber auch alle Treiber für Netzwerkkarten, Speichersubsysteme, Grafikkarten etc müssen für 64bit neu geschrieben werden. Es wird also sicher noch etwas dauern, bis die Server die gewünschte Stabilität und Performance erreichen können.

Warum 64bit ?

Die kurze Antwort ist: Alle die mit 2 GB RAM nicht mehr auskommen.

Natürlich können Sie sich die Frage stellen, wer denn jemals mehrere Terabyte Speicher brauchen wird. Aber die Fragen haben Sie sich schon zu den Zeiten eines ZX81 (8-16 kbyte RAM),  C64 (64-128kByte RAM) , IBM PC (256-640 KByte) gestellt und mittlerweile (Weihnachten 2005) werden selbst bei den Supermärkten die PCs mit 1 GByte Speicher verkauft.

Wenn Sie sich heute einen Server anschauen, dann gibt es ein paar Faktoren, die maßgeblich für die Performance sind.

  • CPU
    Die Steigerung der CPU-Taktrate hat sich verlangsamt, so dass heute andere Architekturen oder mehrere CPUs für die Skalierung benutzt werden. Aber wenn Sie ihre CPU-Belastung anschauen, dann sind die meisten modernen Server hier nicht nicht ausgelastet. Die CPU wartet oft auf andere Komponenten. Aber 64bit Register erlauben natürlich eine viel schnellere Berechnung von Werten und sorgen daher für höhere Geschwindigkeiten für solche Aufgaben.
  • RAM
    Der Speicher dient zur Ablage von Programmen und Daten. Was dort nicht enthalten ist, muss von langsameren Speichern nachgeladen werden. Viel RAM hilft daher, mehr Daten im Cache zu halten und damit die Zugriffe auf Festplatten zu reduzieren. Hier ist 64bit ein großer Fortschritt, da die 32-bit Technik bis 4 Gigabyte nur umständlich über PAE erreichen kann. Erinnern Sie sich an die Zeiten von Extended Memory (EMS) mit EMM386.EXE aus den DOS und Windows 3.x Zeiten? Zudem sind nicht einmal die 4 GB am Stück nutzbar, sondern entweder als 2GB System und 2 GB für Anwendungen oder als 1GB/3GB aufgeteilt (/3GB Schalter in den Boot.ini)
  • Netzwerk
    Daten müssen zwischen Servern übertragen werden. Fakt ist aber auch, dass selbst moderne Server nur sehr schwer wirklich eine 1 GBit-Verbindung bedienen können, da andere Faktoren (speziell Datenträger) hier als Flaschenhals wirken. Erst wenn die abgeforderten Daten überwiegend im Hauptspeicher liegen (Cache), kann das Netzwerk zum Engpass werden.
  • Speichersystem
    Festplatten nehmen zwar immer größere Kapazitäten an und höhere Umdrehungszahlen sorgen für höhere Datenraten, aber die immer erforderliche Positionierung sind Welten im Vergleich zu Zugriffen auf Hauptspeicher und CPU. Server werden schnell, wenn die Festplatten schnell werden (z.B.: viele Festplatte) oder wenn die Zugriffe darauf minimiert werden. Und das geht umso besser, je mehr Daten im RAM gehalten werden

Die Wichtige Antwort für 64bit ist daher "RAM RAM RAM". Viel RAM hilft den Servern von heute, viel mehr Daten im Hauptspeicher zu halten und damit die Belastung der Festplatten zu reduzieren und vor allem dort Reserven für erforderliche Zugriffe zu schaffen.

64bit Argumentation von Microsoft

Natürlich hat sich auch Microsoft einiges einfallen lassen, um den Wechsel nach 64bit zu erklären. Bedeutet es doch, dass bisher angeschaffte Server vielleicht nach einen Jahr nicht mehr genutzt werden können. Aber die Argumente sind dennoch passend.

  • Disk-I/O
    Wie schon weiter oben genannt hat Microsoft festgestellt, dass die Skalierung von Exchange auf heutiger Hardware mit 32bit durch der Leistung der Festplatten vorgegeben ist. Exchange 2007 soll durch bessere Nutzung von Hauptspeicher (Caching) die erforderliche I/O-Leistung um bis zu 75% reduzieren. Das bedeutet, dass Sie entweder einen sehr viel schnelleren Server erhalten (Was aber dank dem Outlook 2003 Cached Mode nicht mehr so wichtig ist), oder eben sehr viel mehr Postfächer (also bis zu 4 mal so viel) auf einem Server betreiben können. Das kommt dem Hosting und natürlich auch der Reduzierung von Servern in Firmen entgegen. Oder sie können einen "günstigeren" Server verwenden, da die I/O-Last nur noch 1/4 betragen soll. Hier muss aber natürlich das zukünftige Wachstum berücksichtigt werden, damit keine Milchmädchenrechnung draus wird.
  • Mehr Clients
    Die Zeiten, dass ein Anwender ab und an mal die Anwendung "Mail" gestartet hat, bzw. diese nutzt, sind endgültig vorbei. Vielmehr nutzen Anwender heute parallel sogar mehrere Zugänge auf das Postfach. Neben Outlook wird oft noch ein PDA oder BlackBerry repliziert (ActiveSync), Sharepoint oder Desktop Search erstellt Suchindexe und vieles mehr. Alle Verbindungen belegen "Speicher". Schon daher ist 64bit wieder ein Gewinn.
  • Sicherheit
    Sicherheit ist natürlich wichtig und schon Exchange 32bit hat umfangreiche Zugriffssteuerungslisten (ACLs). Hierzu werden oft Sicherheitsgruppen verwendet, die auch verschachtelt sind. Dies belegt Kernel-Speicher. Angeblich wäre das ein Grund für mehr Server, um die Berechtigungen feiner zu vergeben, was mit 64bit ebenfalls gelöst wäre.
    Dieser Argumentation kann ich mich aktuell noch nicht anschließen, aber vielleicht weiß Microsoft hier schon mehr als wir alle.
  • Größere Postfächer
    Dieses Argument zieht aber wieder, da Sie als verantwortlicher Administrator oder Geschäftsführer es nicht zulassen sollten, dass Nachrichten in lokalen PST-Dateien ausgelagert werden müssen. Das Postfach und eine serverbasierte Archivierung ist der besser Platz dafür. Allerdings bedeutet das eben auch größere Postfächer. Hier kann 64bit helfen, da eben mehr Speicher adressiert werden kann (Cache) und bis zu 50 Datenbanken eingerichtet werden können.
  • Speicherbedarf
    Angeblich machen die Kosten für den "Storage" eines Servers bis zu 80% der Gesamtkosten aus. Und dabei ist das Problem, dass Sie zwar heute 100 GB und mehr an Festplattenkapazität kaufen und installieren können, aber die meisten Administratoren doch ein mulmiges Gefühl haben, wenn die EDB-Datenbank dann mal über 25 GByte anwächst. Denken Sie nur an die Wiederherstellung oder einen Einsatz von ESEUTIL. Daher nutzen die meisten Administratoren gar nicht diese Kapazitäten. Das wird mit 64bit (genauer: den 50 Datenbanken) natürlich einfacher

Sie sehen also, dass es viele Argumente für den Umstieg auf Exchange 2007 geben wird, von denen aber nur einige direkt mit 64bit zu tun haben, sondern auch neue Funktionen von Exchange 2007 zählen.

64bit für Alle ?

Sicher wird es auch Desktops mit  64bit CPUs geben, aber da auch die Treiber darauf abgestimmt werden müssen. Daher erwarte ich nicht, dass sehr viele Endanwender (mal von Freaks abgesehen) gleich auch die 64bit Version von Windows XP oder Windows 2003 installieren werden. Oftmals erlauben die 64bit CPUs auch den Betrieb mit einem 32-bit Betriebssystem, wenngleich dann nicht alle Leistungsreserven genutzt werden können.

Aber für Server stellt sich das Bild komplett anders dar. Für Hersteller von Servern und passenden Adaptern lohnt sich sehr wohl die Entwicklung von 64bit Treibern, so dass es sehr schnell nicht nur entsprechende Hardware mit Treibern, sondern auch entsprechende Installationen geben wird. Hier sehen ich folgende Dienste als erste Server:

  • SQL 2005
    Es ist nicht verwunderlich, dass gerade großen Datenbankserver von 64bit und besonders der damit möglichen großen Hauptspeicherausstattung profitieren. Da diese Server zugleich immer sehr "wichtig" sind und auch Performance ein Thema ist, dürften die meisten 64bit Systeme daher eben Datenbankserver werden
  • Domaincontroller
    Stellen Sie sich vor, ihr Active Directory enthält so viele Objekte (Speziell auf GCs größerer Firmen), dass es nicht mehr in den Speicher passt. Damit verschlechtert sich die Performance des DC natürlich sehr stark. Es kann daher hilfreich sein, einen DC mit ausreichend Speicher auszustatten, so dass die komplette NTDS-Datenbank im Speicher ist. Es gibt Berichte, dass solche ein "Super-DC" problemlos die Last von mehreren 32-bit DCs übernehmen kann.
  • Terminal Server
    Aktuell gibt es noch sehr wenige Anwendungen für 64bit, aber gerade Terminal Server haben oft das Problem, dass die 2 GByte für das System eine erreichbare Grenze darstellen. Der Betrieb mit Windows 64bit hebt diese Grenze an. Der Zusätzliche Speicher wird ebenfalls eine weitere Skalierung zulassen.
  • Exchange
    Zwar können Sie Exchange 2003 auf einem 64bit System betreiben, aber Sie müssen dazu weiterhin die 32-bit Version von Windows einsetzen und haben daher keinen Vorteil. Erst Exchange 2007 wird 64bit unterstützen. Das sollte Sie aber nicht daran hindern, bei der Neubeschaffung gleich ein 64bit System zu kaufen, so dass in naher Zukunft da Update möglich ist.

Weitere Links

Es gibt noch einige andere Seiten, die über Exchange 2007 spekulieren bzw. offizielle Informationen bereit stellen

Source: MSXFAQ.DE – E2007:64-bit

Exchange 5.5 to Exchange 2007 mailbox migration

December 1, 2006

Migrating mailboxes from Exchange 5.5 to Exchange Server 2007 directly is not supported. Using native tools, administrators will have to perform this kind of migration as a two-step process which includes:

  1. Migrating from Exchange 5.5 to Exchange 2003
  2. Migrating from Exchange 2003 to Exchange 2007

Typically, there will be two scenarios:

Scenario 1: Exchange 5.5 and Exchange 2003 are in same Organization; Exchange 2007 is in a different Organization

Here is the brief description of typical steps and related information:

– In Exchange 2003 / 5.5 Organization

1. Exchange Server 2003 Migration Wizard doesn’t allow migration from an Exchange 5.5 in the same organization.

2. You should verify that Active Directory Connector is installed on Exchange 5.5 machine and replication service is configured with correct credentials and with correct port. You can do this by going to Start > Programs > Microsoft Exchange > Active Directory Connector. Change to port for Exchange Server to 389 if it is set to something else.

3. You can wait for replication or you can select replicate now in Active Directory Connector (especially if Exchange 2003 in newly configured in this organization).

4. Once you can see all the users with mailbox information in Exchange 2003 machine, you are ready for migration to Exchange 2007.

– In E2007 Organization

1. Verify that there is a trust between these two organizations.

2. You need to have Administrative privileges in the other organization.

3. You cannot do Cross-Org migration using the GUI wizard. You have to use Exchange Power-Shell.

4. Open Exchange Power Shell and enter $s=get-Credential. Enter the Administrator account and password of the other organization. This credential information would be saved in variable “s”.

5. Then to transfer a mailbox, you can use the following command
Move-Mailbox -identity <username> -sourceForestGlobalCatalog <e2k3server> -targetDatabase <Target MBD > -sourceForestCredential $s -NTAccountOU Users.

6. If this command gives some error, verify that Exchange information store service and Exchange System Attendant Service is running.

Scenario 2: Exchange 5.5 is one organization; Exchange 2003 and Exchange 2007 are in a different Organization.

Verify that there is a trust between these two organizations. This one is easier and it can be done using GUI wizards.

– In Exchange 5.5 Organization

1. In Exchange 5.5, you should go to Exchange Administrator Console and verify that the port for LDAP is set to 389 in Protocols.

– In Exchange 2003 and Exchange 2007 Organization

1. On Exchange 2003, run the Migration Wizard. Move the selected user mailboxes to Exchange 2003 server using Migration Wizard.

2. On Exchange 2007, run the Migration Wizard to move mailboxes to Exchange 2007.

Conclusion

1. Users with moved mailboxes will still use OldOrg\UserName to login and check their emails as their login credentials are still in the previous organization.

2. Users will appear as disabled users in Exchange 2007 machines.

Note: ISV tools are available to help in this kind of migration, including ‘Quest Migration Manager for Exchange’ that can aid in Exchange 5.5 to Exchange 2007 migrations and archiving tools such as ‘CommVault QiNetix’ that can archive Exchange 5.5 content and restore to Exchange 2007. Other tools might be available too. This blog posts covers what can be done with native Microsoft Exchange tools only.

(Quelle : MS Exchange Team Blog)