Top 10 Gotchas
Windows SBS 2003 Setup places the machine running Windows SBS at the root of an Active Directory forest. The end result is that there can be one and only one server running Windows SBS in a Windows SBS domain.
Many Enterprise IT Pros have stumbled right here, thinking that Windows SBS is like Windows Server, Standard or Enterprise Editions, on this point. They assume that they can install Windows SBS 2003 on a server and then drop that server on to an existing Windows Server domain as another replica domain controller on the network with no issue. But they can't! The server running Windows SBS always sits at the root of the domain. This obviously means that you can have only one server running Windows SBS on a network.
There can be only one machine running Windows SBS in a domain! Also, the Windows SBS computer must be the root of the forest so you can’t add another Windows Server machine to a Windows SBS network as the primary domain controller. (You can add extra machines running Windows Server to a Windows SBS domain as replica domain controllers, line-of-business (LOB) application servers, or servers that have Windows Server 2003 Terminal Server enabled.)
Another surprise for the Enterprise IT Pro who is familiar with Windows Server only in the enterprise space is that Windows SBS domains cannot establish trusts with any other domains—period. No if-ands-or-buts about it; a Windows SBS domain stands alone. You can’t establish a trust between a Windows SBS domain and a Windows Server domain, and you can’t establish trusts between Windows SBS domains.
 Note
The End-User License Agreement (EULA) for Windows SBS specifically prohibits "hacking" the system in order to work around the "no trusts" rule. So not only is Windows SBS configured to not allow trusts, but you also break your licensing agreement if you try!
Some Enterprise IT Pros have recommended Windows SBS for a small business under the mistaken notion that they could tie the Windows SBS domain into another Windows Server domain using trusts, only to find out they couldn’t—after they purchased Windows SBS and installed it at the small business!
Following on the second gotcha, you need to know that Windows SBS does not allow child domains. That is, you can’t create a child domain (or sub-domain) beneath the initial Windows SBS domain that you create during Setup. Unlike Windows Server 2003, Standard, Enterprise, or Datacenter Editions, Windows SBS doesn’t allow you to further subdivide your domain namespace hierarchically by creating child domains.
For example, if the small business you're assisting is the Contoso company, and the root domain name is contoso.local (".local" is the default domain root suggested by Windows SBS Setup for the internal domain), you can't add child domains accounting.contoso.local or payroll.accounting.contoso.local. This makes sense when you consider that a typical small business employs a small number of staff and operates out of a single location. The small size of the average small business just doesn’t call for the division of the namespace into child domains.
In contrast to Windows Server, where users connecting to the server can number into the thousands, Windows SBS 2003 handles the upper end of the average small business—75 users or devices (including computers) at the most. This is the fourth gotcha for Enterprise IT Pros!
Because you're probably used to working with Windows Server, Enterprise Edition, or even with Windows Server, Datacenter Edition, in which thousands of users and devices are common, you should keep this limit in mind when you're helping a small business decide whether to install Windows SBS 2003 on their network. A business that has more than 75 users or devices should consider other editions of Windows Server 2003.
You can think of a Windows SBS installation as happening in two phases: the first phase is the installation of the operating system that drives Windows SBS, and the second phase is the installation of the Windows SBS application. When the first phase is finished, you have an operating system; when the second phase is finished, you have all of Windows SBS 2003. A full installation isn't finished until both phases are finished.
There is a point during installation when the operating system has been installed and the user is returned to the desktop. Some Enterprise IT Pros have been tempted to pause here and tweak the operating system before they install the rest of Windows SBS. But a word of caution: don’t do it!
The second phase of the installation does a great deal of configuration of the underlying operating system. Setup prompts the administrator to make configuration decisions for areas like Internet connectivity, DHCP, and DNS. The end result is that if you did tweak the operating system between phases, the changes that you made after Phase 1 might be overwritten during Phase 2, and those changes that weren’t overwritten might cause problems for the rest of the installation.
Now having said that, let me add that it is a good practice to take a quick look at Device Manager once the first phase is finished. You should check Device Manager to ensure that the operating system correctly recognized your server hardware. If it didn't, this is the time to get the right drivers installed—before you press on to Phase 2.
Aside from that one exception, don’t try to customize between phases. Finish the entire installation, and make the appropriate configuration changes only when Setup prompts you to do so.
Probably the biggest misstep for Enterprise IT Pros who know Windows Server only in an enterprise network happens right here: Windows SBS wizards vs. Microsoft Management Console (MMC) snap-ins. Enterprise IT Pros often, mistakenly, jump to the familiar MMC snap-ins instead of using the Server Management console wizards. A good rule of thumb here is this: if the Windows SBS Server Management console provides a wizard, use it!
Windows SBS is filled with handy wizards that take the place of the MMC snap-ins that most Enterprise IT Pros use to modify or manage their servers. Many common management tasks, like adding a new user—something you might usually do with the Active Directory Users and Computers snap-in—shouldn't be done with an MMC snap-in. In Windows SBS, you really should use the wizards provided in the Server Management console.
Here's why: the Windows SBS wizards do customizations behind the scenes that make the product work best for a typical small-business environment. And, as I mentioned earlier, some Windows SBS wizards perform several tasks at once, so that changes you make in one place cause changes behind the scenes in other places. For example, the Add User Wizard creates a user account in Active Directory, creates a mailbox for the user in Exchange, and sets access permissions for the user on the company intranet, to name just a few! The MMC snap-ins aren't all connected that way, and they haven’t been customized for small-business use, so if you use the snap-ins instead of the wizards, you might actually break some Windows SBS functionality. In Windows SBS, Enterprise IT Pros should let the wizards do the magic!
In a way, licensing is fairly simple with Windows SBS. Instead of having to purchase separate client-access licenses (CALs) for each server application running on the Windows SBS machine—for example, one for Windows Server 2003, one for Exchange 2003, and one for SQL Server™ 2000—Windows SBS requires only one CAL per user or device. With this one CAL, the user or device can access the services provided by the server applications that Windows SBS includes. You should take special note that the CALs for Windows SBS are not the same as the CALs for Windows Server or for Exchange. You can't add a standard Windows Server CAL to Windows SBS; Windows SBS requires Windows SBS CALs.
Also, if you add a computer running Windows Server as a member server in a Windows SBS domain, you don't need any extra licenses for the client computers to access the member server; the Windows SBS CAL covers that, too! But be advised: if you have a member server running applications that require their own licenses—for example, Terminal Server, or a line-of-business application with a SQL Server backend—then you might need to buy additional licenses for those applications. Check the licensing requirements for the application.
And a final tip: SBS CALs are sold in increments of 5 or 20, so keep that in mind if you're advising a small business about the cost of licensing for a Windows SBS network.
Windows SBS includes Terminal Server, but you can run it only in Remote Administration mode. As you no doubt recall, Terminal Server can run in either of two modes: Application Server mode, and Remote Administration mode. On a server running Windows SBS, Terminal Server runs only in Remote Administration mode. This is one of the big gotchas!
If you want to make Terminal Server in Application Server mode available in a Windows SBS network, you have to add an additional server to the network running Windows Server and Terminal Server in Application Server mode. Because this isn't hard to do (as you'll see in the later section, "Set Up Server Computer Wizard"), it's a quick task for the administrator. Just be aware that client computers connecting to Terminal Server on the additional server need Terminal Server CALs in addition to the Windows SBS CALs.
Bottom line? Windows SBS provides Terminal Server only in Remote Administration mode, so you can't provide Terminal Server in Application Server mode for network users. But if you want to provide Terminal Server in Application Server mode for a Windows SBS network, you can easily do this if you add an additional server running Windows Server and you configure it to provide Terminal Server for your users.
Windows SBS provides a default installation experience that doesn’t require a lot of work by the administrator. And when you do need to make changes to your server, Windows SBS provides easy wizards for most tasks. This holds true for the default Active Directory structure.
For example: by default, when users are added to the Windows SBS network using the Add User Wizard, user objects are placed in the ServerName.local.MyBusiness.Users.SBSUsers organizational unit (OU) in Active Directory (where ServerName is the name of the server running Windows SBS). Other functions in Windows SBS expect to find the network users in that OU. Moving users out of the OU or renaming the OU might cause these other functions to fail.
The crucial point here is that you should leave the default Active Directory structure as is, or else proceed with extreme caution.
While it’s true in general that the stronger the hardware, the better the performance of the operating system, you should know just how much you can upgrade the hardware that runs Windows SBS.
Take a look at the following table, which compares the hardware maximums of Windows SBS 2003 to those of other Windows Server editions. Keep this table in mind when you're thinking about what hardware to buy to run Windows SBS 2003. The hardware maximums are different than those of other Windows Server operating systems, especially Enterprise and Datacenter Editions: Table 1 Comparison of Windows Server hardware maximums
And while we're on the topic of hardware, a good practice is to connect all of the hardware on the server before running Windows SBS Setup, because Setup makes some configuration choices depending on what's installed.
|
