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 (http://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.
  
  

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.

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

• 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.
  
  

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.
  
  

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 (http://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 (http://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 (http://go.microsoft.com/fwlink/?LinkID=58914).

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.

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 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 (http://go.microsoft.com/fwlink/?LinkID=17050).
  
  

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.

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.

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.

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.

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.

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.