Exchange 2010 co-existence with Exchange 2003 - a list

To start: Well I must congratulate the Microsoft team on a super, slinky, simple yet powerful and elegant product - Exchange 2010.

Have deployed the product a few times for a handful of customers and the demand is growing as the good news spreads - i believe! However there are many considerations and prerequisites to keep in mind for a successful implementation, and many customers do not (or don't want) a "Big Bang" approach to moving to Exchange 2010.

So, I thought - for my very first ever blog in my 15 years of working as an IT professional - I would put a little list which I have gathered through the journey.

Before you start:

• Reproduce your currect Exchange 2003 / AD environment in an isolated test lab. This will require you to get hold of some hardware(Use a hyper-visor product! VMware,Hyper-V etc), and of course will require time as you reconfigure certain aspects of the infrastructure that you do not bring into the lab. The times that I have found oddities - especially customisations to environments - in the lab has saved time (and grey hairs) and also prevented uneccessary "tweaking & fiddling" in the production environment. Everyone talks about this step - people seldom really do it.
• Size Server Correctly - there are more than enough tools and whitepapers to help you through this, the MSExchange Team's blog has a super calculator which you can download. Be sure to get a good sample of past mail traffic statistics. Further to this, refer to Microsoft's Technet Library on Exchange 2010 and review each Server role's sizing requirements.
• Understand port requirements - we always seem to scamble around for this - well scramble no more - have a look at this list for all the ports needed (it's a short list)
• Prerequisites ensure that you have these at hand BEFORE you start - and see that you deploy the hotfixes after .Net :-) find a list here
• Clean up DNS - DNS is vital to the health of Active Directory and Exchange, ensure that old records are cleaned out and that records which should be there are there!                                                                                                                  I have very often found records for domain controllers advertising services in a site to which they do not belong to - unintentionally causing clients to authenticate over links which they shouldnt be. Use DCDIAG /test:DNS ; and also DNSLint to check over the health. Another common "eek" is broken delegation errors - found with DCDIAG, which often are due to erroneous creation of DNS zones (mycompany.com.mycompany.com for example) Get rid of these...but if you find there are real broken delegation issues - refer to Microsoft's Technet Library on DNS
• Check Replication Replmon days are gone, get used to repadmin; in this case to start use repadmin /replsummary  as a starting point.
• AD Check Site Configuration in AD Exchange 2010 no longer uses Routing Groups - it is entirely dependant on Active Directory site. Ensure that subnet to site assignments are correct!
• Run the Exchange Pre-Deployment Analyzer Download Here
• Obtain Unified Messaging /SAN (Subject Alternative Name) certificates for Client Access functions
• Ensure that Permissions are correct in Active Directory - this is usually done automatically with the Exchange Setup process, however I feel better about manually executing the tasks to ensure that they are done,  especially when you expect to co-exist for a while. [Thanks Nicolas! ;-) ]

Some problems I have encountered:

• PowerShell site has missing modules
• Here one isnt able to start the Exchange Management Console, or connect to the new server using the EMS.
• When you inspect the PowerShell site's modules it's found that the kerauth and WSMan modules are either incomplete or missing
• Refer to the Exchange Team's Blog Article for details on repairing this.
• New Exchange 2010 servers will not initiate (Initialization failed - No Exchange Servers are available in any AD sites)
• Find MSADAccess 2808 in event log - this is the crux of the error and ultimately the main smoking gun. The event log refers to the SACL's for the DC's being unable to read certain attributes - which i *think* is specifically Read to nTSecurityDescriptor
• Refer to this blog to see what the SACL's should look like (which incedentally also refers to the issue I am speaking of here ;-)
• MSEXCHANGETOPOLOGYSERVICE Topology discovery failed, DSC_E_NO_SUITABLE_CDC
• This one really had me going - I am fairly sure I read the entire internet ;-) but found similar problems and LOTS of solutions - of which none worked for me. Here is a list of all the suggestions:
• Install WinRM for IIS on the Windows 2008 R2 server (made zip.zero.nada difference)
• Enable IPV6 (made no diffs if i had it manually enabled, or disabled - partially or fully)
• Ensure that the Exchange computer accounts are members of "Exchange Servers" group in AD (I found Exchange 2010 SP1 did this during install)
• The solution that I ended up being able to repeat on all the servers was, before installing the server, adding it's computer account to the Exchange 2003 created Exchange Domain Servers group.

Lastly:

• Learn how to use PowerShell! it's scary, it's powerful, its the foundation of Exchange 2010 management....and pretty much everything else soon! :-)
• Read books! Some of my favourites are Exchange 2010 Best Practices (MS Press) ; Exchange 2010 - A practical Approach(ISBN: 978-1-906434-31-1); and Exchange 2010 Administrator's Pocket Consultant (MSPress).

Ok - well that's it for now- will update and add as time permits :-)
Toodles!