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).
Yep Citrix is the way you probably want to head with this. RDP's vanilla implementations are great for low-cost solutions under most high-bandwidth, low-latency environments for general desktop/windows app distribution. But the whole thing kinda falls apart under specialist workloads and high latencies.
I answered a recent, relevant question where I think there's some crossover, here: Improving Performance of RDP Over LAN
You'll definitely want to test thoroughly before splurging any cash, though, as you still may hit limitations with such a high ping.
Outside of the Citrix/ThinApp solution, you may need to consider decentralising some of your applications and moving them back towards the branch offices. Even if you can't move them right out to the branch, having a rack or some kind of presence in a datacenter in the UK or europe, and hosting your solution out of it, may be the best option.
Best Answer
Frist of all - You don't want to (and I believe its not possible) to redirect OST files to a network share. They are supposed to -always- be available to the client.
I've done my part researching this, and it turns out that OST's on remote desktop services isnt something thats going to happen. I can guess why you want it (instant searches), but its simply not worth the cost.
Also - if you run a remote desktop farm where users get load-balanced to different servers you'll get this potential scenario:
100 users - 5GB mailbox - 5 remote desktop servers = 2,5TB of disk space JUST for storing OST files across the remote desktop servers. Add the increased I/O each time a user logs on to a remote desktop server and the Exchange sync starts.
Do you really want this cost?