Getting Used to the Shell
PowerShell previously code-named Monad is a powerful command-line and scripting interface that provides a single way to automate management operations on the Windows platform. Microsoft has taken the opportunity to clean up the horrible mess of APIs (not all of which are fully documented or even publicly documented) that it has used in previous versions of Exchange to perform management activities. For example, on Exchange 2003 and Exchange 2000 servers, you had to use a mixture of APIs to automate management operations. In an Exchange 2007 environment, you drop all the old APIs and use a set of PowerShell cmdlets. (Pronounced command-lets, cmdlets are prepackaged commands for performing specific functions, such as creating a new mailbox.) In fact, Microsoft built the Exchange 2007 management framework, including the new version of the Exchange System Manager console (called the Exchange 2007 Management Console), from PowerShell cmdlets.
You don't have to wait for Exchange 2007 to learn PowerShell: It's available for Windows 2003 today. You might not be able to manage Exchange servers, but you'll be able to learn the language and learn how to create scripts that get real work done. When you install Exchange 2007 on a server, the installation procedure adds all the new Power-Shell verbs to work with Exchange and you can then upgrade your knowledge to work with Exchange. For more information about PowerShell, see the Learning Path.
Preparing on Other Fronts
Apart from the software products that obviously support Exchange, such as antivirus packages, there are new versions of other products that you might need to take into account as you plan your Exchange 2007 deployment. For example, Microsoft is about to release Office 2007, which includes a new version of Outlook. You need to test Outlook 2007 to justify the upgrade and deployment costs. The feature I like best about Outlook 2007 is the client's ability to use an Exchange-provided Web service called AutoDiscovery to consult AD to find out which server a user's mailbox is located on—thereby reducing the potential for error when users set up Outlook.
Many companies consider Microsoft SharePoint Portal Server as the natural replacement for Exchange public folders, which Microsoft plans to phase out in the next major release of Exchange following Exchange 2007—perhaps three or four years from now. One forward-thinking pointer is that the Exchange 2007 Management Console offers no way to manage public folders; you have to manage them through PowerShell or with an Exchange 2003 server. So now is the time to figure out your replacement strategy for public folders. A new SharePoint version is on the horizon, so should you incorporate this release and an upgrade for SQL Server, which provides the database for Share-Point, into your overall server upgrade and refresh plan? Perhaps you've deployed Live Communication Server—something else to consider.
My point is that the Exchange ecosystem is more than just the products that are immediately associated with messaging. To ensure that all the necessary moving parts mesh together, you need to take a holistic approach to your Exchange 2007 upgrade project.
Training
Even if have 10 years Exchange experience, you'll find that Exchange 2007 has a significant learning curve. The introduction of PowerShell and its power scripting capabilities brings a lot to the table, but so does tuning the 64-bit platform, ensuring that routing works well across your Windows sites, learning how best to coexist with legacy Exchange servers, coordinating upgrades in large organizations, and so on. I recommend signing up for the Exchange 2007 beta and deploying it on some servers, just to play with some of the new features, such as the scheduling assistant (a feature that should have been in Exchange a long time ago). For information about obtaining the beta release, see the Learning Path.
Even if you devote some time to playing with the Exchange 2007 beta, some training will be necessary, so be sure to sign up for some classes or attend some conferences to upgrade your knowledge, learn about best practice, and share your experience with other administrators.
Just Do It
Since 1996, Microsoft has released new versions of Exchange every few years, so dealing with an upgrade isn't a new challenge. Every upgrade has its quirks. The major changes in Exchange 2007 are its move to the 64-bit platform, the change to the routing subsystem, and a new scripting and management automation capability. The new Unified Messaging (UM) capability might also be an attractive selling point, as I discuss in the sidebar, "Talking with Exchange UM." As long as you're prepared for the upgrade, Exchange 2007 will be a straightforward installation—and now is a great time to start.
End of Article
