Running Multiple Servers in a Windows Small Business Server Environment

  • Article

Updated: May 27, 2009

Applies To: Windows SBS 2003

Note

The information in this document applies to the Microsoft® Windows® Small Business Server 2003 R2 server software (Windows SBS). The intended audience for this document is Value Added Providers and Value Added Resellers (VAP/VARs).

Windows SBS is a powerful single-server solution for small and medium-sized businesses. Out of the box, it can run a small-business network without any additional software. But its abilities extend beyond the single-server deployment. For customers who need additional power and flexibility, Windows SBS can be the core of a multiple-server environment.

This document explains the technology and scenario alternatives that build upon Windows SBS. It presents prescriptive guidelines for deploying Windows SBS and Microsoft technology in multiple-server environments. These guidelines can help you simplify integration and determine suitable server deployments for your customers.

Understanding Windows Small Business Server

It is rare that Windows SBS partners have the opportunity to plan, design, and implement a multiple-server installation from scratch. If you do, consider yourself lucky; you can work with your customer to define their business needs, evaluate available resources, and plan the deployment accordingly.

But most of the time, customers have already installed client computers, some servers, and network equipment before they decide they need a better integration solution. Perhaps they have a server running file and print services at a remote office, or they have copies of the same line-of-business (LOB) application running at multiple locations. The customer wants to find a cost-efficient, easy-to-manage solution that links all the systems together.

Your challenge as a partner is to understand what technology considerations are involved in either adding additional servers to a Windows SBS domain or adding Windows SBS to an existing multiple-server environment. To do this, you must determine which deployment scenario is appropriate and then explain the trade-offs involved to the customer. There are also non-technical factors that can influence the customer's decision.

Design Constraints of Windows Small Business Server

Windows SBS is designed to run mission-critical business services on a single server, making it a cost-efficient solution for small businesses. It provides centralized user and server management, network security, file and print services, e-mail, database capability, and Web-based collaboration tools. These services can increase the technological sophistication and efficiency of small businesses to a level that is equal to or greater than larger companies and competitors in their market, often at substantial cost savings.

Although Windows SBS is designed to be a single-server solution, it works with other servers on the same network, with a few limitations. Windows SBS peacefully coexists with other servers, extending its flexibility and value to the customer as the networking environment changes or grows. This is welcome news for many users who believe that "single-server solution" means "only one server solution."

But before you create a new multiple-server environment for a customer, you should factor in some design constraints that might affect your plan. These constraints do not impede your progress, but they are important to keep in mind when you consult with customers who are planning to integrate multiple servers into a Windows SBS network. The constraints include the following:

  • You can create and manage only one Windows SBS domain. Windows SBS is designed to make network management as easy as possible. One way it does this is by restricting the Active Directory® directory service so that there can be only one domain, with Windows SBS as the domain controller at the forest's root.

Important

You can install Windows SBS into an existing Microsoft Windows Server® 2003 domain in order to manage and control the existing domain by using Windows SBS as the core server. This has the effect of switching all domain controller services to Windows SBS, such as authentication and security services, as well as Flexible Single Master Operations (FSMO) and global catalog functions. This is a highly technical process and it is not recommended unless you have advanced skills as a Windows SBS consultant. For more information, see "How to install Small Business Server 2003 in an existing Active Directory domain" at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58909).

  • You can't establish trusts with other domains. The corollary to the "single domain" requirement is that you can't establish trusts with other domains. This is true both for other Windows SBS domains and for Windows Server 2003 domains.

  • You can't create child domains. With Windows SBS, you cannot create subdomains in your existing root domain (such as subdomain.contoso.local).

  • No more than 75 user or device licenses that access a server that is running Windows SBS. You can have no more than 75 user or device licenses that access the server that is running Windows SBS. If your customer requires more than 50 user or device licenses, consider purchasing the Windows SBS Transition Pack. It allows you to convert your Windows SBS license into standard licenses for each of the individual server components, such as Windows Server 2003 Standard Edition and Microsoft Exchange Server 2003 Standard Edition. It also removes the limit of 75 user or device licenses. For more information about the Transition Pack, see the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58910).

  • Exchange Server, SQL Server, and ISA Server are licensed only for the server that is running Windows SBS. The copies of Exchange Server and Internet Security and Acceleration (ISA) Server that are included with Windows SBS 2003 R2 Standard Edition and Premium Edition (for ISA Server) can be installed only on the server that is running Windows SBS. You can add additional servers to the Windows SBS domain and install other applications on those servers, but to install Exchange Server or ISA Server on a different server, you must purchase separate licenses for the servers. Expanded client access license (CAL) rights in Windows SBS 2003 R2 allow client computers to access additional servers on the network (such as those that are running Exchange Server 2003, SQL Server 2005 Workgroup Edition, and Windows Server) without requiring additional CALs.

These restrictions present some challenges in planning multiple-server scenarios, but they tend to affect ad-hoc network implementations rather than informed network design. With a little advance planning, you can design and build a multiple-server network that uses Windows SBS at the core.

Planning and Design Considerations

Ad-hoc multiple-server deployments are often expressions of frugal creativity or sometimes desperation. Various server products were stretched, jammed, or mutated into configurations that the software designers did not originally intend. As part of your planning phase, create a site survey that documents the physical and logical layout of the servers and services in each office, so that you have an idea of what the current situation is. For more information about infrastructure planning for small businesses, see "Small IT Solution" at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58911).

Next, compare your physical and logical diagrams with the technologies that affect multiple-server deployments. These technologies are described in the following sections.

Server Capacity

How much server power do you need in order to provide acceptable performance? The standard answer is usually, "It depends." Rather than guessing, consider the following factors when making recommendations:

  • Types of applications and services needed. Not all server applications are created equal. A database application is computationally intensive, and it benefits from having a powerful CPU and plenty of RAM available. A mail application is disk-space and throughput intensive, and it benefits from having large amounts of storage and multiple network cards available. A server that is running Windows SBS usually runs several applications and services simultaneously, and consequently it requires more powerful hardware than a single-purpose server.

  • Server load: Theoretical versus real-world demands. Server load is one of the most important factors you need to evaluate. Each client computer that connects to your server requires server resources; numerous client computers that request several intensive resources can strain your server if it lacks the hardware to sustain the load. Your experience provides value to the customer; if you know that a server application's minimum requirements do not provide acceptable performance, you can recommend the appropriate hardware to the customer. If you do not have experience with a specific application, talk to other consultants at a Windows SBS user group meeting or search the Web or newsgroups for other consultant’s opinions and experiences. You can find some basic capacity guidelines per number of users at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=60075).

  • Backup, redundancy, and fault tolerance. The more the customer values the data, the more you need to plan for inevitable hardware failures. A law firm can possibly function without a server for a day; a bank branch cannot. Make sure you discuss availability and risk tolerance with your customer, and plan your hardware options accordingly.

  • Replacement timeframe. Replacing an old server involves a considerable amount of cost and complexity. Tools are available to help with server migration, but it is better to extend the usable life of the server than to replace it within a couple of years. Encourage your customer to buy as much server as they can afford now, such as an x64 server that will be able to run next-generation operating systems and application software.

Note

You should discuss at least two different hardware configurations with your customer before they buy new hardware. For example, one configuration might be sufficient for current requirements, while another might allow for more future growth. This lets the customer decide on the best way to invest their money.

Server Applications

When it is matched with appropriate hardware, Windows SBS Standard Edition is optimized to support e-mail, remote users, file and print services, common administration tasks, and one or two LOB applications. Windows SBS Premium Edition adds SQL Server and ISA Server, which can increase the load on the server.

In most small businesses, Windows SBS handles the load smoothly. But if customers want to extend the Windows SBS foundation, they must purchase additional servers and applications that might not be the most cost-effective solution. As with most multiple-server environments, they must balance desired functionality, performance, and security against the cost to purchase, implement, and maintain additional servers and server applications.

Some applications can easily be added to the Windows SBS network, whether on the local network or across a wide-area network (WAN) in a remote office. Other applications require additional planning to consider the effect of having more than one server with the similar service available.

Applications Included with Windows Small Business Server 2003 R2

Other Microsoft applications can be integrated into multiple-server scenarios. You can add some of the applications easily; others present technical or management challenges.

Note

Additional servers require additional server and client licenses. For more information about licensing and multiple-server scenarios, see "Windows Small Business Server 2003 Licensing: Frequently Asked Questions" at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=44529).

  • Windows Server 2003. One of the most common misconceptions is that customers cannot run another member server or domain controller in a Windows SBS domain. This is not true! You can add additional member servers that are running Windows Server 2003 or Windows 2000 Server to a Windows SBS domain. You can even promote a member server that is running Windows Server 2003 to be a domain controller, in order to improve authentication services at remote offices.

  • Exchange Server 2003 with Service Pack 2. Installing an additional Exchange server in a Windows SBS domain is problematic because there is no easy way to replicate information stores between servers in a Windows SBS domain. The servers cannot be clustered, and Windows SBS does not support network load balancing. If your customer absolutely must have redundant Exchange servers, consider purchasing the Transition Pack.

  • SQL Server. SQL Server 2005 Workgroup Edition is an integrated component of Windows SBS 2003 R2 Premium Edition. You can install SQL Server 2005 Workgroup Edition as your database for business applications. You can also upgrade Microsoft SQL Server Desktop Engine (Windows) (MSDE), used by Microsoft Windows SharePoint® Services, if you want to be able to search document libraries on your company's internal Web site.

  • ISA Server. ISA Server is an integrated component of Windows SBS 2003 R2 Premium Edition. You can install ISA Server on a member server or a standalone server in a Windows SBS domain if you have separate licenses for Windows Server and ISA Server. However, you lose integration with Windows SBS management tools, such as the Configure Your Internet Connection Wizard.

  • Update Services. Update Services is an integrated component of Windows SBS 2003 R2. It provides centralized patch and update management for computers that are on the Windows SBS 2003 R2 network and that are running one of the Windows operating systems that support Microsoft Update. Update Services can help protect the Windows SBS network by keeping Windows-based computers on the network up-to-date with the latest Microsoft software updates.

  • Remote Web Workplace and Terminal Server. Remote Web Workplace is the easiest way to let employees and customers access internal resources, such as e-mail and LOB applications. If you configure a member server as a terminal server in a Windows SBS domain, the server is automatically available to users via Remote Web Workplace.

  • Third-Party or LOB Applications. You can deploy these easily on member servers in the Windows SBS domain. However, you must plan carefully to determine how to provide the most efficient access to these applications.

Secure Computing

One of the great trade-offs in network planning is that of security versus ease of use. The more secure something is, the more difficult it is to use, and the less likely it is that users will follow any prescriptive or restrictive requirements that you install as part of the business process.

An in-depth discussion of improving security is beyond the scope of this document. But there are several factors that become important in remote-office deployments that you should address in your deployment plan.

  • Physical security. How often have you walked into an office only to find that the company's server is sitting under a desk somewhere? Physical security should be one of the primary factors for any site in your remote-office deployment. If someone can gain physical control of a server or network device, the security battle is lost before it has begun. Do whatever it takes to help secure the network's hardware: BIOS passwords, computer case locks, locked data closets. The specifics depend on what is available at each site, but make sure you discuss this with your customer and come up with appropriate solutions for each site.

  • Data backup and recovery. Multiple-server scenarios change the scope of data backups and recovery. Instead of working with the data on one server, now you must consider multiple servers. Member servers that provide file and print services must also be backed up regularly. This means purchasing additional backup technology or possibly changing the customer's business processes so that data is stored (and backed up) in a more organized manner. Although hard drives are inexpensive, backup technology can be expensive, depending on the methods used. Discuss with your customer such factors as disk quotas, expected database growth for Exchange and LOB applications, and archive solutions for older material. If you rely on employees to change tapes or to deposit the tapes at an offsite security service, make sure you include those employees in the appropriate security groups with the appropriate and limited permissions. If numerous people are involved in the backup process, draft a document describing what they can do, what they can't do, and when to call for help.

  • Disaster planning. Sometimes even the most careful businesses are hit with disaster: fires, floods, hurricanes, earthquakes. If disaster strikes, what does it take to get the business operating again? In your planning, you should determine where and how to restore Windows SBS and any LOB applications and associated data. List the services by priority—for example, the site for Windows SharePoint Services might not be as critical as a company's customer records in a SQL database. Draft step-by-step procedures to restore the server that is running Windows SBS and member servers from a backup, and hold a practice session on a weekend to see whether you can actually get the business back up and running by using your procedures. Ideally, restore a few random files from a backup once a month to verify the integrity of the backups. If the customer does not have spare hardware, you can practice the restore procedure in your own lab, or you can image servers and bring them up in the lab (potentially on virtual hardware) in order to test them.

Special Considerations for Remote Offices

There are additional factors that you should consider for remote-office deployments, because each deployment has its own specific variations on a standard multiple-server scenario. Think through this list of factors, and ask your customer questions about what they want to do and what is important to them. Their answers can help you identify which factors are more important than others, and they can point you to areas that you might need to investigate further.

Network Bandwidth

Network bandwidth analysis considers the amount of traffic that you expect to move across the physical connection between the offices. Information has to move from one site to another, whether it moves over DSL, cable modem, or a leased line. Connection speed is the most significant bottleneck between sites, and it determines what services and technologies can be shared across the network. The bandwidth affects your server deployments to the greatest degree, so make sure you quantify the number of users at each site and the expected traffic load across the connections.

The following is a list of considerations for various connection types. It is not exclusive. You might have other communications technologies available, such as ISDN, wireless, or satellite communication. If you are using those technologies, you should work with your network service provider to determine capacity planning and service availability.

  • Digital Subscriber Line (DSL). DSL is offered by local telephone companies over existing telephone lines, with different levels of service available depending on whether you have a consumer or a business account. Download speeds vary from 256 kilobits per second (Kbps) to 7 megabits per second (Mbps), and upload speeds vary from 256 Kbps to 1.5 Mbps or more. Speeds depend on the quality of the phone line and of your hardware, and you do not share the connection to the central office with other customers, although you do share the same main connection to the Internet. If the branch office is more than three miles from the telephone company's central office, DSL might not be available. The DSL connection cost depends on the link speed. In addition, the customer pays monthly fees both to the phone company and to the Internet service provider (ISP). You might also have to pay a DSL modem rental fee, although DSL modems can be purchased at low cost. For multiple business sites, package deals can often be arranged.

  • Cable modem. Television cable providers offer this service for both consumer and business accounts. Download speeds range from 1.5 Mbps to 8 Mbps, and upload speeds range from 256 Kbps to 1.5 Mbps or more. Some offices might not have television cable installed to the building, so it might not be available at all locations. The cable-modem speeds are also theoretical, because you share the local network connection with other cable users. During peak hours, the connection might be slower than normal because multiple connections are vying for bandwidth. As with DSL, the bandwidth cost depends on the speed, and you typically have to pay a monthly rental fee for a cable box.

  • Dedicated or leased line. You can obtain these network connections from telephone companies. The connections have a high bandwidth, so they are useful to customers who need to move a lot of data between sites regularly. Fractional or dedicated T1 lines are typically used for branch offices that are close to a telephone company's central office, and frame relay is used for more distant offices. Speeds vary, no other users have access to the link, and most dedicated lines come with a service level agreement that guarantees a minimum amount of bandwidth. These lines are not inexpensive. But for customers who must move a lot of data (such as CAD/CAM drawings, pre-press files, or large inventory or stock database updates), these are much better alternatives than DSL or cable modem.

  • Dial-up. Dial-up connections are useful for two groups of people: remote users connecting directly to a server and remote users connecting to the Internet and then to a server. Dial-up connections are common for business travelers, for telecommuters, and for remote administration tasks when the regular Internet connection is not available. In rare cases, customers might request a dial-up connection between servers in order to connect the offices. If this is the case for your customers, they should understand the restrictions that are inherent in using a dial-up connection. Dial-up speeds rarely reach 56 Kbps, so do not consider using dial-up connection for any but the most basic connections between offices, such as transferring small files or occasionally checking e-mail.

If you are deciding what type of connection to use between a remote office and the main office, your two basic considerations are the amount of traffic generated by users and the amount of traffic generated by server maintenance (such as data replication and backup). User traffic typically consists of Web browsing and e-mail. For sizing purposes, Table 1 gives you an idea of how to determine bandwidth requirements for remote offices.

Table 1. Determining Bandwidth Requirements by Number of Users

Number of Users Recommended Minimum Download / Upload Speed

1-10

256 / 128 Kbps

10-20

512 / 256 Kbps

15-30

768 / 384 Kbps

20-40

1024 / 512 Kbps

30-60

1536 / 768 Kbps

If users do more than check e-mail, browse the Internet, and collaborate by using Windows SharePoint Services, you should add additional bandwidth for each application. Check with the manufacturer of each application to see whether they have this data; otherwise, as a best guess, add another 50 Kbps download and 25 Kbps upload for each application per simultaneous user.

If you plan on having remote users connect to the network by using client-based virtual private network (VPN) connections, you should do some rough calculations to determine whether your network connections will be affected. There is no simple way to determine how much bandwidth each VPN connection needs, because it depends on your local area network (LAN) architecture, on the applications that the remote users need, and on the ability of the VPN server to handle multiple connections. For more information about VPN capacity planning, see the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58912).

Server-related traffic presents a different picture because the traffic tends to involve transferring large quantities of data at infrequent intervals, such as data replication and software installations. Although most of these functions occur during non-peak hours, the quantities of data involved can overwhelm a slow connection. For Windows Server 2003, slow links are defined as any connection that is slower than 500 Kbps. This speed affects not only what is replicated to domain controllers at other offices, but also what Group Policy settings can be enforced. Security templates are always enforced; software restrictions and folder redirection templates are not. For more information about Group Policy and link speeds, see the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58913).

The bottom line is that if you do not have fast links connecting the remote offices to Windows SBS, you will run into difficulty when you try to replicate information stores, synchronize LOB application databases, back up remote data to a central location, or manage user desktop features such as folder redirection. Because data integrity and operational continuity are important, spending the money on robust links between sites should be high on the priority list. For more information about optimizing remote access, see the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58914).

Note

Most private business networks are not well-suited to hosting a publicly-accessible Web site. Each inbound Web site connection requires at least 50 Kbps, and the network can be quickly overloaded with Web site requests. If your customer wants to host their own Web site, they should use a connection that has plenty of bandwidth and a separate server for the site. For most small businesses, it is more cost-efficient to have an ISP host and maintain the company's Web site.

Network Services

Network services provide name resolution for computers and servers on the network. Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Windows Internet Name Service (WINS) work together to help computers locate resources on the local network and on the Internet. Windows SBS installs DHCP, DNS, and WINS by default.

However, remote-office deployments require additional planning to ensure that these services work together. Remote offices might require different approaches to network service management, because some scenarios do not provide you with the tools to manage the services directly. You are likely to encounter two scenarios: remote users connected to the main office over the Internet, and remote offices connected directly to the main office over a VPN connection or dedicated line. Remote users usually connect by using either Remote Web Workplace or Outlook connecting to Exchange via RPC over HTTP. Remote offices usually connect by using demand-dial VPN connections.

For remote office networks connected directly to the main office by using VPN or leased lines, you can use Windows SBS to manage network services. When you do this you gain the ability to manage and monitor your remote site's connectivity.

Note

One alternative to routing all traffic across the VPN connection is to route internal resource traffic across a VPN while forwarding all other traffic through a local Internet gateway. This provides better traffic management capability and overall faster response times at the expense of increased management required and increased potential for security holes. This is most often done by adding static routes for the local traffic to the IP adapter's route table. For more information about connecting remote offices over the Internet, see "Routing Overview" at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=58915).

Windows Networking

Windows SBS relies on Active Directory to provide authentication, rights, and permissions for computers and users on the network. The server acts as the root domain controller and operations master for the entire Windows SBS domain. The server that is running Windows SBS expects to provide all authentication and permission services for every object in the domain.

If you have remote offices and you want to use a common set of Group Policy settings for users in the company, you must consider the connections to the remote offices and how they impact Active Directory services. If many remote-office users are trying to log on in the morning and the network connection to the main office is slow, then user authentication can be delayed or may even fail. This can result in the user's cached credentials being used to access network resources, which might not be the desired effect, such as when permissions are revoked for a shared network resource. If authentication traffic is high and the remote-office link is slow, consider installing a domain controller in the remote office to improve authentication and security management.

The nature of the business and its remote offices also determines whether file and print services are needed. For retail or point-of-sale operations, it is not likely that each sales lane needs to print out Web pages on a shared printer. But a warehouse or loading dock does require a shared printer for pick lists and shipping labels. Depending on the applications in use, there may also be a need for server-based data or for a server-based application.

With these Windows services, it is a balancing act between centralized management, speed, and performance. Adding a remote-office server is often the quickest way to improve the robustness and speed for users who are accessing network resources.

Other Useful Windows Server Technologies

Other Microsoft technologies can be leveraged in multiple-server scenarios. Not every customer can afford to purchase new hardware and software for every remote office, and it is up to you to help them find ways to keep costs down while extending the reach of their business applications.

  • Remote Access technologies (Outlook Web Access, ActiveSync, Remote Web Access). These technologies can save you a lot of time and money, especially for remote offices. You can set up accounts for remote-office users at the main office, and then they can access all necessary applications across the network. Most remote workers can use RPC over HTTP for e-mail. This allows remote users to use Microsoft Outlook® 2003, including calendaring and shared folders, without requiring a dedicated VPN or WAN connection between offices.

  • Terminal Server. Consultants often deploy Windows Server 2003 Terminal Services running in application mode to provide remote user access to LOB applications. Remote office users can access these applications by using Remote Web Access and the Terminal Services option. For more information about adding a member server to host Terminal Services access to applications, see "Deploying Windows Server 2003 Terminal Server to Host User Desktops" at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkID=17050).

Multiple Server Deployment Scenarios

There are two primary scenarios for multiple-server deployments. The first is main-office centric: all servers are located at the main office, and remote users connect to the main office. The second scenario has member servers or domain controllers at remote offices.

There is also a third multiple-server scenario: the customer wants to have a server that is running Windows SBS at every site. This option can be used when a customer wants to run essentially separate networks.

Each scenario can be modified to accommodate a customer's needs, but the best practice is to stick to one of the first two scenarios as closely as possible. This makes your design, deployment, and management much easier in the long run, and it also keeps your customer happier with fewer support calls needed.

All servers in the main office

The simplest and least-expensive configuration is one where the server that is running Windows SBS and all other servers are located in the main office. Figure 1 shows remote users connecting to the main office by using their own dial-up or Internet connection. This is a common configuration for smaller businesses and for businesses that do not have complex business needs.

Typical customer scenario

This scenario is best used where overall business administration is highly centralized. Most, if not all, applications and data reside on servers in the main office, and only casual or infrequent remote access to LOB applications is needed. If there are remote offices, the business tasks performed at each office are functionally independent. All interoffice traffic is routed over the Internet.

Putting the pieces together

Some of the components listed below might already be in place. If so, work them into the planning and deployment documents so they match the scenario more closely. The less customization you have to do, the better.

  • All servers located at the main office. The server that is running Windows SBS and the servers that are running all applications and storing all data are located in the main office. This is the easiest scenario to manage, both for regular administration duties and for backup and security.

  • Inexpensive network connections between offices. DSL or cable modem connections can be used to connect the offices, although dial-up connections are possible if faster connections are not available. Scale the connection types to match the types of applications and information needed by remote users.

  • Firewall or security appliances at every office. Use a router with firewall capability at every office that uses a DSL or cable modem connection in addition to a software firewall. Commercial-grade firewalls and security appliances often provide better security, content filtering, and hours-of-operation capabilities, so you can place some limits on unrestricted Internet browsing without requiring ISA Server 2004. Dial-up users should always use a personal firewall.

  • Remote access users. All remote users connect to the main office by using Remote Web Access, Outlook Web Access (OWA), Exchange ActiveSync, or a VPN connection. Remote Web Access is the most useful if users need to access their desktop applications and resources, and OWA and the ActiveSync® technology are best for light e-mail usage. A highly useful access solution is to use Outlook to connect to Exchange by using RPC over HTTP. This gives remote users the benefits of the full Outlook product without requiring a VPN connection.

  • Folder redirection and Volume Shadow Copy Service not recommended. For remote users connecting to the main office, most connection types are too slow to allow folder redirection to a server in the main office. This means that enabling these features in Windows SBS for remote office users is counterproductive and should not be done.

This centralized scenario is simple and convenient. All of the important servers and services are at one location where you can maintain and troubleshoot them easily. For remote sites you can enable Remote Desktop and work through most problems without visiting the site. The disadvantage is that remote client computers are not backed up automatically. Unless users are diligent about backing up their data frequently, any event that causes an individual's data loss is most likely not recoverable.

Windows Small Business Server in the main office, one or more servers in other offices

Larger businesses or ones with more complex business operations are the ones most likely to have multi-site server deployments. This scenario, shown in Figure 2, is by nature more expensive, due to the increased hardware and software requirements, and Windows SBS might limit network design choices and restrict the ability to construct the most efficient managed network. If you find this is the case, consider purchasing the Transition Pack and moving your customer to the standard versions of Windows Server 2003, Exchange Server 2003, ISA Server and SQL Server 2005. (ISA Server and SQL Server are included only in Premium Edition.)

Typical customer scenario

Customers with multiple-server, multiple-site operations usually have greater remote office independence. They often have their own LOB applications and data that they need to manage and control. Interoffice communication ranges from ongoing and frequent (such as regular updating of price lists, inventory, or financial data) to intermittent (occasional e-mails between users or departments). Examples of multiple-site businesses include regionally-owned businesses and franchises and independently owned stores that connect to a main office for regular information updates. Law offices, medical organizations, tax preparation companies, and other professional service companies often fall into this category.

Note

The longer the remote offices have been functioning as separate entities, the more planning and preparation you need to do. Data replication, data normalization (removing duplicate or obsolete entries from common applications), and business process integration become very important. If you specialize in a particular business segment or deploy vertical-market solutions, you can use your expertise to help the customer with data integration issues.

Putting the pieces together

You might not have the luxury of planning and deploying a multiple-server or multiple-site operation from scratch. In some cases you are working backward, looking to integrate multiple servers or sites into a single cohesive network. Conduct a survey with customers (including those in remote offices) to determine what you have to work with and what needs to be implemented.

  • Windows SBS centrally located and managed. You might even have an on-site IT person who is available to assist you with routine Windows SBS tasks.

  • Member servers at remote offices. Remote offices might need a member server that provides file and print services. These offices are also likely to have local LOB applications and data they use to conduct their business. You might need to centralize these applications and data in the main office, or you might need to keep them separate but manage them remotely, depending on the business workflow.

  • Domain controller at remote offices. Remote offices might already have a domain controller running. This helps reduce authentication time and it provides security services, but if it is part of its own domain you probably need to demote the server, join it to the Windows SBS domain, and then promote it to domain-controller (DC) status.

  • Greater need for high-speed dedicated network connections. It is possible to handle remote office connectivity across a DSL or cable modem. You can route authentication, file sharing, e-mail, and application traffic to the main office over these connections, depending on how many users and what type of traffic is involved. Find out how the customer wants to handle the increased traffic, and consider setting up a VPN connection or a leased line to connect each remote office to the main office. If data replication from the main office to the remote office (or vice versa) is a requirement, then a dedicated high-speed line is a must.

  • Remote Web Workplace, OWA, or ActiveSync usage depends on LOB application location. How do remote users access the network? Work with your customer to decide who should have access to which resources, and from which office.

  • Local data backup a must. If remote offices maintain servers and data, you must plan for a backup and restore method. Folder redirection and Volume Shadow Copy Services are possible over a WAN but you are likely to find that the performance is not acceptable. In many cases, you are better off creating a local backup system for remote data. Online backup over the Internet to a third-party data-storage provider is also available to supplement local backups.

Large remote-office deployments are inherently trickier, with more factors to consider, and it becomes difficult to recommend only one right way to integrate remote office servers with an existing Windows SBS network. The more things can be centralized, the better it is both for the customer and for network and application management.

Note

If the cost to centralize applications and services is too high for the customer, both in terms of hardware and time needed, propose a multi-step approach, where offices are integrated with the Windows SBS domain one at a time. This helps minimize any business disruption, and it spreads the integration costs over a longer time period.

Windows Small Business Server in all offices

This third option, shown in Figure 3, isn't really an option for Windows SBS customers except for offices that are loosely related but separately managed, such as joint ventures, supply chain partners, or independent subsidiaries. There might also be legal or business reasons for keeping the business functions separate, so you need to be aware of confidentiality and trade-secret agreements when discussing technology connections between the sites.

Typical Customer Scenario

Each office has its own server that is running Windows SBS and each office is separately managed, so there is little or no centralized management. There may be some interconnection for business purposes and there may be extranet access required for the business partners. With this configuration, you are often the unifying link between the organizations and are therefore responsible for ensuring that appropriate access and permissions are set up between sites.

Putting the pieces together

Some customers might encourage you to install Windows SBS in each office. Despite the apparent cost savings, technical factors weigh against it.

  • Separate Windows SBS in each office. This sounds great and cost-effective, but it means that there are separate copies of Exchange Server, Windows SharePoint Services, and Internet Information Services (IIS) at each office, which is usually too much for the number of users and applications supported. Costs are increased, and the redundancy does not provide any advantages.

  • No interoffice trusts or subdomains permitted. Without benefit of Active Directory's ability to work with multiple forests, simple functions such as searching for a user's name or extension number at another office are not permitted.

  • LOB applications are different at every office. As with the core Windows SBS applications, there is expensive and time-consuming redundancy built into remote-office overhead and management. The business cannot achieve economies of scale with separate copies of identical applications at each office.

  • Most difficult to administer locally or remotely. Each office must be configured separately, and users in one office do not have any permissions in another office, unless you create duplicate accounts for them. Duplicate, repetitive management is introduced.

  • Limitations on user licensing. Windows SBS user CALs do not allow a user to access a server that is running Windows SBS at another site. You need to purchase additional CALS for users who need to access resources at each additional site.

A significant difficulty with this arrangement is that there are no centralized management tools available for you as the partner. Setting up and maintaining the appropriate levels of security, user management, and service provisioning is labor-intensive. If you have customers that insist on this type of interrelationship, then you should recommend that they invest in Windows Server 2003 and related applications like Exchange.

Non-technical issues applicable to all scenarios

Throughout this document there have been suggestions that multiple-server, multiple-site deployments are not only about the technology, but also reach outside the technical realm into the world of business and interpersonal relationships. Some non-technical issues that affect these scenarios are as follows:

  • Consider the business needs and processes. It is not enough to sell a technical solution as being better than what the client currently has. You must show how the solution helps the customer achieve their business goals. In the same vein you must show how you are improving their ability to do business, either through reducing cost of ownership or providing a competitive advantage through quantity (more information), quality (better information), or immediacy (faster information). You should understand what the customer's pain points are and what the customer's workflow is trying to achieve.

  • Politics dictate solutions as much as technology does. In multi-site businesses, the political interrelationships can have as much bearing on your eventual deployment plan as the technical solution does. If one site's manager doesn't trust another site's manager, that has security and access implications for your solution. Be discreet when inquiring about the political weather, and endeavor to be neutral in any disagreements between sites.

  • Engage the users early and often. One of the biggest complaints from users is that they "never know what is going on." Discuss your ideas and plans for the rollout with the affected parties, especially if you are changing the way they do business. Work with end users to find out what their ideas are, and make them a part of the rollout plans. And when you are bringing new systems on-line, make education and training a part of your customer support plans.

  • Be up front about the licensing implications of your plan. Let the customer know what the approximate costs are to, for example, give everyone a license to a terminal server that is running an LOB application. Chances are that the customer will decide that fewer employees need access to it than they initially planned and that exporting a report into an Excel spreadsheet might be sufficient for most users. If business processes are being reworked due to cost, consider bringing in a specialist on business-process software. You might have an opportunity to move the customer to a more robust software package with features that are needed in the business.

  • Document the as-built solution. As part of your solution, you should create site-specific notebooks with important contact numbers, network diagrams, backup and restore procedures, and disaster recovery information. If you become unavailable, can the customer or another person from your organization address a sudden crisis at a customer's remote office? If not, start writing.

For more information about technical resources for Windows SBS, see the Microsoft Web site (https://go.microsoft.com/fwlinks/?LinkId=29938).

For updated product documentation for Windows SBS, see the Microsoft Web site (https://go.microsoft.com/fwlinks/?LinkId=19041).

For more information about the community for Windows SBS, see the Microsoft Web site (https://go.microsoft.com/fwlinks/?LinkId=16919).