Killer Exchange 2010 session at TechED 2010

This week I’m at TechED 2010 in New Orleans, and as part of the conference package I signed up for a pre-conference session on Exchange Server 2010. This was an eight hour session on Sunday covering a whole gamut of Exchange 2010 topics. The two presenters actually wrote a book, called Mastering Exchange Server 2010. The session was packed with good information, and I ended up taking five pages of notes. I won’t cover all of my notes in this post, but I will highlight some of the most important details that I gleaned from the session.

– Prior to starting the Exchange 2010 migration you can use tools such as Winroute to evaluate and document mailflow.

– To better understand your user workloads for Exchange 2003 and 2007 servers, you can use the Exchange profile analyzer.

– Microsoft has the Exchange 2010 Deployment assistant to help guide you through various migration and deployment scenarios.

– You can also use the online Microsoft Exchange connectivity tool to verify external access to various Exchange services such as Active Sync, autodiscover, and other features.

– Recommended base operating system for all Exchange roles is Windows Server 2008 R2.

– If an Exchange server is part of a DAG (Database availability Group), it is recommended it have two NICs. One for MAPI connections and the other for the database replication. The two NICs must be on different subnets and must be fully routed between all DAG members.

– You can configure a ‘lag’ copy of an Exchange database, say 24 hours, but you should only do so when you have three or more copies of the database.

– The maximum latency between servers in the same DAG is approximately 250ms.

– When using DAGs, the file share witness (FSW) can be hosted on any server you wish. But the AD group “Exchange Trusted Subsystem” must be a member of the local administrator’s group on the FSW server. For this reason, you shouldn’t host a FSW on a domain controller since you would need to use the domain admin group. Always use a member server.

– All DAG members must have the same drive letters and paths for the databases and log files.

– You should always configure a CAS array, even if you just have one CAS server. This will allow for easier future expansion. A CAS array is also required for software or hardware load balancing. For the best results, use a hardware load balancer for your CAS array. This need not be some uber expensive device. You can use software load balancing (Windows NLB), but not if the server is hosting multiple roles. Hardware load balancing is required for multi-role server deployments.

– If you want to implement site resilience and DR, you should use a multiple DAG topology. For example, at Site A you can have DAG1 on two servers (active copy and one passive) and a remote copy of DAG1 at Site B. At Site B you have DAG2 (active copy and one passive) with a remote copy of DAG2 at Site A. Site A would also have a FSW for DAG2, and Site B a FSW for DAG2. This is a total of six DAG servers, plus any FSW hosts. This is an active/active site configuration, with users actively “homed” at both locations.

– A server can only be a member of one DAG, so multi-DAG deployments will require additional servers.

– Configure the TTL of the CAS array record to be short lived, to help with a reduction in downtime when performing fail-overs.

– When issuing SSL certificates for your CAS servers, use the CAS array name, not individual server names. If possible, get a wildcard certificate to make certificate life easier. But these will likely cost a lot more than a regular SAN SSL certificate.

– Exchange 2010 now features ‘shadow redundancy’ is basically a stateless message queue technology used in the hub transport server role.

– It is recommended that MX records point to a CNAME record which in turn has multiple IPs. This provides some crude load balancing, unlike preference values for MX records.

– Outlook 2003 has a lot of gotchas with Exchange 2010. RPC encryption settings, OST corruption, non-cached mode delays, and a laundry list of other problems. Bottom line, if at all humanly possible only use Outlook 2007 and later with Exchange 2010.

– If at all possible, do not co-exist Exchange 2003, 2007 and Exchange 2010 at the same time. If you have a mixed 2003/2007 environment, complete your migration to 2007. After all servers are on 2007, then migrate to Exchange 2010. Supporting two versions of Exchange during co-existence is hard enough, and three is simply asking for many sleepless nights.

– Pilot groups should be long term (a few weeks), meaning for more than a few days. At first everything may seem fine and dandy, but once users start banging the more advanced features such as calendars and free/busy, you may run into problems. Don’t just pilot for a couple of days and assume all is well.

– There’s a new feature called the EMC powershell logger. This is a feature that logs all powershell commands that the EMC issues. This is great for capturing all the PS commands that the EMC executes when you use the Exchange management console. You can take that output and use in your own scripts.

– If you are using DoubleTake with Exchange 2003 or Exchange 2007, it performs some unsupported changes on a few critical Exchange objects in AD. While Exchange 2003/2007 will appear to run fine, these changes cause major issues when migrating to Exchange 2010. To help troubleshoot these issues, increase the AD logging level within Exchange. When you run into a problem, comb through the verbose logs for AD related object errors. You then need to find a pristine AD/Exchange environment to compare the ‘hosed’ production objects with what they should look like. Make the corrective change in the production environment and try the migration again. For example, the DN for the public folder hierarchy is cleared by DoubleTake and you need to re-populate the value.

The session was really great, and the presenters really knew their stuff. Given their detailed knowledge and excellent presentation skills, I fully expect their book to be top quality. I have a copy sitting at home, but I haven’t yet had time to start reading it.

Print Friendly, PDF & Email

Related Posts

Subscribe
Notify of
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
August 4, 2010 8:46 pm

“- All DAG members must have the same drive letters and paths for the databases and log files.” So if you were asked to use 4 databases for the DAG, how would you choose to lay them out? Would you give each database and log its own driver letter? E:\Database1 , F:\Log1E:\Database2 , F:\Log2 E:\Database3 , F:\Log3E:\Database4 , F:\Log4 2 luns. Would you have one drive letter for the databases with separate paths? E:\Database1 , F:\Logs1G:\Database2 , H:\Logs2I:\Database2 , J:\Logs2K:\Database2 , L:\Logs2 8 luns. this method cost the most in terms of disk space as you need separate space for… Read more »