We have Exchange installed in our head office which provides all our email. We have a branch office which connects via VPN, but this means email is very slow for them because it has to go over the VPN link.

We have an extra Exchange License the we are considering installing on the Branch Office Server, and moving some of the mail accounts onto it.

Has anyone done anything similar and can point out potential problems and pitfalls, or can point out good resources to help plan a move like this. Both servers are running Windows Server 2003 and Exchange 2003.

I am hesitant to dive in and try it until I know how it may affect existing email accounts and access.

4 Answers
4

I'm in agreement with everything that Massimo says. I wanted to expand re: "existing accounts and access".

For Outlook to remain "connected" to the mailbox it's really, really straightforward.

I'd recommend bringing up the new Exchange Server computer on the network where the current Exchange Server computer is located. Do everything that Massimo said re: the Routing Group (and, if necessary, creating an Active Directory site for the remote office, etc).

You'll perform a "Move Mailbox" operation on each mailbox that you want on the new server. I've found that it's best to do this when the user doesn't have Outlook open, but it can be done "hot", too. (I've found that Outlook can get confused when Cached Exchange Mode is enabled and the mailbox gets moved to another server. Your mileage may vary.) Performing a "Move Mailbox" over the VPN is going to be tedious and potentially failure-prone. That's why I'd recommend staging the new server on your existing LAN first and getting all the mailboxes moved over. Create your public folder replicas at this time, too.

Since your users are already used to the "speed" (or lack thereof) of accessing their mailboxes they won't notice any speed difference during this transition. Their Outlook clients will automatically "update" to reflect that the mailbox is on a new server (this is a very, very nice feature). Once you've gotten all the mailboxes moved, ship the server out to the remote site, change its IP address, plug it into the network, and get its DNS registration updated.

If your users are only using Outlook to connect to the Exchange Server computer you can be "done" at this point.

If your users are also using Outlook Web Access, POP3, IMAP, or ActiveSync over the Internet, though, you're going to need a strategy to facilitate their access. Presently, having a single Exchange Server computer you've never had to worry about "Front End" and "Back End" servers. When you have multiple Exchange Server computers hosting mailboxes you'll either have to: (a) allow users to connect to OWA, POP3, IMAP, or ActiveSync running on the server that hosts their mailbox, or (b) deploy a Front-End Exchange Server computer that clients connect to for these protocols.

The front-end/back-end server method is the easiest to use, but requires an additional Exchange Server license. Users have one URL to connect to for OWA and one hostname to use for POP3, IMAP, and ActiveSync.

Alternatively, we have some Customers who have two Exchange Server comptuers and users who use OWA. To get by "on the cheap", we've configured two (2) different public IP addresses and names for the users to connect to-- one for each Exchange Server computer. The user has to connect to the correct URL / server to access their mailbox, though.

Thanks for the info on OWA, I hadn't thought of that... since we're limited to 1x server and 1x license, but we do have an existing public IP for that server, we may just go with two webmail addresses. What I might do is move all the branch offices' emails to this location, so when users go to webmail they choose either "HQ" or "Branch office". They may just be able to grasp that... ;)
–
Keith WilliamsSep 22 '09 at 16:00

That strategy sounds like a winner. Be sure to think about your SSL certificate needs re: a second OWA instance, too. >smile< (It's never easy, is it?)
–
Evan AndersonSep 22 '09 at 16:47

1

I would add that you'll want to ship the server machine there rapidly, and by rapidly I mean before its computer account expires. Otherwise, you might have to disjoin it from the domain, then re-join the domain again, to get it recognized. Sound strange? I've spoken to people who shipped their servers overseas via cargo ship and.... yeah.
–
Mark AllenSep 22 '09 at 19:52

Exchange is designed to allow for multiple sites, so this should work out quite well if you design things properly.

Exchange 2003 "sites" are called Routing Groups; the definition is as simple as "Exchange servers in the same RG can directly talk with each other". A Routing Group Connector allows servers in different RGs to move messages between them.

You should install your new server in your Active Directory domain, install Exchange on it and create a new RG to put the new server in; then you'll have to manage mail flow and move mailboxes to the new server; you'll also need to set up public folder replicas, if you use PFs.

A very important thing: you should have a Domain Controller/Global Catalog available in the new site, so the new Exchange server will be able to query AD without going over the slow VPN connection, which is the bottleneck here. You should install and configure a DC/GC in the branch office, define the new AD site and configure replication; then you can install your new Exchange server and it will automatically use the local DC.

DC/GC won't be a problem - the office server is already a DC/GC. Would installing on a domain controller cause us any issues? -- Simon's boss
–
Keith WilliamsSep 22 '09 at 13:43

You'll hear rumblings about how Exchange 2003 on a DC isn't "recommended", but the Microsoft Windows Small Busienss Server 2003 product runs Exchange 2003 on a DC fine. Likewise, I've had no major difficulties running Exchange 2003 on DCs for Customers for years.
–
Evan AndersonSep 22 '09 at 15:12

It actually isn't recommended to install Exchange on a DC, but it's perfectly possible; and if the server doesn't directly handle Internet mail traffic and/or OWA publishing, there are no security issues. It will take quite a while to reboot such a server, though...
–
MassimoSep 22 '09 at 15:20

Isn't that what I said? It isn't recommended, but it works fine. I haven't experienced long reboots. Whether or not it's a "security issue" is a matter for debate, since "security" isn't boolean. Like I said, W2K3 SBS runs in such a configuration in many, many offices and works fine. It may not be "recommended", but it can work just fine. It depends on your budget re: another server computer and a license of Windows versus running in a "not recommended" configuration, to my mind.
–
Evan AndersonSep 22 '09 at 15:26

Hehe, yes I've experienced slow reboots on SBS server before. Sadly budget is very limited here, so we have to work with an existing server and our single spare license. Thanks for the replies!
–
Keith WilliamsSep 22 '09 at 15:57

It does add complexity to your network! Sometimes it is just way easier to serve those offices with IMAP/OWA or decent hookups so they can access your exchange locally. Extra Exchange, extra DC, more than one point of failure, etc. etc.