Keeping up with technology is what causes headaches for most people these days. Most companies hesitate to migrate to a newer software release, especially if back-end servers are involved. There's a good reason for that. In this article we will try to explain what such a migration involves. This is not just another software update, because lots of employees rely on Exchange Server.
Often, when major server roles are about to be migrated, specific steps must be taken. The first is requirements management, analyzing the costs and whether the upgrade benefits the company and your specific environment. Newer software tends to bring improvements, security enhancements, and new goodies to the table, but it's doubtful that everyone really needs those additions or can afford them.
Once the previous step is done and the results are positive, then the next step is migration planning. The people that are responsible for the task(s) are looking into the situation: finding out what it involves, how it's possible for their environment, and actually scheduling the task and setting up deadlines. It is generally recommended that you set up a "test" environment where the migration is done-so it doesn't directly affect your employees.
Of course, it need not be mentioned that backing up your current setup can be a life-saver. Once this is done and the migration succeeds within the test domain (either via test physical machines set up in an isolated environment-usually called as a lab- to simulate "tougher" administration tasks, or simply relying on virtualization approaches), the migration can be carried out on the real environment.
Whenever possible, you should always opt for a "coexistence" kind of migration. This way there won't be any down time, which means you will not be required to work overtime/during the night, nor will employees be affected by your maintenance actions. Additionally, when or rather if things go wrong, you can always roll back and use your already-existing working solution. If done well, coexisting migrations are harmless.
Having said this, throughout this article we will discuss how to migrate in such a coexistence setup with either Exchange Server 2003 or 2000. Let's begin.
The first thing we need to understand is what coexistence means. It is basically a state when there are two Exchange Servers within an environment, say Exchange 2003 and Server 2007. Coexistence is interoperability. The other key differences between the newer and older versions of Exchange Server concern its management tools.
Exchange Server 2007 comes with a set of management tools that do offer some sort of backward compatibility. But to easily remember, the rule of thumb should be like managing the appropriate mailboxes with their management tools. For example, you should not manage mailboxes belonging to Exchange 2007 with old-fashioned 2003 tools. This means the way you "work with" mailboxes changes slightly.
With Exchange 2003 you've been accustomed to managing your mailboxes with the MMC snap-in extension for the ADUC (Active Directory Users & Computers). Every time you right-clicked a user, there you could find the Exchange-related tabs. During the coexistence state, those will not disappear, but they cannot edit/manage properly Exchange 2007 mailboxes.
And once Exchange Server 2007 is set up, don't look for a renowned version of that MMC snap-in extension. The way you manage mailboxes has changed. Now you're given two options: either via management console (GUI-based) or via shell (text). You can also find plenty of tools from Microsoft, but always double-check which kind of Exchange mailboxes they are written for.
Earlier we've mentioned backwards compatibility regarding tools. Most of the tools written for Exchange 2007 mailboxes can manage older mailboxes (2003), except for creating them. But if you're migrating, you won't need to create any new mailboxes on the old platform. During the coexistence state, certain configurations are considered global and, therefore, are shared between both versions.
Our advice is keeping the coexistence state only as a backup, and once you've done the migration and the new platform works as expected, you don't need to maintain co-existence anymore. You can remove the old Exchange server to alleviate system resources and clean up the clutter.
In the case of an Exchange migration, coexistence is the only option, since a direct upgrade is not possible. The process requires you to set up another Exchange Server, of the new version (2007) within the organization. After that you can move the mailboxes and server roles. Moreover, if you check the change-log of Exchange 2007, you'll find out that the Hub Transport Server role has become the main role that handles communication.
On earlier versions you could install an Exchange server without that role. Things have changed, since the architecture of Exchange 2007 is different. Right now communication between Exchange servers happens on the RPC topology, unlike SMTP as it did in earlier versions. Since RPC is handled by the Hub Transport Server role, this makes it required.
Exchange 2007 makes the following server roles available: the Hub Transport Server role that we discussed above, the Mailbox Server role (this role hosts the mailboxes), the Client Access Server role (this one enhances the accessibility of the server by providing more protocol types, such as POP3/IMAP4, does the OWA, and so forth), the Unified Message Server role (VoIP and IP-PBX capabilities), and Edge Transport (enhances security).
Please read the official documentation regarding these server roles to decide which are necessary for your custom scenario. One of the typical setups involves installing 3 roles: Mailbox Role, Hub Transport, and Client Access. These can be installed on the same physical machine. The same goes for Unified Messaging if you really need those telephone-related capabilities. However, the Edge Transport role needs to be alone as a server role.
Now that we know what we're dealing with-let's get to it!
As always, we need to prepare the server for the new application by installing its requirements if they aren't present already. In short, you need .NET Framework 2.0, MMC 3.0 version, and Windows Powershell. The latter is not installed by default; the other two might already be installed if your server is up-to-date with the latest patches.
ServerManagerCmd -i PowerShell
The above command sets up Powershell. Execute it from a command-line console. Moreover, you also need to have the IIS prerequisites:
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
And finally for Outlook Web Access and Anywhere function, you also need this:
ServerManagerCmd -i RPC-over-HTTP-proxy
Once the preliminary steps are done it's time to begin installing Exchange Server 2007. You can opt for console-based installation or just launch Setup and follow the install instructions. It's up to your preference. The most important step you should be careful about in the case of co-existence is at the "Mail Flow Settings." You need to select your existing Exchange server towards which the routing connector is set up.
On the UI-base installs you just "Browse" for it; chances are you will only have one option for the bridgehead server (e.g.; Exch2003Bridgehead). The other steps are self-explanatory and should not create problems. If you opt for an unattended installation, then you can run the command as seen below:
setup /pl:ourfirm.com (updates legacy perms.)
setup /ps (updates AD schema)
setup /Preparead (updates organization)
And the following command automates the entire installation procedure:
You may eventually want to add /OrganizationName:ourfirm to specify the OU.
Once the setup is finished you will have some Finalize Deployment tasks to do. You can read the official documentation regarding these. In short, you need to set up such things as SSL, Offline Address Books, and the mail flow for the Hub Transport Server role. The latter step is what actually points out where mails should flow; likewise, this is the place where setting up Receive/Send connectors is possible.
The key that manages the communication between your two coexisting Exchange servers is the routing group connector. If you've specified your other Exchange server appropriately during the setup, then the bi-directional (two-way) routing connector should be created automatically. To get a deeper understanding of routing group connectors, please check out the following detailed blog post: link.
Active Directory Migration Tool, abbreviated ADMT, is a set of tools that helps system administrators to accomplish a variety of tasks when migrating AD-specific and Exchange components, and many others. This can be used when you want to move mailboxes as well. The usual methodology whenever doing entire migrations is first migrating the users (using ADMT) and then moving the mailboxes (move-mailbox).
Currently, the latest version of ADMT is v3.1 and it supports Microsoft Windows Server 2008. Make sure you're using the right version; it's more feature-laden. Moreover, the extensive documentation of ADMT is hundreds of pages long, and it covers most migration situations; be sure to search for what you need.
This is necessary if you're opting for a different transition procedure, like creating a new domain and installing Exchange Server 2007 there. Then you also want to move the users first, preserving their SIDs (it creates the accounts in the new domain while keeping their SID history), and then moving the mailboxes to the new Exchange server.
Once the move mailbox process finishes, the legacy mailboxes will be part of the new Exchange Server database only. Outlook Express (2003/2007) and Office Outlook can automatically update the HomeMDB tags so that it reflects the changes regarding the mailbox database. This change won't have a direct effect on users.
One final pointer before we finish: the Public Folderdata can be seamlessly cloned using replicas between the coexisting Exchange servers; however, please do remember that by using OWA you will not be able to access Public folders. But in the case of "legacy" mailboxes, neither OWA nor the other protocols lead by Hub Transport will have issues. The users will be able to access their mailboxes through whichever way they choose.
As you can see, we're quickly running out of space. Our final reminder regarding the entire migration procedure is: please don't skimp om reading the official Migration Manual. It's really extensive and covers most situations, as well as the pitfalls that you may run into. Also, don't hesitate to ask for help on forums and message boards. As another resource, there's the official Microsoft Exchange Team's blog.
There are various Powershell-based Commandlets that you can use to manage your mailboxes, do other Exchange-specific tasks, and so forth. Over time, chances are you will find out how flexible and modular Exchange Server 2007 really is. In addition, it is also highly scalable, in the case of larger corporations where thousands of mailboxes are involved-deploying different roles per server(s) is amazing so the load is balanced.
All together, we'd advise doing extensive research on whether the new Exchange Server is worthwhile for your company and its proprietary environment. And if so, by all means, it is something that will pay off in the future, even if it might require a few hours of extra research. Via the coexistence strategy, you can migrate without down time.
The process in itself is pretty straightforward. The only tricky part might be to truly understand everything related to routing connectors. This is necessary, especially if more than one legacy Exchange server is maintained in coexistence. If you opt for the Edge Transport Server role, then this can also become tougher to configure. As mentioned earlier, however, it "just" adds to the complexity but improves security-this might be not only advised, but required in the case of large businesses.
That's all for now; I hope you found this article informative.
In closing, I'd like to invite you to join our experienced community of technology professionals on all areas of IT&C starting from software and hardware up to consumer electronics at Dev Hardware Forums. Also, be sure to check out the community of our sister site at Dev Shed Forums. We are friendly and we'll do our best to help you.
Extracting Google-Indexed Web Site Pages Using MS Excel
