Your source for the news, opinions, and reader reaction on the industry’s hottest controversy.

In This Chapter

• Knowing the Client Base

• Planning the Network

• Planning the Storage Layout

Deploying Small Business Server 2008 into a client network is more involved than simply installing the software on a server and plugging it into the network. As such, when planning for an SBS 2008 installation, hardware requirements are not the only factors that need to be addressed. Merely running the SBS 2008 installation process and providing the correct network settings will not guarantee a successful deployment for a business.

There are two general categories of people who install SBS 2008—those who install it for their own use, and those who install on behalf of others. No matter which category you fall into, there are a number of preparatory steps you need to take prior to inserting the installation media and powering on the new server. This chapter covers the basic hardware guidelines for running an effective SBS 2008 server, as well as the other factors that need to be addressed prior to implementation.

Knowing the Client Base

Unfortunately, there are no hard and fast rules that you can use to determine what resources you need to implement an SBS 2008 server. The implementation needs depend on how the system will be used. An SBS 2008 server for a 20-person company that primarily uses the system for e-mail and file and print services may be configured very differently from a 10-person company that has high-volume line-of-business applications with a large SQL database that integrates with Exchange.

Getting to know the business needs and the day-to-day manner in which the employees operate will help you better plan the implementation of the SBS 2008 network. The following are some basic questions you will likely need to be answered. A more detailed examination of other aspects of the installation follows. Questions that should be asked before attempting an SBS installation include the following:

• How many users are in the organization?

• How many devices are in the organization?

• What is the geographic layout of the organization (one site, multiple sites, and so on)?

• What desktop technologies are being used (Windows XP, Windows 2000, Windows 98, Mac OS X, Mac OS 9, Linux, and so on)?

• What is the connection to the Internet?

• Does the organization have an existing domain name for the web?

• Does the organization have an existing e-mail domain name and provider?

• Does the organization have users who want to work remotely, either from home or while traveling for business?

• Does the organization want to restrict or track access to external web sites?

• How many printers are in the organization? How many of them need to be shared?

• Does the organization have a fax machine? Will the organization be using the fax services of SBS?

• Does the organization have or need a terminal server?

Understanding How the Server Will Be Used

With previous versions of SBS, everything was on one box, so the determination of how to build and configure that box was fairly straightforward. As long as you provided enough CPU power, RAM, and disk space to accommodate the business needs, you would be in pretty good shape.

With the second server option in SBS 2008 Premium, this planning gets a little more complex. In some cases, installing everything on one box may still be feasible, even if SQL is needed for a line-of-business application. In some cases, the ability to split SQL off to its own server gives greater performance for the database and the application that relies on it. In some cases, the business might have a need for deploying Terminal Services on the second server and not use SQL at all. The end result of this more complex set of possibilities is that the approach to determining appropriate resources levels becomes more complex as well.

As a result, this book can offer only general guidelines for the various configuration options for your SBS server. The information contained in this chapter focuses on the core components of SBS, Server 2008, Exchange 2007, Sharepoint Services 3.0, WSUS 3.0, and so on, and not on any third-party applications or resources. If tools other than the core SBS components will be installed on the main SBS server, you need to work with the vendor to determine the appropriate resources required to support those additions on the main server.

Planning for Correct Licensing

As with previous versions of SBS, SBS 2008 has some basic restrictions for how the server can be used in a network. The basic license for SBS requires that the core components reside on the SBS server. This means that Exchange, IIS, and Sharepoint have to remain on the SBS server. Even though the Premium Edition provides a second server operating system, the SBS license prevents the core components from being installed on the second server. SQL is the exception to this rule, as the SQL software bundled with the Premium Edition can be installed on either server.

One common misunderstanding about the SBS product space relates to using more than one server in an SBS network. SBS has always allowed for additional servers to be present in the SBS network, even as Domain Controllers. The only restrictions about additional servers is that the SBS server must have all the core components installed on it, and the SBS server must hold the master roles for Active Directory. As long as those items are met, the SBS network can have as many additional member servers and Domain Controllers as is reasonable for a small network. Many consultants have installed additional servers in SBS networks to keep line-of-business applications off the SBS server, and the inclusion of the second server OS license in the Premium Edition of SBS 2008 recognizes the practicality of this approach.

Access to the SBS 2008 server is granted through a Client Access License, or CAL. Microsoft has used the concept of CALs for many years to govern access to software resources, and the SBS product line has followed in this design. The SBS product uses a different type of CAL from other Windows Server products, however, because it encompasses a number of technologies. For instance, in a “traditional” server setup running Windows Server 2008 and Exchange Server 2007, each user accessing the network would need a Server 2008 CAL and an Exchange 2007 CAL to be properly licensed to access the file and print services on the server, as well as the mail services in Exchange. The SBS CAL, however, covers access to all the bundled technologies, so separate CAL purchases are not needed.

Microsoft has changed one aspect of CAL purchases with SBS 2008 that will be welcomed by sites needing more than five CALs. SBS 2008 still has the initial five CALs bundled with the product, but additional CALs can be purchased singly instead of in 5- or 20-CAL packs, as with previous versions. So, those sites needing 17 CALs total can purchase an additional 12 CALs instead of an additional 15 to meet their CAL requirements.

Standard Versus Premium CALs

One other important difference in SBS 2008 from previous versions of SBS is that there are separate CALs for the Standard and Premium products, specifically in relation to SQL. In SBS 2003, a single SBS CAL covered access to both the Standard and Premium products, meaning that you were essentially buying the license for the premium technologies even if you did not have the Premium version of SBS 2003 in production.

Microsoft has addressed this concern by splitting the CALs along the SQL lines and lowering the cost of the Standard CAL. There is a potential for confusion in the way that Premium CALs have been positioned. If SBS 2008 Premium is deployed in a network, you do not necessarily need to purchase Premium CALs for all users and devices in the network. You only need to purchase a Premium CAL for a user or device that will be accessing the SQL resources. Table 2.1 breaks down the four CAL types with SBS 2008.

TABLE 2.1 SBS 2008 Client Access Licenses

As an example, suppose you have 20 users on your SBS 2008 Premium network. You have the SBS 2008 SQL server installed, and 8 of those users need to access the SQL resources. In this instance, you would need 12 Standard User CALs and 8 Premium User CALs. If you allocate the five included CALs from SBS 2008 as Premium CALs, you would need to purchase only three Premium CALs and 12 Standard CALs.

In another example, you have purchased SBS 2008 Premium to get the second server license and will not be installing or using SQL. In this instance, you would not need to purchase any Premium CALs.

In short, you need to provide a Premium CAL for every person who will be using SQL on the network, and all other users can make use of Standard CALs.

When to Use User CALs

For the majority of SBS 2008 installation, User CALs are the proper CAL to use. A User CAL is assigned to a person, and authorizes that person to access any of the network resources managed by the SBS 2008 server from any device. If an employee has a workstation in the office, a cell phone/PDA that accesses his or her mailbox, and a workstation at home used to get into Outlook Web Access or the Remote Web Workplace, a single User CAL assigned to that person covers his or her access from all of those devices and locations. If that person were not covered by a User CAL, each device that person used to access the server would need to have a Device CAL assigned to it. In this example, that would mean three Device CALs would be needed: one for the PC at the office, one for the cell phone/PDA, and one for the workstation at home. If that person attempted to use Outlook Web Access from another device—say, a kiosk at a trade show or a relative’s home computer—that person would be accessing the server without a valid license.

When to Use Device CALs

A Device CAL makes sense when there is a single resource that is shared by multiple people. The most common example of when to use a Device CAL is for a facility that runs work in shifts, and each computer may have two or more people who use that resource during their shift. If, for example, a facility has 30 workstations on a plant floor and the facility runs three shifts, there would potentially be 90 people accessing the server from those resources. Acquiring 90 User CALs for these people would go beyond the licensing limit for SBS. However, only 30 Device CALs would be needed to cover these devices, keeping well within the SBS licensing restrictions.

However, each person accessing those workstations would not be allowed, from a licensing perspective, to access the SBS resources from another workstation that is not covered by a Device CAL. This means that the people accessing the workstations in this example would not be able to use Outlook Web Access from home and still be covered by adequate licenses. For some facilities dealing with shift work, this might be a reasonable approach. But for people who are regularly accessing SBS resources from a number of devices, the Device CAL approach can become very limiting very quickly.

---

Changes from SBS 2003—Licensing Enforcement – One significant difference in SBS 2008 from previous editions is that there no licensing enforcement engine runs on the server. As with Windows Server 2008, the standard paper license enforcement is all that is needed for SBS 2008. No tools in the software track current license usage, maximum license usage, or whether user or device CALs are being used.

By removing the licensing enforcement engine from the product, it is less painful for system administrators to deal with licensing issues (that is, no need to install license codes on the server, so no worrying about backing up license data in case of disaster or data corruption, no users prevented from logging into the server because there are not enough licenses installed, and so on). On the other hand, it does allow for more abuse of licensing, and no one is sure at this point how that will play out over the life of the product. It will still be important for the consultant and the business to keep track of the licensing paperwork to be able to document appropriate licensing for the server and network should the business be audited.

---

When to Use Terminal Server CALs

Because the second server license in SBS 2008 Premium could be used to set up a dedicated Terminal Server on the SBS 2008 network, a word about Terminal Server CALs is warranted. The SBS 2008 CAL does not cover access to terminal services on the second server. If you choose to implement the second server as a Terminal Server, or if you bring in another server licensed outside of the SBS 2008 product license to run as a Terminal Server, you need to acquire Terminal Server CALs for the users who access the server.

For a Terminal Server based on Windows Server 2008, there are two types of CALs that are supported for providing access to the Terminal Server—User and Device. As with the SBS CAL, using a Terminal Server User CAL will likely be the most commonly-chosen CAL type for the majority of Terminal Server implementations. As with the SBS User CAL, the Terminal Server User CAL enables a user to access the Terminal Server from any device. A Terminal Server Device CAL allows only that specific device to access the Terminal Server. As with earlier versions of Terminal Server implementations, Device CALs are tracked in the Terminal Server Licensing Server, but User CALs are not.

The bottom line for anyone wanting to add a Terminal Server to the SBS 2008 network is that you need to purchase and install appropriate Terminal Server CALs in order to meet Microsoft licensing requirements.

Planning the Hardware

Once you have an understanding of how the server will be used in the environment, you can begin determining the specifications for the hardware that will be used in the box. As mentioned earlier, the requirements of any third-party applications that might be installed and run from the server are beyond the scope of what can be addressed in this book. However, the following sections discuss the limitations of the hardware that can be used in the server and provide some guidance as to the minimum specifications needed in general cases.

Processor

SBS 2008 is built on Windows Server 2008 Standard Edition, and inherits the hardware requirements for that OS. Server 2008 can run on one to four processors. With current processors having one to four cores, you could build a server with up to 16 cores, as long as you are comfortable with the pricing. Server 2008 requires a minimum 1.4GHz processor speed for 64-bit processors, but a minimum 2GHz processor is recommended.

The second server license that comes with SBS 2008 Premium can be installed as the 32-bit or 64-bit version of Windows Server 2008. The only difference between the two is that the minimum listed CPU speed for the 32-bit version of Server 2008 is 1GHz. Still, a minimum of 2GHz for the 32-bit version of Server 2008 is recommended.

Memory

The SBS 2008 server can use between 3 and 32GB of RAM. The recommended minimum RAM for the SBS 2008 server is 4GB, and if any third-party applications will be installed on the box, installing more than 4GB of RAM on the SBS server is highly recommended.

If the second server license from the Premium Edition is used, both the 32-bit and the 64-bit versions of Server 2008 require a minimum of 512MB of RAM, but 2GB of RAM is the minimum recommended amount for the second server. Again, the actual use of the second server license determines how much RAM will really be needed on the system.

Related Hardware

Because the SBS 2008 installation media (both Standard and Premium Editions) are on DVD discs, all servers in the network need a DVD reader to be able to install the software. Having a writeable removable media drive is not required, and if you choose to try to use a writeable drive in the system, make sure any writing software you install is compatible with Server 2008.

A video card and monitor capable of displaying an 800×600 resolution is required. Most of the software tools in SBS 2008 can be run in this resolution, but a 1024×768 resolution or higher is recommended. You could also select a video card that is capable of handling the Aero interface, but that is not required.

At least one USB 2.0 interface is needed on the server. This is to connect the external disk drive for backup, if the built-in backup utility will be used on the server. Additionally, a FireWire (IEEE1394) interface could be used to connect an external hard drive for backup as well.

Planning the Network

After you have the licensing counts established, you can focus on the network implementation. This aspect of the installation covers a number of networking issues, from connecting to the Internet to internal IP address schemes to internal and external domain names. Each piece of this puzzle has a significant impact on the way the server is set up, and because some networking changes are difficult to impossible to change down the line, it’s best to spend some quality time in this area to make sure that you can get it right the first time.

Changes in Network Options from Previous Versions

All previous versions of SBS supported the ability to use the SBS server as an edge device and a network router, but that is no longer the case with SBS 2008. Due to changes in the underlying network architecture with Server 2008, SBS 2008 can no longer be used in a two-NIC configuration where the SBS server sits between the internal network and the external network.

This change has caused a bit of an uproar in the SBS community because of the related changes. ISA is no longer included with the SBS product, the first time in any release of SBS. The previous best practice of using SBS as a router between the internal and external networks, even if it was not an edge device, no longer applies. Consultants who had built their practice on the security provided by using the SBS server in this way have to rework their own approach to network security.

This change simplifies the network layout in many ways, but it also makes it more complex in others. The following sections outline the standard network configuration for the SBS 2008 network, as well as the best practice recommendations for network implementation.

Connection to the Internet

SBS 2008, in its single-NIC configuration, expects that it will access the Internet in the same way that the other workstations on the network will—through a firewall/router at the edge of the network. Historically, this has often been through a consumer-class DSL or cable modem or other consumer-class router device. And for those who used the SBS server as a router (with or without ISA), this might have been a reasonable approach. But now that SBS 2008 is a node on the network just like any other workstation, those who are implementing SBS 2008 networks should give serious consideration to a business-class device at the edge, especially one that can control outbound traffic as well as inbound traffic.

There are a number of business-class firewall devices on the market as standalone hardware devices. Those who are comfortable with ISA as a solution can still implement an ISA solution, but it must be on a separate computer. Regardless of which approach is chosen, be sure to budget appropriately for the edge device, as a business-class firewall is not going to be found in the sub-$100 range of consumer-class devices. There are a number of business-class devices ranging in price from $300–$1000, with some devices having basic inbound firewall features and others offering Active Directory–integrated outbound filtering, for example. The choice of which firewall to use will likely be heavily based on personal preference or brand loyalty, but the general consensus is that a consumer-class device does not provide the level of protection most businesses want or need.

---

USING ISA IN THE SBS 2008 NETWORK – At the time of publication, the ability to run ISA on an edge device in the SBS 2008 network has some key limitations. The current version of ISA, ISA 2006, cannot be run on Windows Server 2008. That means that the second server license included in SBS 2008 Premium cannot be used as the OS for the computer running ISA. A separate Windows Server 2003 license would be needed to run on the ISA device.

Microsoft will have a whitepaper (https://go.microsoft.com/fwlink/?LinkID=122167) on configuring ISA on a separate server as an edge device for the SBS 2008 network. Because there will be no wizard integration for the configuration of ISA, the ISA configuration must be performed manually. For those who want to use ISA as the edge device, refer to the Microsoft whitepaper on the topic.

---

IP Address Ranges

SBS 2008 expects that the IP address for the network will be a private, non-routable IP address range. During installation, SBS 2008 will look in several 192.168.x. subnet range locations (based on common defaults) for the firewall device and configure the network accordingly. However, this does not limit the SBS 2008 network to only use the 192.168.x.x address ranges for the local network. If other private address ranges are used, they must be configured manually. See Chapter 3, “Installing and Configuring SBS 2008,” for more information about configuring the network settings on the server.

---

BEST PRACTICE—SELECTING THE INTERNAL NETWORK ADDRESS RANGE – If you have the option and the ability to adjust the internal network address range when installing SBS 2008, you should select an address range that is not a “default” address range. Many recent firewall devices use a 192.168.0.x or 192.168.1.x address range for the internal network connection. If a user wants to connect into the network via VPN, and his or her home router also has the same internal subnet, the VPN connection will not work correctly (for more information about setting up a VPN connection using SBS 2008 tools, see Chapter 6, “Remote Web Workplace and Other Remote Access Tools”). Moving the internal subnet away from these router defaults will help avoid VPN access problems down the road.

VPN access can also be an issue for the IT consultant who has many different networks that he or she supports. Even if the consultant has a different internal network range than a client site, if he or she needs to connect to more than one client site at a time, and those two client sites have the same IP network address range, communicating with the client sites will be problematic.

To avoid these issues, select a unique internal network address range for each SBS 2008 installation, where possible. When installing into an existing peer-to-peer network, or when setting up a network for a new business, this can be done when first setting up the firewall. When installing into an existing network, especially one with an existing server, the change may be more difficult to make. If there are a large number of devices with static IP addresses, you might opt not to make the change for that site.

---

DHCP Configuration

Many small networks use DHCP to allocate IP addresses to network resources, and this is the expected practice with SBS 2008 as well. SBS 2008 wants to install a DHCP server as part of the Windows services, but the DHCP service will shut itself down if it detects another DHCP server (provided by the firewall, for example) on the network to avoid DHCP confusion and the possibility of assigning duplicate IP addresses to network devices.

---

BEST PRACTICE—USE SBS AS THE DHCP SERVER FOR THE NETWORK – In cases where an SBS 2008 server is being introduced to an existing network, there might already be a functioning DHCP server on the LAN. Any devices that are providing DHCP services should have the DHCP function disabled so that the SBS 2008 server is the only device that provides dynamic network configuration information to the workstations.

The reasoning behind this is simple. When the SBS 2008 server is configured using the setup wizards, the proper network configuration information is put into the DHCP server settings and provided to the clients. When the SBS 2008 server is not allowed to serve DHCP, it falls on the network administrator to manually configure the DHCP server settings on the device. Chapter 4, “DNS, DHCP, and Active Directory Integration,” covers the default DHCP settings for an SBS 2008 network in greater detail. However, when planning a new SBS 2008 implementation, the plan should include making use of the SBS 2008 server’s DHCP services in place of any other DHCP services on the internal network.

---

DHCP can also be used to assign “static” IP addresses for network devices that need to have a consistent IP address, such as a network printer. The DHCP service on the SBS 2008 server can be used to create IP address reservations for these devices to ensure that they receive the same IP address every time they are restarted. Again, more information about this process can be found in Chapter 4.

Public and Private Domain Names

The argument over whether to use a public domain name (that is, smallbizco.net) as the internal network name for an Active Directory network is a passionate one for most parties. Those who believe a public name should not be used internally will generally not be swayed to think otherwise. Those who believe that the public name should be used internally will generally not budge from their position, either.

Microsoft’s recommendation, and the way the wizards are built, is to use a private, non-routable domain name for the internal network, and once again Microsoft has chosen the .local namespace as the default for SBS 2008. The installation process does have options for choosing a different internal domain name (see Chapter 21, “Advanced Installation Options”), which can be a public domain name or a different private domain name. There is not any reason that one has to be chosen over the other, but those who go with a standard installation end up with a .local internal domain name.

The only caveat to using a public domain name for the internal domain name is that the DNS records for any public services, such as the company’s web site, have to be manually maintained in the SBS 2008 DNS configuration. If the web host changes to a different public IP address, someone has to update the DNS records for the www site in the SBS 2008 DNS configuration to match the new IP address. For those who do not want to manage DNS at this level, or who are unsure how to do so, a private domain name should be used internally.

---

NOTE – The .local and .lan top-level domains (TLDs) are not reserved domains. That means those domains could be put into service at some point in the future and become routable domains. Four reserved domains are identified in RFC 2606 (https://https://www.ietf.org/rfc/rfc2606.txt) for testing: .test, .example, .invalid, and .localhost. Although it’s unlikely that the domains .local and .lan would be used as live top-level domains in the near future, a systems administrator who wanted to be absolutely certain that his internal domain would never be publicly routed could use one of the four reserved domains. Doing so would present a special set of challenges, because the .localhost name has special functions for referring back to the local machine, and the other names do not imply permanence.

---

Planning the Storage Layout

Determining the appropriate storage layout for the SBS 2008 server is probably the most complex process in the planning stage. So much of the storage requirement depends on the data needs for the site implementing the new server that it is difficult to make a generalized recommendation for what an appropriate storage layout should look like. The remaining sections in this portion of the chapter cover terminology and some baseline recommendations for bare minimum storage requirements. Depending on the level of usage expected on your server implementations, these baseline recommendations may be insufficient for a final deployment.

Changes in Storage from Previous Versions

Because SBS 2008 is built on updated versions of the included components, there are a number of differences in the way the product handles storage needs. The amount of overall storage capacity needed in SBS 2008 is higher than SBS 2003. Where SBS 2003 could originally fit in a 12GB C: partition, SBS 2008 requires a 60GB C: partition. Exchange 2007 now allows for stores of larger than 75GB and can have multiple stores instead of one, which has implications for total storage capacity as well as disk performance. The following sections cover possible approaches to designing storage for an SBS 2008 server given these and other factors.

Multiple Partitions Versus Multiple Spindles

Finding the ideal storage layout is a giant puzzle with a number of key pieces. In the end, the layout implemented is the result of a number of compromises with these pieces.

Ideally, some suggest that an optimum SBS installation would have three spindles, or separate drive mechanisms. One spindle would contain the OS and key applications, one would contain the Exchange log files, and one would contain the Exchange mail databases. This layout would be optimized for performance because the type of disk access needed to read and process the Exchange log files (sequential) is different from the disk access needed to process the Exchange databases (random). User data could be stored on the spindle with the Exchange logs because most user data would be read and written sequentially, and any system-wide databases would be stored on the spindle with the Exchange databases because they would use a similar type of drive access.

The cost of such a layout, however, would keep a small business from implementing it. To achieve any level of fault tolerance, you would need to at least mirror each of the spindles, a total of six drives. If performance were truly the primary consideration, the two non-OS spindles would likely be a RAID 5 or RAID 50 array, jumping up the number of disk drives to at least eight.

Although SBS 2008 will install and run on a single spindle with multiple partitions, if disk performance is a concern for the operation, the server should be built with a minimum of two spindles—one for the OS and one for the remaining data. At a minimum, both spindles need to be mirrored, but a mirrored OS spindle and a RAID 5 (or similar) array for the data.

If a single spindle is all that can be used in the server, the space in the disk should be partitioned into at least two partitions. The C: partition should contain only the operating system and key applications. Dynamic data should be kept off the C: partition to protect against accidental filling of the disk. Should the C: partition get completely full, the server could crash unexpectedly and cause data problems in addition to downtime. As discussed in Chapter 3, “Installing and Configuring SBS 2008,” the default installation places all data and applications on the C: partition, even if multiple partitions or drives are available during setup. Only after setup can you move dynamic data off the C: drive and onto other storage areas of the server.

Minimum Partition/Spindle Sizes

The SBS 2008 installation routine requires a C: partition of at least 60GB before it will perform the installation. This is a far cry from the 12GB C: partition that OEM installs of SBS 2003 regularly used. But a 60GB C: partition still may not be large enough, depending on your server configuration. The following sections provide some baseline suggestions for how to devise minimum partition sizes for your server. These sections assume a two-disk or two-partition installation of SBS 2008.

Sizing the OS Partition

One of the significant challenges in supporting existing SBS 2003 installations is maintaining a server with a very small C: partition. When SBS 2003 was originally released, a 12GB C: drive seemed like it would be large enough. When SBS 2003 SP1 was released, a 20GB C: partition seemed like an appropriate recommendation. With SBS 2003 R2, a 30GB or larger C: partition was recommended. The same progression may well happen over the lifespan of SBS 2008, so when reviewing these minimums, understand that they might not be appropriate in a few years; you should try to have as large a C: partition as reasonably possible.

As for the minimums, SBS 2008 installs and uses about 24GB of disk space on the C: drive after all the dynamic data has been moved to other partitions. The remaining space can be used by new applications, OS log files, and swap file storage.

When planning the size of the C: partition, the swap file is probably the single biggest factor to consider; this has not been the case in previous versions of SBS. Microsoft recommends a swap file of 1.5 times the size of physical RAM installed in the server. Because the 64-bit OS can access 32GB of RAM, this could be significantly more storage than IT consultants have been accustomed to using.

To help gauge how much disk space could be used by the basic installation, plus swap file and memory dump free space, Table 2.2 lists the recommended sizes for swap file and minimum total disk space for C: based on the amount of RAM installed in the system.

Table 2.2 OS Partition Size Minimums

If you expect the usage of space on C: to grow more than 20GB in the life of the server, you would need to adjust the initial partition size accordingly. This also highlights the importance of understanding how your RAM needs in the server might increase over the life of the server. If you initially install the server with the minimum 4GB of RAM, and then discover in a year that you really need to have 16GB for the server plus new applications, the 60GB minimum C: partition might not have enough space to handle the increased swap file size and the other applications. Although you can move all or part of the swap file to a different partition, you will not get a crash dump file generated if the swap file is not stored on the C: partition. This is an important consideration because a crash dump can be used by support professionals to help determine the cause of a system crash if the cause is not evident from the crash code itself. If a crash dump is not created on a system failure, it eliminates one possible tool for identifying and resolving the issue.

Sizing the Data Partition

If trying to determine an appropriate size for the OS partition was a bit vague, coming up with an appropriate minimum size for the data partition is even more nebulous. The guidance for partition size in this section is based upon having sufficient free space on the data partition to perform a repair of the Exchange databases, should such a repair be needed. In general, Exchange needs 1.2 times the size of the database file in free space to perform the repair (specifics of the Exchange database repair process are detailed in Chapter 10, “Exchange Disaster Recovery”). If you have a 60GB mail database, you need around 72GB of free space available on the server to be able to repair the database.

Obviously, trying to figure out how large your mail databases could get over the next few years, and then allocating space not only for the database but the repair space, is going to require a bit of guesswork. The bottom line is that you need to allocate as much disk space as you can for future growth.

Fault Tolerance

Fault tolerance defines a system’s capability to recover from a failure of hardware or software in such a way as to minimize the impact on the system. In most computer systems, hard disk drives are the first components to fail because they have the most moving parts and are accessed constantly while the system is powered on. Knowing this, most server systems are built with some form of fault tolerance for the disk system to minimize the impact when a disk drive fails.

SBS servers can achieve fault tolerance for the disk subsystems using either hardware or software solutions. Hardware solutions rely on specialized disk controllers to handle the management of the fault tolerance implementation selected. These controllers are more expensive than standard disk controllers. Hardware fault tolerant solutions provide either a mirrored solution—where two disks of the same size act as one—or a RAID (redundant array of inexpensive disks) solution—where three or more disks function as a single drive. See the next section, “RAID Types,” for a more detailed explanation of RAID arrays and their functions.

---

HARDWARE VERSUS SOFTWARE FAULT TOLERANCE – Microsoft servers can implement mirrored and RAID-like solutions via software, avoiding the expense of a specialized disk controller card. Through Disk Manager, partitions of the same size can be mirrored by the operating system or combined into a RAID.

Although more expensive, hardware-based fault-tolerance solutions are preferred over the software solutions for one reason—performance. Although the software implementations Microsoft provides for mirroring and RAID are less expensive from a hardware standpoint, the amount of overhead involved in managing the mirror or RAID has a significant impact on server performance.

---

Traditionally, SCSI or Serial-Attached SCSI (SAS) RAID controllers are the devices of choice for fault-tolerance solutions for the disk subsystem. Over the last few years, many servers have been built using Serial-ATA (SATA) drives attached to RAID controllers for a lower-cost solution than SAS. The lower cost does come with a price, however. SAS drives have a greater data throughput than SATA drives, so for servers where disk I/O is going to be critical, SAS should be chosen over SATA.

RAID Types

RAID—which stands for redundant array of inexpensive disks or redundant array of individual disks, depending on whom you ask—is a specification for combining multiple disk units of the same size into a single logical unit for the purpose of improving read/write performance, providing fault tolerance, or both. Although there are a number of RAID specifications, only a few are actually used in practice. Table 2.3 lists the most commonly used types of RAID and describes their functions, advantages, and disadvantages. The number of disks needed for each RAID type is listed as the total available disk space for each type. (The values are based on 80GB drives used as individual elements in the array.)

One other advantage of a RAID configuration is that most RAID controllers can accommodate a hot spare—an extra disk drive on the controller that automatically becomes active if one of the other members of the array fails. Plus, when combined with a hot-swappable drive technology, the failed drive can be removed and replaced without bringing down the server. The upside is obvious because the system automatically rebuilds the necessary information on the newly activated disk if one fails and reduces the time the server spends without fault tolerance due to the failed drive. The downside is the overhead associated with rebuilding data onto the newly added drive, and that can be observed by end users during the rebuilding process. Use of a hot spare is more commonly found with RAID 5 implementations but can be used with a mirrored configuration as well.

TABLE 2.3 Commonly Used RAID Types

Backup Technologies

One of the most significant changes to backup in SBS 2008 actually comes from a change in Server 2008—no tape drive support in the native backup tools. The backup tools in Server 2008 make use of an imaging technology that writes backup data to hard disk rather than tape, and SBS 2008 inherits that change. Now, this does not mean that you cannot use a tape drive to do backups in SBS 2008; it simply means that the native tools will not write to the tape drive. If you want to use tape technology, you need to use a third-party solution for that.

Making the correct decision about which backup technology to use is important during the planning stage. External USB storage drives have become popular in the last few years, but those devices are far from the only option when looking into SBS 2008. Most name-brand OEM server manufacturers include multiple USB ports on their server configurations, but a few are beginning to include other ports on the server as well. Some servers can be configured with a Firewire (IEEE1394) interface, and others have started including eSATA connectors. Although each of these technologies has their own individual advantages when compared with the others, they all have a similar challenge when dealing with SBS 2008—how to safely disconnect the external drive from the server to rotate the backup media.

In addition, you need to have an external backup disk that is at least as large as the combined capacity available on the server to successfully back up the server. If there is going to be a large amount of data churn on the system, you may want to look at backup devices that have double or triple the capacity of the internal storage to ensure that there is room for incremental backup files during the backup process.

For a complete discussion about backup technologies and how to use the native tools, see Chapter 17, “Managing Server and Workstation Security,” and Chapter 18, “Backup and Disaster Recovery.”

Summary

Now that you’ve looked at all the options you need to consider for the design of the server and the network, you should be ready to prepare a proposal that outlines how the installation should look. Be sure to include the technical as well as the business justifications for the choices made in the proposal.

Best Practice Summary

• Determining the Number and Type of CALs Needed—Purchase a sufficient number of User CALs to cover all the employees in the organization. Only look at Device CALs in a shift-work environment where employees are sharing terminals.

• Selecting the Internal Network Address Range—The internal address range for the SBS 2008 network should not be one of the commonly-used address ranges used by routers and firewalls (that is, 192.168.0.x, 192.168.1.x). The internal address should be unique so users and support staff can make incoming VPN connections, if needed.

• Use SBS as the DHCP Server for the Network—To ensure that workstations and other network devices have the correct settings to allow them to communicate efficiently with the SBS server, use the DHCP services on the SBS server instead of the DHCP services on the firewall or other device.

Copyright © 2007 Pearson Education. All rights reserved.