Introducing Microsoft Exchange 2010 in Visual C#.NET

Creator QR Code ISO/IEC18004 in Visual C#.NET Introducing Microsoft Exchange 2010

1

Will you use Unified Messaging (including integration with other Microsoft products such as Office Communications Server) Is better high availability required Will you use archiving and compliance

The need to upgrade other applications, including rewriting code that depends on now unsupported APIs such as Web Distributed Authoring and Versioning (WebDAV), could cause difficulty. There is also a need to test third-party applications that integrate with Exchange or wait for vendors to release new versions of their applications that are certified to work with Exchange 2010. A new version of Outlook must be deployed to take full advantage of the features of Exchange 2010.

Microsoft s Business Productivity Online Suite (BPOS) includes the option to run a hybrid model, where some mailboxes are supported on classic on-premise servers and some run in the cloud. Moving to the cloud seems like a simple decision, but considerable complexity lurks under the surface. A different email platform might be selected, although this introduces additional work items in terms of platform selection, clients, and migration.

After you understand the full context of your current situation and know what the motivation is to deploy Exchange 2010, you can proceed to the planning phase.

Microsoft chose not to engineer the code to allow administrators to upgrade a server from Exchange Server 2003 to Exchange Server 2007, and they have gone along the same route for Exchange 2010. The logic was that it is just too difficult to create software that can perform a reliable upgrade from a 32-bit platform of Windows Server 2003 and Exchange Server 2003 to a 64-bit platform of Windows Server 2003 and Exchange Server 2007, even if Windows and Exchange run the latest service pack. There are just too many edge cases that Microsoft won t know about until they are encountered in the field. All of the

Exchange code base and associated products such as Microsoft ForeFront run on the 64-bit platform today, so that s not the major engineering concern. The problem now is how to accomplish a dual in-place upgrade of operating system and mail server to get to the desired Windows 2008/Exchange 2010 configuration. This is far less of a problem than when the underlying platform changes, as in the case of going from a 32-bit to a 64-bit platform, but it still would require substantial engineering effort to write and then test the code to perform a complete upgrade. Microsoft s view is that the experience of Exchange Server 2007 deployments proved that it is far easier to introduce new servers and move mailboxes to those servers when you are ready. Such an approach avoids the need to perform in-place database upgrades that would otherwise be required to support the database schema changes such as the major upgrade applied in Exchange 2010. It also eliminates the need to test the installation (setup) program to make sure that it can accommodate the multitude of scenarios that Exchange is deployed into for production. 1

The problem with in-place database upgrades is that they are usually slow because every page in the database has to be processed to upgrade it to a new version . The need to process databases introduces a period of vulnerability during the installation process . For example, if your server supports a mailbox database of 100 GB and the data can be upgraded at the rate of 10 GB/hour, you can look forward to a 10-hour period during the installation when the server is fully occupied with the database upgrade . Not only must this processing occur when all users are blocked from using their mailboxes, but if anything happens during the upgrade, you ll have to restart after you fix the problem . Building this kind of data upgrade into upgrades introduces too much risk . From an engineering perspective, it is far better to require customers to install new servers with clean databases and then gradually move users over to the new platform . Although the no upgrade approach means that new servers are required for Exchange 2010, it might be possible to align the upgrade with a hardware refresh cycle or to reuse some older servers .

!

Although customers might incur some extra cost to achieve the upgrade, Microsoft will argue that the time they save from not having to figure out how to make in-place upgrades work (even partially) allows their engineering teams to dedicate time to solving other problems, such as making mailbox moves work more efficiently (which occurs in Exchange 2010), improving the quality and features of the installation program, and upgrading tools such as the Exchange Best Practice Analyzer to help administrators understand any issues that might exist in their infrastructure that must be resolved before an Exchange 2010