Exchange 2010 - what can we work on now?

Time for a design and planning article on something I spend a lot of time talking to customers about. Planning for migrations and change in their Exchange organizations. With the recent news about Exchange 2010 being code complete and released to manufacturing (which is a silly term now IMO) they will RTW - release to web via TechNet, MSDN, and eventually general availability. Unfortunately we don't have dates for when on any of those yet, but early November is when they predict the general availability. It is safe to assume that TN, MSDN, and MSVL customers might have it before then.

So that's within the next 30 days. If you are on a previous version of Exchange and you know you want to go to Exchange 2010, what can you work on to help make sure you can get there as soon as possible?

Examine your AD
Exchange 2010 requires that the forest and domain functional levels are Windows 2003. If you have an old 2000 DC still ticking, it's time to work out migration and decommission plans for it. If some of the high availability DAG features are what you are hoping to implement with Exchange 2010, this is the time to ensure that you have domain controllers in the sites where you intend to have DAG members. For fault tolerance, I recommend two DC's in those sites, but the MS requirement is one.

Examine your integrated applications
When Exchange 2007 released, I was very busy migrating customers and in the first few months after the release, the biggest thing holding up projects was waiting for third party vendors to get their software compatible. As I mentioned above, the MSDN release is when many of those vendors gain access to the software and can begin working on new code. For most people, the list of things that integrate includes backups, Anti-virus, Anti-Spam, blackberry, archiving, faxing, and voicemail delivery. While you are waiting for vendors to release new versions or patches to support Exchange 2010 (and Windows 2008 R2 as well, since many integrate to the OS/IIS quite a bit as well) you can still begin Exchange 2010 installation upon release and migrate some groups of users who don't require those third party apps.

Some third party integrations such as archiving, faxing, and voicemail, can remain integrated to Exchange 2000/2003/2007 and allow your legacy server to pass the message to the mailboxes on Exchange 2010.

The major gotcha is always backups. When Exchange 2007 RTM'd there was no included backup utility, and this prevented several migrations from moving forward. In Exchange 2007 and SP2, we can now backup with the Windows Server Backup utility. While this may not be the application of choice if you spent a lot of money on another solution, it is a very good workaround in the meantime until vendor support comes. And as always, please don't move production data to a server you cannot back up properly!

Confirm your licensing
This is likely the biggest and most important one. If you have not yet deployed a Windows 2008 server on your network, you will likely need to upgrade your CALs (Client Access Licenses) to 2008. For some organizations, this can be a fairly large budget item. In addition, check if you purchased Exchange 2007 and CALs recently with Software Assurance, you may have upgrade rights already. Also, on the client side - Outlook 2003 and 2007 will both still work with Exchange 2010, but purchasing Office 2007 now with software assurance will also allow upgrade rights to Office 2010 when that releases.

Begin hardware planning NOW
At a bare minimum, you know your user counts, your server count and your disk usage needs. You can use Microsoft TechNet to find planning guides. There is no storage calculator announced or released at this time, so if you have a larger infrastructure, this planning is still a little difficult, but using the guides and over planning a little bit should be enough to at least start to ballpark your server counts and budget needs for your migration.