If you're running Microsoft Small Business Server (SBS) 2003, you might be interested in an approach I've come up with for building a branch office in an existing SBS 2003 network. This approach is an alternative for what's commonly known as the Install from Media method, in which you build a domain controller (DC) for a branch office from backup media so that you don't need to ship the DC to the branch site.

With my alternative approach, you build the DC in a second subnet created in the main office, as Figure 1 shows. Unlike the Install from Media method, my approach requires that you ship the DC to the branch office. However, the advantage to using my approach is that you can build and test the DC's functionality before you ship it to the branch site.

As Figure 2 shows, the final deployment consists of the main office with a single-NIC machine running SBS 2003 Standard Edition, Service Pack 1 (SP1). The branch office has a machine running Windows Server 2003 Standard Edition, SP1. The two sites are configured as Active Directory (AD) sites, connected by two IPsec VPN firewalls (in my case, Symantec Gateway Security 320). The firewalls provide a virtual router between the subnets.

The main process is to build a DC with AD and DNS at the main site, check everything out, then move the DC to the branch site for final adjustment and check. Figure 3 depicts this process. Although not complex, it involves fair amount of details, some of which are pointed out here:

  • Before joining the workgroup server to the domain, use static IP (not DHCP) addresses and be sure to fill in the addresses for the default gateway, DNS, and WINS. Otherwise, the workgroup server will lose connectivity when it boots up with a new address. It's a good idea to start the workgroup server with an address that you aren't going to use later for the DC.
  • Add the branch subnet to the Directory Security exception list so that the branch subnet can access the IIS ConnectComputer virtual directory. Otherwise, you can't open the ConnectComputer page from the branch subnet.
  • Remove the SBS_LOGIN_SCRIPT.bat script from the administrator profile that you're going to use for logging on to the branch server. Otherwise, you'll encounter a problem in which the default gateway address changes to that of the main office whenever you log on to the server or a Remote Desktop connection is made to the server.
  • For the AD-integrated DNS zone's replication scope, select the To all DNS servers in AD domain option, which is one of the two application directory partitions where the zone data can be stored. That way, you're consistent in where you store the zone data.
  • Don't install the DNS service on the Windows 2003 machine until after it is made a DC and AD replication has occurred.
  • Be sure to create an AD-integrated primary forward lookup zone. AD-integrated zones create multiple Start of Authority (SOA) records for the SBS local domain. Each DC becomes SOA for the forward lookup zone it carries. Although not conventional, this setup is consistent with the multimaster AD design in which changes can be made on any DC and replicated to other DCs.
  • High-speed Internet connection is assumed at both sites. Pay attention to the upload speed because it becomes the download speed for the other site.

After you ship the server to the branch office, remember to change the DNS forwarders to the local ISP's DNS servers and delete the static route entries to the branch subnet from the main office's SBS server and firewall. Now you can proceed with the final connectivity, replication, and other functional tests, including testing client logons, access to Internet and intranet, network shares, and the Microsoft Outlook connection to Microsoft Exchange Server.