Now that you've looked at some of the basics of the Internet Information Server, it's time to look at the operating system IIS runs on: Windows NT Server. This chapter introduces you to some design features of Windows NT Server and explains some of the buzzwords associated with Windows NT Server to give you a better understanding of the operating system and its capabilities. This chapter should help you prepare to build an outstanding Web server using Windows NT Server and the Internet Information Server. If you have not worked with Windows NT Server before, this chapter has much to offer. You will learn why Windows NT Server often is considered to be one of the best network file and print servers available in today's market. You also will soon be hearing more about Windows NT Server's WWW publishing capabilities. If some of the discussion is a bit too confusing or technical for you, I suggest that you take a look at another book of mine called Microsoft BackOffice Administrator's Survival Guide, as well as Internet Information Server Unleashed, both by Sams Publishing. These books provide more in-depth discussions of the material.
The current version of Windows NT Server (version 4.0 beta) includes some enhancements, which are discussed a bit later in this chapter, but the basic component model has stayed the same in each release. If you have been reading any of the literature produced by Microsoft about Windows NT Server, you've probably looked at it and wondered just what they were talking about with their scattering of various buzzwords. And how do these buzzwords really relate to your day-to-day activities as a Web Master? Well that's what you are going to look at here. Although I don't include all these buzzwords, I do include the ones I think will make the most difference in your life.
Some buzzwords you might hear follow:
Note: You can execute 16-bit Windows applications in separate address spaces by manually starting them from the command line with the switch
Note: Windows NT Server's capability to support multiple processors and multiple threads of execution is one of the main reasons that the Internet Information Server performs as well as it does. Don't overlook this capability when comparing IIS to other WWW server platforms.
The Windows NT design includes much more than can be explained in a few simple words. And as you've probably heard before, a picture is worth a thousand words, and I'm going to put that to the test. Figure 2.1 is a basic picture of the Windows NT system design model and illustrates several of the more important features. I like to think of Windows NT as a mainframe operating system that has been scaled down a bit to run on your desktop. As such, it includes many of the features of a mainframe operating system. Specifically, you should note that, like a mainframe operating system, Windows NT incorporates a split in the process hierarchy. This split includes a user mode (ring 3 on Intel CPUs) where your applications, the environmental subsystems, and services execute. It also includes a kernel mode (ring 0 on Intel CPUs) where the core operating system executes.
Figure 2.1. The Windows NT design model.
This split architecture is used to keep an errant application from bringing down the operating system, which is a must for any WWW site that is connected to the Internet 24 hours a day. After all, downtime is a serious issue if you are using IIS to provide services to your customers. Like a mainframe operating system, it cannot protect you from design flaws in the kernel. This also includes poorly written device drivers. Any error in the kernel is trapped and, if possible, an error handler executes to maintain system integrity. If a device driver or other kernel component has an unrecoverable error, however, Windows NT displays a kernel core dump. I, and many others, often refer to this as the blue screen of death because the dump is displayed on a blue background with white characters. This dump includes an error code, a device driver listing with address location, and a stack dump of the offending driver(s). Just to ease your mind a bit, I'd like you to know that core dumps are very infrequent with Windows NT Server. And if you use supported hardware and software, there is a good chance you will never even see one.
Warning: Development tools, such as Visual C++, interrelate with the operating system at very low levels during the build and debug stages. It is possible during one of these actions to hang the Win32 subsystem or the complete operating system. If you will be developing applications for Windows NT Server (which may include ISAPI DLLs or CGI applications to extend your web server's functionality), never do so on a production server. Always create a standalone network (server and workstations) for your development efforts in order to avoid any potential server downtime.
Now take a closer look at Figure 2.1 and notice that the core operating system component is called the Executive. The Executive includes many subcomponents; from left to right, and from top to bottom, these subcomponents follow:
Note: The default security descriptor used by the Internet Information Server for any generic access (where a user is not an explicate member of your domain) is based on the default user name IUSR_ServerName, where ServerName is the name of the server where IIS has been installed.
Note: One of the interesting items produced by this mechanism is the capability to convert an RPC-enabled application to an LPC-enabled application. An LPC application is an application that has both the client and the server applications executing on the same computer instead of two computers. Simply changing the server name in the communications linkage to a single period enables LPC instead of RPC for the transport mechanism. And LPC is faster than RPC for the same action. If you are using SQL Server to create dynamic WWW pages on your WWW server, for example, you might want to configure your development WWW server to use a nonlocal SQL Server database by creating a named pipe with the following format and use RPC:
In the previous section, you learned that Windows NT has a split personality in which operating system components operate in kernel mode, and the rest of the operating system operates in user mode—the user mode components which include services (such as the LanMan Server service, which is used to share resources on the network, and the LanMan Workstation service, which is used to access shared resources, as well as many others) and the environmental subsystems (such as the OS/2, POSIX, and Win32 subsystems). These components are called environmental subsystems because each of these subsystems creates an emulation of a particular operating system (the environment), under which the applications (MS-DOS, Win16, Win32, and so on) execute. What is important here is that each of these environmental subsystems execute in entirely different process address space and therefore are protected from each other. This means that if a POSIX applications crashes, it has no effect on the other applications you are running.
All these subsystems are isolated completely from each other and have no communications facilities between each other, except through supported RPC functions, such as named pipes or sockets—with two exceptions. First, the Win32 subsystem is responsible for all I/O interaction. This includes the mouse, the keyboard, and all rendering on-screen. Every subsystem must request such support from the Win32 subsystem (by using local procedure calls), which is why if the Win32 subsystem hangs, the entire system becomes unusable unless the Win32 subsystem can be restarted (possible, but very unlikely). Second, the Win32 subsystem also contains the support for your MS-DOS and 16-bit Windows applications. And both 16-bit and 32-bit Windows applications can pass messages back and forth to each other, as well as make use of the standard OLE and DDE facilities.
The 16-bit Windows subcomponent is referred to as the Windows on Win32 (WOW) layer and can be restarted without complications (as far as I have seen to date). These particular subcomponents are interesting because they use the Virtual 8086 mode of the Intel processors hardware support to emulate an Intel 8086 (on RISC processors, this emulation is entirely in software) and provide completely independent address spaces for the MS-DOS and 16-bit applications (if desired) under which to execute. Figure 2.2 illustrates the MS-DOS virtual DOS machine (VDM) architecture, whereas Figure 2.3 illustrates the WOW architecture.
Figure 2.2. The Virtual DOS Machine (VDM) architectural model.
Figure 2.3. The Windows on Win32 (WOW) architectural model.
The OS/2 and POSIX subsystems are similar, but less complicated because they are not built on the VDM concept. Instead, they just use the subsystem to directly support the application environment. Note that, with MS-DOS and WOW emulation, in order to directly support hardware access by an application, a virtual device driver must be available to support the emulation of the device and control access to it. This is why many MS-DOS disk utilities fail under Windows NT and why many Windows fax applications (which use virtual device drivers in enhanced mode) fail to execute under NT. It also explains why protected applications (which use a dongle hanging off the parallel port) fail; the standard NT parallel port driver does not support access to the required I/O ports in the fashion the protected application expects. Another interesting concept for WOW applications is that, by default, they all run in a shared VDM. This provides the greatest level of compatibility, but if one WOW application fails, it can crash the entire WOW layer. In order to provide additional robustness, at the loss of compatibility, each 16-bit application can run in its own VDM. This provides the capability to preemptively multitask your 16-bit Windows applications, but prevents these same applications from using any shared memory (because they run in their own address spaces). This is one reason why you cannot execute the 16-bit versions of Microsoft Mail and Schedule Plus in separate address spaces (they use shared memory).
There is more to the Windows NT design than its User/Kernel mode architecture. Many other network operating systems (NOSs) include similar architectural concepts. Not every NOS includes the NTFS file system, the additional fault-tolerant features, and the centralized administration capabilities, however. This section focuses on why these capabilities are so important to you in your role as a Web Master.
Windows NT includes a new file system called, appropriately enough, the New Technology File System (NTFS). This file system includes several enhancements over existing file systems currently in use today on most network file servers. To begin with, it is entirely transaction-based. Much like the transaction log, which SQL Server uses to maintain data integrity, the NTFS file system uses a transaction log to maintain file system integrity. This does not mean that you cannot lose data, but it does mean that you have a much greater chance of accessing your file system even if a system crash occurs. This capability stems from the use of the transaction log to roll back outstanding disk writes the next time Windows NT is booted. It also uses this log to check the disk for errors instead of scanning each file allocation table entry as does the FAT file system.
NTFS also has several other beneficial features:
Tip: To prevent potential hackers from damaging your system, especially those that gain access to a domain user account and password, all of your critical system and data files (including your web pages) should be on an NTFS partition. This way, you can assign explicate permissions to prevent users from accessing your critical data even if they gain access to a non-administrative user account and password. If they gain access to an administrative user account and password, they can do serious damage, so protect these carefully.
The primary purpose of a file server, which includes a server running the Microsoft Internet Information Server, is to provide the capability to share resources. This can include CPU, file, and print resources. But what happens if you have a hardware failure? In many cases, this means that your entire server goes down and all the resources you share with it. And if you can't get it back on-line quickly enough, your job might go with it. And this is where the fault-tolerant capabilities come in to play to protect both your data and your job.
Earlier in this chapter, you learned how an NTFS partition can provide data integrity at the file system level, but this might not be enough for mission-critical data. And the way I define mission-critical data is any data that is required to continue your business practice. This could be a SQL Server database or the source code for your WWW pages, for example. Windows NT Server provides three options that can be used separately or which each other to safeguard your data:
Tip: The best type of disk subsystem to use is SCSI-based, because this type of subsystem supports several important features. First, most SCSI controllers are bus masters (which means that they have their own dedicated controller to transfer data to/from the disk to/from system memory). Second, most SCSI drives support command queuing (used to issue several commands to a disk) and bus detachment (which means that while the disk is processing the request, it detaches from the SCSI bus, so that another SCSI peripheral can connect to the bus and possibly transfer data). Most SCSI controllers also include a dedicated CPU so that your system CPU does not have to watch over each byte of data transferred from the SCSI controller, as most IDE disk controllers do, so that your CPU can continue processing data and enhancing system throughput. One other important feature is that SCSI drives have spare sectors that can be mapped to a failing sector (IDE drives have a similar feature, but do not support a specific command to replace a failing sector) and the NTFS file system driver can take advantage of this.
The question is, when do you use each of these techniques? Each of these techniques provides increased data integrity, but at a cost. You can use disk mirroring, for example, to split a single disk into two partitions and use one of these partitions to contain the primary data. You can use the second partition to contain the copied (the mirrored) data of the primary partition. In order to create this copy, your disk controller must make two physical writes—one to each disk partition. And if the entire disk becomes defective, all your data is lost. To offset this problem, you might use two separate disk drives, but if the disk controller becomes defective, you again lose access to your data. Table 2.1 summarizes the capabilities of the fault-tolerant drivers.
Fault Tolerant Driver |
Pro |
Con |
|
Disk Mirroring |
May be used on a single physical disk with at least two equally sized partitions. Can be used to mirror separate physical disks on a single disk controller as well. |
Does not protect against disk failure if a single disk is used. Does not protect against controller errors. Limits disk storage to half of system capacity. Performance hit for disk writes. |
|
Disk Duplexing |
Used to mirror separate physical disks on separate physical disk controllers. Protects against disk failures and disk controller errors. |
Requires twice the hardware (two disk drives and two disk controllers) to provide half of the storage capacity. |
|
Stripe Set with Parity |
Provides fault tolerance for single drive failure. Increases disk read performance. |
Does not provide protection from disk controller errors. Does not protect against multiple disk failures. Requires percentage of disk partition to contain ECC stripe. Slight CPU performance degradation for disk writes to calculate ECC stripe. |
My preference is to use striping with parity because it provides fault tolerance and increased performance (particularly if you also place the paging file on the stripe set), but if you need maximum data protection, use the disk duplexing option. Continuing this basic premise of keeping your server functional during hardware failures, you might want to consider using one of these optional techniques:
Note: If you are using an ISDN device as your connection to the Internet, be sure it is connected to a UPS. Otherwise, the moment your power fails, so does your Internet connection. ISDN devices require external power to provide power to the phone lines, unlike your POTS phone which obtains its power from the phone line.
Tip: This can also provide an additional benefit not necessarily related to performance. By using multiple network adapters, you can segment your network to reduce the potential for a security breach of your corporate network. You can use one network adapter to connect to your network that is also connected to the Internet, and another network adapter to connect to your corporate network. By using separate network protocols (such as TCP/IP and IPX/SPX) or a firewall/router, you can limit access to your corporate network from users who connect to you from the Internet.
One of the major benefits of using Windows NT is the capability to manage your entire network from any NT Server, NT Workstation, Windows 95, or Windows 3.x workstation running in enhanced mode. I have divided these management tools into two sections: "Computer Management" and "User Management."
Computer management includes all the administration tools used to configure your local computer or a remote client computer. This section points out the more useful tools:
Note: Every Administrator should review all three logs on a daily basis to determine what type of problems may be accumulating. Not all problems are flagged immediately and sent to the Administrator in an alert. Monitoring your system log can warn you of imminent failures (such as the SCSIDISK bad partition warnings on a SCSI drive that I have been receiving on my portable computer indicating that this drive is getting ready to fail completely) or of security breaches (hackers attempting to gain access to your system) in the security log.
Tip: Until you authorize a user to use the RAS service, he will not be authenticated if he connects and will not be able to access any network resource.
Tip: WINS is not designed to work with network clients that are not WINS aware, such as UNIX clients. A solution does exist in the form of a WINS Proxy Agent, however. A WINS Proxy Agent is a Windows for Workgroups 3.11 or a Windows NT Workstation or Windows NT Server computer that acts as an intermediary between the WINS server and the non-WINS aware client and forwards the IP address to the client based on the NetBIOS name the client is attempting to find. To enable the WINS Proxy Agent feature, enable the WINS Proxy Agent checkbox in the TCP/IP-32 configuration dialog box on the Windows for Workgroups 3.11 computer or the WINS Proxy Agent checkbox in the Advanced Microsoft TCP/IP Configuration dialog box.
User management includes adding new users to the network or manipulating current user characteristics. Most of this is accomplished with User Manager for Domains, This section introduces you to some of the features provided in the basic user management area in case you also will be using your IIS server as a Internet gateway for local or remote network clients. The tools you will be using follow:
Note: Unlike Novell NetWare and other network operating systems, Windows NT Server does not provide the capability to limit the amount of file space a user can access. So be prepared to implement a system policy of notifying users who exceed your maximum disk quotas, backing up their data, and then deleting it when file space runs low. As an alternative you can look into third-party add-ons for Windows NT Server, such as DiskQuota from New Technology Partners, to provide this functionality.
Note: One of the interesting concepts involved with profiles is the capability to use the same profile on more than one computer. As the user logs on from a different computer, his profile is used to configure the computer. He sees the same desktop and can use the same applications (as long as they are installed in the same directories on the local computer or are on a network sharepoint) he uses on his primary computer. But this occurs only if the user profile has been created and is available (shared) from a server that is accessible from the new location. Profiles also are server-specific, unlike logon scripts, which can be replicated from server to server and can be executed from the server that authenticates the user.
Windows NT Server introduces several new concepts for you (the network Administrator) to consider when designing your network. This section looks at the difference between workgroups and domains and introduces the trust concept. Then you will take a look at the difference between the various Windows NT Server modes of operation. Next, you will be introduced to the various domain models supported by Windows NT Server. You then will spend a bit of time with the System Management Server implementation methodologies. And, by the time you finish this section, you will be ready for the next chapter, where you will look at actually implementing your network based on the concepts in this chapter.
When you install Windows NT Server, you have to make the decision as to whether your Windows NT Server is to be a domain member or a workgroup member. If you choose to be a member of a domain, your server also must be a domain controller, a backup domain controller, or a server. If you choose to be a server, you also have the choice to be a workgroup member. If you make the wrong choice, your only supported option to change this decision is to reinstall Windows NT Server and lose any system settings you have made. Because a Windows NT Server installation can be quite time-consuming, not to mention the loss of user accounts and other system configuration options that occur when you reinstall, you want to make sure that you do it right the first time. This section will help you make the best decision possible and limit your downtime.
A workgroup is a casual affiliation of computers that are grouped logically into a single access point. This cuts down on the clutter when your users browses for resources on the network. Instead of seeing all the resources that are shared on the network, they first see the shared resources of the workgroup to which they belong. They see resources in other workgroups only if they explicitly browse the other workgroup. Aside from cutting down on the clutter the user sees, workgroups cut down on the network traffic, because each browse request requires that a Browse Master (a computer than maintains a static list of computers that are online and belong to the workgroup) or the computer being browsed for shared resources responds with a list of the resources being shared.
All security in a workgroup is based on the local (the one sharing the resource) computer. This is a serious administrative chore because it requires that all workgroup computers have the same user accounts defined if you want to allow other computer users to access your shared resources transparently (without supplying a different user account and password) in a user access environment. A user access environment provides the capability to limit access to shared resources on an individual user basis. Each individual user can have different access restrictions. In a large workgroup environment (more than five computers), it is easier to use only share access to limit access to your shared resources. Share access uses an individual password for read-only access and another password for full-access to your shared resources. Share access is essentially the same access method used in a peer-to-peer environment such as Windows for Workgroups of Windows 95.
A domain is similar to a workgroup because it provides the same grouping capability as a workgroup, but with one major difference. A domain has a centralized user database that resides on the domain controller. All user logon authentication is based on this central user database. This makes your life as a network Administrator much easier.
Domains also include the capability to establish a secure, or trusted, connection. This concept of trust begins with the computer account assignment when you install Windows NT or when you manually create the computer account with Server Manager for Domains. You cannot be a domain member without a computer account, although you can access shared resources on a domain if you are a workgroup member as long as you have a user account on the domain and there are no two-way trust relationships defined for the domain.
Note: Remember that if you have a two-way trust relationship defined on your domain, you cannot apply the user account and password mapping of the workgroup authentication model. Even if you have a user account and a password on your domain controller, you cannot use it to access a shared resource. This occurs because you are not a trusted member of the domain (you have no computer account on the domain) and therefore are denied access to the shared resource.
A trust relationship provides the capability to use the user accounts and global groups defined in one domain (the trusted domain) to the a completely different domain (the trusting domain). If this sounds a bit fuzzy, don't worry; it even confuses me on some days, which is why you will look at this a bit more later in this chapter in the section titled "Domain Models."
When you install Windows NT Server, you have three choices that basically define a specific mode of operation. Each of these operating modes provides different functional capabilities and performance options:
Tip: Another reason to use Windows NT Server operating in Server mode is to bypass the Windows NT workstation limit of 10 simultaneous client/user connections. Instead of using Windows NT Workstation, you can use Windows NT Server operating in Server mode.
One major item to consider is that in order to create a domain, you must have at least a PDC in your network. You can have one or more BDCs if desired, although they are not required. Keep in mind that a BDC can be very useful if you have a PDC failure—particularly because only a PDC or BDC can authenticate your Windows NT client.
Microsoft has defined four basic domain models: the single domain model, the master domain model, the multiple master model, and the complete trust model. You should consider this a starting point when you want to plan your network implementation, however. You do not have to limit yourself to a specific domain implementation; instead, you can stretch the basic domain model to fit your specific needs. So now, take a look at these different models so that you can plan how to make the best network design possible.
The single domain model includes a PDC and, optionally, one or more BDCs and servers (see Figure 2.4). It is the basis for all the other domain models. It is the simplest model that Microsoft has to offer and can perform well for you if your system meets the following criteria:
This criteria is not a hard and fast rule; instead, it is based on my experience. You can play with the numbers for the maximum number of users and servers, as long as you keep in mind that the real issue is acceptable performance. If you have fast servers (single or dual CPU Pentiums, for example) and a high-performance backbone (100 Mbps fiber-optic, for example), you will not see the same performance limitation as a company with 80386-based servers on a 10 Mbps backbone.
Figure 2.4. The single domain model.
The single domain model does provide several benefits. It allows any network Administrator to administer all the servers from any server or workstation on the network. Because only one user database is defined that contains all the user accounts, local groups, and global groups, resource administration is completely centralized. Because there is only a single domain, you do not have to create any trust relationships in order to access resources in other domains.
Of course, some limitations of the single domain model exist as well. Browsing for resources is based on the domain, for example, and as the number of computers in your domain increases, performance problems may arise. As the number of users in your domain grows, so does the list you have to search through to find an individual user account. And as you make changes to your accounts (by creating or modifying user accounts and groups), these changes must be replicated to every BDC on the network, which can eat up a lot of your network bandwidth. Finally, if your company has multiple departments that do not want you to administer their network or have access to confidential files, you'll have to split up your domain and choose another domain model.
The master domain model includes a single master domain with one or more resource domains that trust the master domain (see Figure 2.5). The master domain contains all the user accounts and global groups. No user accounts or global groups are defined in the resource domains. Because no user accounts exist on the resource domains, all logons and authentications are referred to the master domain.
Figure 2.5. The master domain model.
Warning: Because all user logons and authentications are processed by the master domain, if you do not include at least one BDC in the master domain and the PDC fails, then no users will be able to log onto the network or access shared resources.
The master domain model enables you to split your network based on departmental resource allocations, yet still provides for centralized administration of your network. The master domain model is well suited for organizations described by the following criteria:
Notice that, although each resource domain trusts the master domain, they do not trust each other. This is because all the user accounts and groups are defined in the master domain. Because each recourse domain trusts the master domain and users or groups can be granted access to the resource domain, so no additional trust relationships are required. One of the other interesting capabilities of the master domain model is that the central administration group can be limited to just creating user accounts in the master domain. The resource domain Administrators then can determine who will be granted access to the resources on their domain by creating global groups that include user accounts from the master domain.
A couple of down sides to this model exist, however, which you might want to keep in mind. A user list that includes 1,000 users, for example, can be pretty intimidating and can be slow to browse. And replicating the entire user list to your backup controllers can generate enough network traffic to make your users scream, which is why I recommend that you do this after normal working hours. The limiting factor here is your network bandwidth and the speed of your servers. If your network bandwidth is insufficient to carry the user logon and authentication requests provided by your servers, or your servers cannot process the logon requests quickly enough, then your network performance as a whole suffers. Consider a resource domain situated on a wide area network, for example. All user logons and authentications must travel across the slow WAN link to the master domain, even when they are accessing resources on servers in their local resource domain.
Once you have more than 1,000 users or 50 servers, you really need to think about how you can lessen your administrative burden and provide additional fault-tolerance capabilities. The multiple master domain model may just fit the bill. Like the master domain model, it includes resource domains. But instead of a single domain with all the user accounts defined in it, you have two or more domains that contain all the user accounts, as shown in Figure 2.6. Your MIS department still can administer the entire network, as long as it has accounts defined in either of the master domains.
Figure 2.6. The multiple master domain model.
Figure 2.6 shows two domains that have split the user accounts between them. The master domain on the left includes all of the user accounts from A–K, whereas the master domain on the right includes user accounts from L–Z. Each of these master domains trust the other, which essentially provides you with one user database, much as the master domain model provides. Continuing this concept requires that each resource domain trust each master domain to provide all users access to all resources in the resource domains.
The multiple master domain model increases your logon and user authentication capabilities. A single failure of a PDC (assuming that you do not have BDCs) only prevents half of your network users from logging onto the domain or being authenticated for resource access. If you have a WAN, you also can include a master domain on each side of the wire to give the local users fast access to their local resources and still enable them to access resources anywhere on the network.
Although I have used an example that splits user accounts alphabetically, you will find that this model works better for large organizations if you split the user accounts by department or divisions. Each of these departments would have a master domain with all the departmental user accounts. Departmental resource domains then would trust this departmental master domain. This would give you (the Administrator) the capability to create a global group that contains all your users in order to access a particular resource in only one domain rather than in two or more domains.
Suppose that you want to create a global group called OFFICE, which includes all the users to be granted access to the MSOFFICE share (which contains the Office installation files). If all your departmental users are included in the departmental domain, it is a simple matter of creating the group and including your users. If you have multiple master domains that split up user accounts alphabetically, however, you have to create an OFFICE global group in each of the master domains. Then, in your resource domain, you have to create a local group that contains the global groups defined in the master domain in order to accomplish the same task.
The last domain model for you to look at is the complete trust model. In this model, all the domains trust each other, and each domain has its own user database (see Figure 2.7). This particular model is designed for corporations that do not have a centralized administration group or do not want to have a centralized group dictate who has access to their network resources.
Figure 2.7. The complete trust domain model.
In some cases, corporations wind up with this model from lack of prior planning, rather than any specific need. And although it works fine, it is much more difficult to administer. As your network grows, it becomes very time-consuming to create additional trust relationships. You can express the number of trust relationships mathematically as n(n-1), where n is the number of domains on the network. If you have five domains, as Figure 2.7 shows, and decide to add another domain, you must create 6 * 5 or 30 trust relationships. If you have 20 domains, adding the twenty-first requires 420 trust relationships. And you thought your life as an Administrator was difficult now!
In this chapter, you looked at some of the features provided by Windows NT Server, along with a brief look at the system architecture to prepare you for actually working with Windows NT Server. These concepts should provide a foundation for you as you look at future troubleshooting and optimization techniques. You also learned about some of the more important features of Windows NT, such as the NTFS file system and what it can and cannot do. You learned about the fault-tolerant features, which can be implemented as part of your normal configuration, depending on your needs, available hardware, and budget. Finally, you briefly looked at some of the tools available to help you manage your network on a day-to-day basis.
In the next chapter, you will look at some of the specific issues involved in preparing your Windows NT Server platform for a successful IIS installation.
