Enable TLS 1.2 Exchange 2010

It sounds like a piece of cake, to be honest. A single server, single physical location scenario like you're describing is the easiest migration to perform. Follow the guidelines from Microsoft and you'll be well on the way to success. You're basically talking about a "Move Mailbox" migration, with zero visibility to the users.

Your Exchange 2003 install should already be at Service Pack 2. That's all that's really necessary there.

Exchange 2010 has the feel of a minor version upgrade from Exchange 2007 (what w/ a lack of major architectural changes like there were between 2003 and 2007), and the migrations I've done from 2003 to 2007 have been very smooth anyway. I expect that 2003 to 2010 migrations will be equally smooth (though I haven't had occasion to do any yet... anybody game?).

You're saying the right things re: getting a new server computer to host Exchange 2010. Be sure you provision your storage per Microsoft best practices (separate spindles for ESE transaction logs and databases, tuned for sequential access for the former, and random access for the latter).

I have seen some hiccups in Exchange 2003 to 2007 migrations when users have their mailboxes open, while in Cached Exchange Mode, during the migration. It's supposed to be possible to move a user's mailbox while they're using Outlook, but I wouldn't chance it-- I'd be sure that they aren't using Outlook while moving the mailboxes.

If you're going to cut everyone over at once, changing your firewall rules that forward OWA access from the Internet to the new Exchange Server computer isn't a big deal. If you plan to coexist mailboxes on both servers for a time, then you're going to need to worry about users accessing the right instance of OWA to get to their mail, depending on whether their mailbox has moved or not. (That's a good argument for cutting over all the users at once during a scheduled downtime interval.)

I don't know that virtualization will "help" in the sense that the migration is going to be the same whether you're migrating onto bare metal or a virtualized machine. Exchange 2010 is more friendly than prior Exchange versions with respect to IO needs, so running in a virtualized environment (where you incur some amount of IO overhead due to being virtualized) is going to less of an impact as compared to prior Exchange versions.

If you're hosting any Exchange-integrated antivirus are you ready to go with a license for an Exchange 2010-capable version?

Is your backup management software ready to support Exchange 2010?

You may want to read up on Exchange Autodiscovery. It can have ramifications for your SSL certificate and DNS infrastructure, assuming you don't want to get little annoying warnings from Outlook. Have a look at these for some good background (the second refers to Exchange 2007, but it hasn't change dramatically in Exchange 2010).

• Understanding the Autodiscover Service

• White Paper: Exchange 2007 Autodiscover Service

a) You can take a look at this cmdlet - Get-ThrottlingPolicy. It has MaxTimeinAD and other keys which can be modified. More details here. http://blogs.msdn.com/b/exchangedev/archive/2011/06/23/exchange-online-throttling-and-limits-faq.aspx

b) How can you control EWS Access.

• Per Mailbox> Run this from Exchange shell get-casmailbox -identity:"username" | fl "*EWS* You can disable those keys using a set-mailbox -identity:"username" -EWSEnabled: $False
• The whole organization: `Get-OrganizationConfig | fl EWS
• You can play around with this, with a list of mailboxes to modify in CSV, and then importing the CSV > and piping out all mailboxes one by one to set-casmailbox.

c) New Mail Notification is a client side feature, so you need to check outlook / phone settings.

b) During Exchange 2003-2010 co-existence, are all mails routed through 2010 or 2003. Also did you setup the CAS role and tested OWA access ?