Take the 2-minute tour ×

We're currently running Win2K3 SBS as the domain controller with an additional Win2K3 server for hosting files and not really doing much else. We are probably looking at expanding to other offices in the near future.

I'm thinking of having a central domain controller with a win2k3 server at each site replicating the AD, shared files/documents, group policies, etc whilst running exchange server independently at each site - i.e. emails will be username@location1.domain.com or username@location2.domain.com with MX records pointing to the IPs accordingly. This way, I figure that there won't be a need for a constant VPN link and there won't be many disconnection issues if user's directories, files and AD's are all local. Without having separate domains for each of the sites, it means that I can manage the whole shebang by myself.

I'm not exactly sure if this sort of thing is even possible with SBS server. If so, what OS should I be running as the central domain controller? How do I set it up so that AD and share directories, GP etc replicate to the remote servers? Can I run multiple Exchange servers on the same domain?

Any help is greatly appreciated!

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

Sounds like a pretty straightforward deployment.

It sounds like you've already created your domain. Since you're using SBS, be aware that the existing SBS machine will be forced to hold all the Active Directory flexible single-master roles. That's probably not a big deal, but the 75 user limit in SBS might be. While SBS makes for an attractive price-point to get a cheap bundle of Windows and Exchange, you might be better off just purchasing Windows and Exchange Server licenses if you're going to approach the 75 user limit. You also won't be able to use Windows SBS in each remote location, if you want this to be a single Active Directory / Exchange infrastructure. You can only have one Windows SBS Server in a given Active Directory forest, so you'll need to purchase "plain vanilla" Windows Server and Exchange Server licenses for the remote locations. (I'd purchase volume license seats of Windows Server 2008, personally, such that you are allowed "downgrade" rights to W2K3 and so that you can re-assign the software to new server computers in the future w/o "re-buying" it as you would have to with OEM-licensed software...)

This initial DC should be a DNS server, and it should use either use root hints or forwarders to your ISP's DNS servers to allow it to resolve Internet names. If you want to use it as the DHCP server for the LAN in the central site, set that up, too.

This is also a good time to plan out the IP subnets you'll be using for the remote offices, and to create the entries for sites (groups of subnets that have "good" connectivity between them-- typically a single WAN / VPN location), subnets, and site-links. If your VPN is a mesh, you can connect all the sites together with a single site-link. If your VPN is hub-and-spoke you should create a site-link to connect each spoke site to the hub site. If your VPN doesn't allow communication from one spoke to another spoke across the hub then you should turn off "Bridge all site links". I'm glossing over this w/o providing much detail, but you can find detailed documentation from Microsoft. Getting this right is essential to getting Active Directory replication running right, and Exchange 2007 mail delivery functioning properly to remote servers. (If you stick with E2K3 then there's no Active Directory site topology ramification.)

Since your domain already exists, you can start to build up the DCs for the remote sites. You can do this via VPN connections or you can prep the servers on the LAN with the initial DC. Either way, be sure that the new DCs, which start their lives as "plain vanilla" Windows Server machines, use the initial DC for DNS until they're promoted to being replica DCs for your domain. Verify that the machines becoming replica DCs have good DNS before you proceed. You should be able to lookup the AD domain name using "nslookup" and get back the exisiting DCs names / addresses. If you can't, figure out why before you proceed.

Once you've promoted a replica DC, install the DNS Server service onto it. Make sure that each DC for a remote office is also marked as a "Global Catalog" server (in the "NTDS Settings" properties under the server object in "Active Directory Sites and Services"). That will speed logons at client computers and make Exchange email delivery work w/o requiring the VPN in each remote location.

Using a single Active Directory domain will cause all your servers to share a common Active Directory database, including user accounts, groups, OUs, group policy, etc. Unless you have very large numbers of users (and, since you're planning on using SBS, you're limited to a single domain anyway) you should be just fine w/ a single AD domain for everything. (Heck, even if you did have very large numbers of users I'd still steer you toward a single domain unless you had some other mitigating factor that caused you to need multiple domains.)

I'd plan for group policy objects to handle "Folder Redirection" into shared folders on each remote office DC for user's "My Documents" and "Desktop" folders. I'd also deploy roaming user profiles. I would work toward having stateless client computers. I would organize my user objects into OUs that represent remote locations, and then by role from there, if necessary. (I do this with the assumption that you'll probably end up delegating control for some "computer person" in each remote location to perform password resets, so having the users laid-out by physical location gets you some of the way there.)

I'd put client computers into OUs representing each remote location, and apply group policies as necessary (to direct clients to the appropriate WSUS server, etc). Later on, I'd use DFS and replication (which type depending on the version of Windows Server you have) to replicate a folder hierarchy that contained any Windows Installer packages for software that you want to "push out" to client computers in the remote offices, such that each office has a replica of the installation packages folder hierarchy.

If you have the R2 verson of Windows Server everywhere you can use DFS replication (DFS-R) to replicate folder hierarchies from the spoke servers to the hub server (and the converse). In theory, you could replicate a folder hierarchy to all the spoke servers such that users could transparently move between locations and access locally-cached copies of their profile and redirected folders. In practice, that usually doesn't work because DFS-R replication doesn't end up keeping up with the traffic. For maintaining a central copy of the spoke servers at the hub for backup purposes, though, DFS-R may do what you need.

re: Exchange - I see what you're trying to do with the MX's, I think. You're interested in seeing inbound Internet email for each remote location delivered directly to that location's SMTP server, versus being delivered to the hub and then distributed across the VPN. You can do that, but because of email antivirus and anti-spam concerns you may find that it makes more sense to have email delivered to the hub and then distributed to the reomte sites.

It's unclear what you mean by running Exchange "independently". All Exchange Server computers installed in the same Active Directory forest share a common configuration, the Exchange "Organization". You would have to have multiple Active Directory forests in order to have multiple Exchange Organizations, and you really don't want that.

I would deploy a single Exchange Server computer into each remote location. Each Exchange Server computer would host mailboxes for users in that location, and would be capable of delivering email directly to the Internet and to the other Exchange Server computers in the network.

If you're thinking that you need "site-specific" SMTP addresses and MX's for Exchange to work at all, that's not the case. Exchange doesn't use MX records to deliver email between different Exchange Server computers of the same Exchange Organization.

In your network, you would deploy additional Exchange "routing groups", each one representing a remote location and containing the Exchange Server computer for that remote location. "Routing group connectors" (or other types of "connectors") are used to convey the network topology to Exchange (much like Active Directory uses the "site" and "site-link" topology to calculate replication paths). Exchange will "just know" to contact the appropriate remote server when email is sent from one remote location to another. The SMTP address and MX records aren't used in this process.

It's unclear to me why you are concerned that the VPN not "be up" 24 x 7. It's virtual, by nature, so there shouldn't be any added expense to having the VPN available all the time. I'd use good quality hardware VPN termination equipment to terminate VPN tunnels at each remote location in either a hub-and-spoke or mesh fashion, depending on how many remote locations you had. (Personally, I'd use either Cisco ASA-5505 devices or small server computers running Linux and OpenVPN, but there are any number of possible solutions out there.)

You can schedule Active Directory replication (and even Exchange mail delivery / public folder replication) to occur in off-hours if you want to keep the VPN reasonably free of traffic during regular business hours. To my mind, I'd keep the VPN up 24 x 7 and use it for constant AD and Exchange traffic, since it would appear that you're trying to keep user files stored in each office and, in general, users won't be sending traffic across the VPN.

I recommend deploying Windows Software Update Services (WSUS) while you're doing all of this, too. You can get documentation from Microsoft on the specifics, but I'd plan on a central WSUS server with replica servers running at each remote location. As I said earlier, I'd use group policy applied at either a remote-location OU or the Active Directory site to direct client computers to their closest WSUS replica.

No doubt you'll be told that you need various separate servers in each remote location for this. You can use a separate physical or virtual machine for each "role" if you'd like. I'll tell you, from my own experience, that you could get by with a single physical machine acting as a file server, DC, WSUS server, and Exchange Server in each remote location just fine, so long as the machine is "beefy" enough for the count of users in the location. It would be nice to have physically separate machines, but only if the load warrants it. (Now doubt I'll get comments from nay-sayers about how Microsoft doesn't "recommend" that you run Exchange on a DC... and while this is true, the Windows SBS product does just that, and it works fine. All I can figure is that these types of commenters have either an unlimited budget to buy Windows Server licenses or they've never actually had to deal with the realities of making a small budget go a long way.)

Be aware that your users won't have a central URL with which to access Outlook Web Access for webmail in this scenario. Exchange can provide such a central URL, but it would be based on having a "Front End" Exchange Server computer that would access the "Back End" servers in each remote location via VPN. It might just make more sense to tell users to access OWA via a remote location-specific URL and then provide the appropriate port-forwards at each remote location for OWA.

Whew. That was fun.

If you're not super familiar with the products involved you would do well to spend some time in a lab scenario mocking this up. If you're still concerned, find a consultant (with good references) who will work with you face-to-face for a few hours doing the setup for the first remote office. Take copious notes, ask a lot of questions, and gather all the details you need so that you can do the next office(s) yourself. (Believe it or not, there are consultants who are happy to "teach a man to fish". Personally, I hate repetitive work and, while I do enjoy making money, I'd rather teach a Customer how to do something themselves, if they so choose, than do the same thing over and over again.)

As I said, this is a pretty straightforward deployment. You're trying to use the products (perhaps with the exception of SBS, depending on your user count) for exactly what they were intended to be used for, and you're not going to find yourself "fighting" the products.

share|improve this answer
Awesome answer! –  atomicharri Oct 20 '09 at 15:13
Great response, Evan. Not wanting to disappoint, I have a bit of Nay Saying to do. Combining some applications with a DC (notably exchange) certainly can work, but if anything goes wrong, Microsoft will not support it. In a business context, that is important to a lot of people. So my advice would be, if multiple application roles need to run on a single box, make the physical install a Hyper-V server then add each role in seperate virtual machines. –  Tim Long Nov 3 '09 at 0:46
Personal experience has shown me that "not supported" from Microsoft depends a lot on who you speak to in Product Support Services. Having said that, I can find copious documentation indicating that running Exchange on a cluster-node that is also a domain controller is "not supported", but I'm having trouble coming up with documentation saying that running Exchange on a domain controller is anything more than "not recommended". –  Evan Anderson Nov 3 '09 at 4:30
add comment

You can do all this without having the users site in the email address. You simply put the users mailbox on the server at their site. Then when they send mail to a user at another site the Exchange network handles all that once there is a VPN connection between the sites.

You'll need a VPN connection between the sites every once and a while to handle AD replication and file server replication.

You are getting beyond SBS here. You'll probably want to just get a bunch of Windows 2003 licenses to handle everything. One for each server. You can virtualize all this under VMware of Hyper-V so that you only need one or two physical servers at each site.

share|improve this answer
I would agree with that. Active directory domains should be used to set administrative boundaries, not geographical boundaries. It's perfectly reasonable and normal in a 2003 AD forest for many sites to be in the same domain. Plus, having all the mail arrive at a single gateway server makes it easier to do anti-malware scanning (a service like ExchangeDefender would be excellent for that and ED will only deliver to a single designated IP address). –  Tim Long Nov 3 '09 at 0:50
add comment

According to Harry Belsford, who has written lots of books on SBS, he has one simple rule: SBS ends if you're expanding to a second site. When I did SBS consulting, this served me well. Although SBS can be tweaked into some kind of multi-site thing, you are looking at additional server costs that turn the difference between your first server and SBS into a very marginal cost. You don't say anything about number of users at each office. Would be helpful to have know if this number is 10 (no way I'd deploy a site-specific Exchange server for 10 users) or 100 (maybe) or 1000 (still maybe). It all boils down to the quality of your WAN links, the type of traffic you'd be sending through (there's a big difference between the traffic type of an art/graphics company and a publisher that only works with text files).

So, a little more info would be great before we (at least I) can say something about this.

share|improve this answer
add comment

Your Answer


