Vendor Management Strategies for the CIOMicrosoft has been pushing hard for existing Exchange customers for an Exchange Server 2007 upgrade for a variety of reasons—many more features, for one, but mainly Exchange 2007's 64-bit-only incarnation.
64-bitness on Exchange did away with many arbitrary limitations—many of which certainly hemmed in ISVs and resellers of Exchange services. For those reasons alone, a 2007 Exchange upgrade is at the least a really good idea: it means that many less limits on what you can offer your customers, and what you can offer yourself.
In the course of this article I'll talk about making the jump to Exchange 2007 from the ISV's point of view, and break things down into two basic categories—new and existing Exchange customers.
New Exchange 2007 customers
"New," in this case, doesn't just mean a customer who's new to Exchange—it can also mean that you're a resller who is new to Exchange. If you've decided to start offering Exchange 2007 as one of the services in your package of goodies, obviously don't make your customers the guinea pigs: you should have a good grip on deploying Exchange 2007 long before you ever offer it to anyone.
Requires Membership to View
To gain access to this and all member only content, please provide the following information:
By submitting your registration information to SearchSystemsChannel.com you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here
- Your use of SearchSystemsChannel.com is governed by our Terms of Use
- We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
- If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.
 |
||||
|
|
|||
|
||||
The best place to start is to look into products that can make the hosting process simpler. Hosted Exchange 2007 Solution from DotNetPanel is one such product: it allows you create multiple virtual Exchange organizations, each with their own Global Address List, Offline Address Book and accounts databases. The product also includes a slew of reseller-specific options—disk space limits, allowed protocol types, and reseller-level policies for each Exchange domain. The whole package is available for about $2,490 per server—not per Exchange server, but servers where the HES product is actually running—along with custom price quotes. I should also mention the PEM Solution for Hosted Exchange, although right only it only supports 2003 and not 2007.
A more generic, all-encompassing solution is H-Sphere from Sitive Software, which covers multiple server platforms and products. This makes sense if you're offering Exchange as one of a bundle of possible server items, although Exchange server support is not enabled by default and has to be added manually.
Existing Exchange customers
Migrating existing Exchange customers from 2003 to 2007 can be summed up in two words: Be careful. Wherever and however you can, make sure that customers are in the loop at all times—that they know what stage of the migration they're at, what kind of work will be involved to get them moved over, and how long they are likely to remain in transition. Migrating from Exchange 2003 to 2007 makes it possible to keep things running during the transition, so it's typically possible to migrate without incurring a lot of downtime.
One thing you'll want to have in hand is live usage statistics for your customers, compiled over a couple of months. This will give you the best possible idea of when to do things like physically move mailboxes between Exchange systems so the least amount of impact on users is incurred. For instance, if you have a given customer who has the majority of their workforce in other time zones, you'll need to respect that whenever possible.
The above-linked article is a key Microsoft document on how to make the transition to 2007 as seamlessly as possible, and also references several other documents—among them information about how to move between single or multiple forests. You'll want to get to know this material intimately depending on how your Exchange offerings are assembled, since no two resellers have similar configurations.
I also strongly recommend these notes from the MS Exchange Team's blog, which talk about things like logging (you can now generate XML reports from mailbox move actions), prevalidation, the various ways the mailbox movements can be accomplished, and so on. (Using PowerShell to script as much of the move as possible and make it an automatic process is strongly recommended.) Also be wary of any circumstances in the new Exchange 2007 setup that might break single-instance storage when you move. If you're reselling Exchange with fixed storage caps, breaking SIS may cause the amount of space taken up by your customers' data to increase dramatically—much to their chagrin as well as yours.
This was first published in July 2007