Some of the main topics in this chapter are
A small organization is defined as being composed of 100 users or less. At that level, there is still benefit in installing a client/server network architecture, but the demands for network services are modest. A small-scale enterprise really requires a flexible topology, room to grow, and modest demands on the available IT staff.
This chapter details the typical scenario for a small-scale enterprise: the single domain model. This model provides for a centralized single LAN or limited remote sites through WAN connections. The requirements of both types of small topologies are discussed, focusing primarily on the successful location of domain controllers and application services and on the nature of the WAN links.
For the purposes of this discussion, a small enterprise is considered an NT network consisting of less than 100 nodes. This network would require file and print services beyond what would be practical using a workgroup scenario, and would establish a domain and a primary domain controller (PDC) for validation services. Additional services consistent with the enterprise's line of business would also be established. For example, server installation of a database such as SQL Server or a Web server such as Microsoft Internet Information Server would be likely.
Although it is certainly possible for a small-scale organization to establish multiple domains, and this can have both organizational and security benefit, generally this is not done. The cost and time required maintaining the domain structure by adding domain controllers and managing additional server resources often is not worth the extra effort.
One of the parameters of a small-scale organization is limited administrative personnel. For an organization of 100 users, it is likely that the support staff might be anywhere from one to five people, and no more. This limitation affects the complexity of the domain organization that is possible to maintain, and it is one of the reasons that a single domain structure is considered in the majority of cases for a smaller organization.
The two basic models for a small-scale enterprise are local and dispersed. In a local enterprise, a single LAN services the majority of the enterprise's needs. Whereas a local enterprise might have dial-in service setup to allow for remote access to the LAN, the local enterprise would not be managing WAN connections to remote offices. This type of enterprise has central domain controllers and centralized application servers.
A dispersed model for a small enterprise has a central location with remote locations. Network traffic to a remote location from the central office might be through a dial-up connection or through a WAN link. Generally, both of these connections should be considered as either being too slow or too unreliable to accommodate service validation using a domain controller located in the central office. For those reasons, most solutions locate a backup domain controller (BDC) in a remote office, as well as any application servers.
Some smaller organizations do adopt separate domains in remote locations, but this type of topology is better suited to a medium- or larger-sized enterprise.
In a small-scale enterprise, service validation is a necessary but not a rate-limiting operation. The level of activity as measured by transaction throughput that an organization of 100 or less generates is low enough that the requirement of a speedy set of servers is not as important as the demands made by a larger organization. Whereas you could install a domain controller or an application service on a x486/66 MHz computer with 32M RAM running Windows NT 4, a better choice would be a Pentium computer running at 90-100 MHz or better.
Unlike larger organizations where service authorization occupies a significant portion of a domain controller's processing activity, a small-scale enterprise can use its domain controllers for application services--provided that the domain controller contains the necessary RAM to run the required services. That is, a PDC or BDC can serve double duty as an Exchange Server, SQL Server, and so forth.
For a PDC or BDC running a service like DHCP or WINS, that additional RAM requirement can be quite modest. It is possible to have adequate performance for validation and DHCP/WINS on a Pentium computer with 40M installed RAM. If you require the services of a SQL Server database, or have Site Server installed, then you will need to have more RAM installed to service both NT Server and that application. Site Server, for example, requires about 64M of installed RAM. Because the transaction load on domain application services is so low in a small-scale enterprise, the additional RAM required to service high transaction loads is just not required in a small-scale enterprise.
As a general rule, a domain controller should be located on either side of a slow or temporal network link. The fundamental design goal of a small organization with remote computing needs should be to maintain services even when the connection to the main office is broken. In planning the location of BDCs, you need to take into account the speed and consistency of the WAN network link. T1, 56K, or ISDN link lines should not be relied on for a local logon validation request.
Some other considerations limit domain controller usage as an application server. It is unlikely that any network administrator would or should feel comfortable locating Web services on a domain controller. Most networks concerned with outside or Internet access to an Internet Information Server would locate that server on a non-domain controller (NDC). That NDC could be located behind a firewall, or isolated from the network using some method like protocol isolation.
Because firewalls are still a rather costly solution (they typically cost about $15,000-$25,000), for the most part, small-scale enterprises will likely use another method. However, if Internet access is a central feature of a business--say that business is an Internet Service Provider--then it is likely that a firewall might be installed to provide that service by proxy to connected clients. An ISP is really a special case and doesn't qualify as a small-scale enterprise. When you consider the additional user accounts granted to clients, an ISP is either a medium- or large-scale enterprise under the criteria presented in this part.
The other restriction on location of application services is the capability to create and manage users and groups appropriately. In instances where you are required to create local groups, you could not place that application on a BDC. Site Server requires that any electronic online store that you create and manage be controlled by a local group of Store Managers. In this instance, you would need to locate Site Server on a PDC or BDC. Issues like this crop up from time to time; their appearance is somewhat random and hard to predict.
The best fault tolerance method that you can have is failover. Failover is when a server goes offline and is replaced by an alternate computer. Failover is achieved for network validation services when a BDC replaces a PDC that fails. A BDC contains a replicated copy of the Security Accounts Manager database. Given the relatively low price of personal computers and the modest need for processing power that a small-scale enterprise has, a BDC is a good investment.
For application services on Windows NT, you can achieve failover by replicating the service and distributing the service across an enterprise on additional computers. The capability to replicate data and distribute it and the application services that use that data is not well accommodated in a small-scale enterprise unless either the application is mission-critical or the services must run remotely on the other side of a WAN. Typically, replication of data and services to a remote location only occurs for domain validation services or for the mission-critical line of business application(s) that require a local server to be present in a remote office.
All the techniques for failover that a medium or large organization might employ-- clustering servers using the Wolfpack technology, for example--are costly solutions for a small-scale enterprise and aren't going to be installed often.
Replication and failover are not perfect methods for fault tolerance. They provide backup services but make no assumptions about the quality of the services provided. If a security database or any other application's data gets corrupted, that bad data will be replicated and propagated throughout the enterprise.
All enterprises regardless of their size should plan for a historical record of their security database or their application data that they can roll back to. To that end, a small-scale enterprise still should have a coherent backup strategy in place, have some level of RAID operating on critical network services, and so forth.
In the final analysis, the best fault-tolerance method that any organization can apply is an aggressive and well-established backup program. The backup system recommended in the published case study in the Windows NT Server Resource Kit is the Seagate (formerly Arcada) BackUp Exec for Windows NT, Single Server/Enterprise Edition - version 6. For online backups, Octopus for Windows NT is used to provide fault tolerance between enterprise servers. Online backups are those that are done as data in a file or database is modified in real time. Octopus creates mirrored files and directories.
The single domain model (see Figure 61.1) is the simplest structure you can have. You create domains in the User Manager for Domains in NT Server's Administration Tools. Be aware that after you establish a domain name, it is incredibly difficult to change them. Renaming a domain requires reinstalling every server.
In the single domain model, you have a single directory service, access from any node for logon, administration from any NT Workstation, remote access, and replication. There are no connections to other domains in this model. A single domain model can be implemented with as few as one PDC and one client, and as many as 40,000 clients. A more balanced mixture of application servers would typically top off a single domain at around 26,000 user accounts.
In the single domain model, the administrator controls all servers and manages all resources. This model is favored by small enterprises that want to limit the number of network administrators and retain central control. Most enterprises of more than 100 users choose a different domain model to partition users into different business units.
NOTE: Chapter 6, "Creating Your Domain Plan," contains a discussion on the role of PDCs and BDCs, the four basic domain types, and how to place domain controllers on your network.
The single domain model is appropriate for use in small organizations.
Windows NT Server allows you to install and manage a multiprotocol network stack. You can install any or all of the following:
The adoption of TCP/IP is a common decision, especially for medium- and large-scale organizations. It offers the following advantages:
When installing TCP/IP, it's possible in a smaller organization to assign static IP addresses. However, most medium- and large-scale organizations install a Dynamic Host Configuration Protocol (DHCP) server to manage IP addressing. Hand-in-hand with DHCP, most network administrators install the WINS service to provide for name resolution between NetBIOS computer names and IP address resolution.
WINS and DHCP services don't require many server resources in a small organization but are somewhat involved to set up the first time. The next generation of Windows NT Server will probably greatly improve upon the installation and management of these two services. For medium and large-scale organizations, WINS and DHCP are almost required when Internet and intranet resources are being managed. No network administrator worth his salt wants to manage a large LMHosts file unless he is forced to because of the different operating systems involved.
© Copyright, Macmillan Computer Publishing. All rights reserved.