Home > Articles > Networking > Network Design & Architecture

Network Operating Systems for IT Consultants

  • Jul 30, 2001
The big winner in the Intel-based client/server battle seems to be Microsoft. Love it or hate it, there is no denying that Windows NT is the premier NOS available. Does it have its shortcomings? Of course, and we'll cover them. This chapter introduces you to Windows NT/2000 as an operating system for a newly designed Ethernet network. It also covers operating in a mixed environment with Novell NetWare.
This sample chapter is excerpted from Network Architecture & Design: A Field Guide for IT Consultants.

The network operating system (NOS) is to a network what the CEO is to a business. The main job of a network operating system is securing access to the network. To perform this function the NOS either allows or denies access to a user based on any number of credentials. This form of network security can range from the simplistic to the elaborate. Windows 9x, for example, when used in a workgroup setting can allow access to network resources based on the address of the machine. In other words, if a machine has the correct network address, it can access all of the resources on a network. (This is not extremely secure.) Novell NetWare, on the other hand, can allow, deny, or restrict access to one, some, or all resources on a network according to user traits.

Of course, the NOS is not concerned only with security. As network technology has grown, the roles of network servers have become more and more expanded. In the earliest days of networking, the server was the only computer on a network. Mainframes were connected to vast webs of terminals. Thus, users were manipulating data that never left one location.

When PC networking was introduced, the world changed forever. Suddenly everybody could have massive computing power right on his or her own desk. The new breed of server became sentries of information flow. Servers were initially receptacles for miscellaneous files and gateways to centrally located printers. The idea that a desktop computer could replace the power and functionality of a mainframe was ridiculous. However, as the PC revolution gained ground, the line between front office and back office became more defined. Suddenly the prospect of an entire corporation being run on Intel-based machines was actually feasible. Desktop-style servers were no longer the redheaded stepchildren of client/server networking.

As the power of the servers grew, so did the power of the clients. Since server and client computers are based on the same technology, great strides in one equals great strides in the other. There was a need for network operating systems that could not only handle a more powerful server, but also adapt to the growing demands of the clients.

During this time, many developers offered systems capable of meeting these demands. Memorable yet not-so-popular entries into the operating system wars included IBM (OS/2) and Apple. Unfortunately, the OS/2 server and the Apple server never really took off the way they could have.

The products that emerged victorious were Windows NT (with Windows 3.11 through ME) and Novell NetWare. However, some diehards won't consider NetWare a true NOS because of the lack of a client OS. Novell's Client32 is an application, not an operating system.

The big winner in the Intel-based client/server battle seems to be Microsoft. Love it or hate it, there is no denying that Windows NT is the premier NOS available. Does it have its shortcomings? Of course, and we'll cover them later in this chapter.

This chapter introduces you to Windows NT/2000 as an operating system for a newly designed Ethernet network. This chapter also covers operating in a mixed environment with Novell NetWare. (These are not necessarily the same mixed environments discussed in the previous chapter.)

Why are we focusing on Windows as the operating system for a newly designed network? When designing networks, you need to plan for the most stability possible. Microsoft (for better or worse) has a large offering of products that are designed to work together. That's not to say they do not work with anything else, but in most cases this is not your money you're playing with. You need to build a product that you know will integrate with every other product on the network (without experimentation).

Planning for Windows NT and 2000

Now that you have a rough idea of the network type ABCcorp (refer to the scenario outlined in Chapter 1) needs to run, you need to decide what OS will govern the actions of the clients. The operating system itself will dictate the overall layout of the network type you choose, just as much as any other factor.

What you have right now should be a sketch of a network. Obviously you can't get into much detail because you have only a fraction of the information you need. What you do have should look like what you see in Figure 3.1.

Figure 3.1 Preliminary network design.

You know that you need an Ethernet network with 100 clients, a server, and a connectivity device. Based on the information given to you in the previous chapter, this is a fair representation of the network you need.

NOTE

The sample scenarios I gave you did not specifically say the client needs a server or a connectivity device, but you should have been able to figure that part out.

You've decided that you will go with a Microsoft operating system for the server, but which one do you pick (Windows NT 4.0 or Windows 2000)? Then you need client software; do you pick Windows NT, 98, ME, or 2000?

Choosing Your Server

When choosing your Microsoft server, you really have only two choices: Windows NT 4.0 and Windows 2000. Everyone likes to have the biggest, newest technology, but you need to look at the established history of a product as well. Windows NT has been on the market for a while now; it has a proven record. This is important with regard to stability. You don't know who will be administering your network when you're gone. Seasoned NT administrators are easier to locate than seasoned 2000 administrators, if there is such a thing.

Most peripheral software products available for networks by Microsoft were updated for Windows NT most recently. This means that these particular products (Exchange 5.5, SQL Server 7.0, and SMS 2.0, to name a few) were made to work with Windows NT 4.0. Until more products are updated to work with Windows 2000 (and until the operating system has some history behind it), I will continue to design for Windows NT.

Novell also has more than one offering on the server operating system table. The newest operating system released from Novell is NetWare 5.1, a very strong, robust server environment. However, you may come across a couple of different versions of NetWare if you are dealing with pre-existing networks. NetWare 3.12 and 4.1 are two very popular and very different versions of the Novell operating system. I have run across more 3.12 servers in production environments than any other release of NetWare. (Novell discontinued support of NetWare 3.12 in May of 2000.)

The last of the more popular operating systems are Unix (the workhorse of operating systems) and Linux. Many die-hard Unix techs are going to scoff at the way I used Unix and Linux in the same sentence. However, they are extremely similar. Most of the differences between the two operating systems are in the packaging or the non-kernel stuff.

Unix comes in four main flavors: BSD, HP, AIX, and SCO. Each has its own set of tools and devices that set it apart from the others, but at the core of each is a kernel that is relatively similar. As one of the oldest operating systems available, Unix has developed many traits that make it desirable in a server environment. One thing that almost every network administrator will point to as the single strongest attribute of Unix is its stability.

For a long time, Linux was the redheaded stepchild of Unix. However, Linux has come into its own within the last few years. Like Unix, Linux is based on a kernel. The major difference between Unix and Linux is that Linus Torvalds released the kernel for Linux free to anyone who wants it. Numerous manufacturers have created different flavors of Linux. Some of the standouts include Corel, Red Hat, Mandrake, and Caldera, but there are many more.

Windows NT Domains

The basic structure of a Windows NT network is the domain model. A domain is a logical grouping of network devices. All users within this logical grouping or domain share certain things such as resources and privileges. Each domain on your network needs a name, in our case ABCcorp. All PCs on the network will be given the domain name ABCcorp. This will identify them as being part of the ABCcorp domain.

NOTE

This will become more evident as we move along, but the domain name is not the same as the computer name. Every PC on each domain needs a name that is unique in that domain. For example, Joe's PC may be called JoePC. If you have more than one domain on your network, you can use JoePC again on the other domains, but not in ABCcorp.

The domain name you choose helps to determine the Fully Qualified Domain Name (FQDN) of the network. The FQDN is used to identify PCs and networks. In the example in the preceding note, Joe's FQDN would be joepc.abccorp.com. Anyone who has navigated around the Internet is familiar with FQDN. The address http://www.marzdesign.com simply points the browser to the computer www on the domain marzdesign.

A domain generally consists of a PDC (primary domain controller), possibly one or more BDCs (backup domain controllers), and the client PCs. The domain controllers are Windows NT servers that were assigned the role of PDC or BDC at the time Windows was installed. This is why you need to plan out your network ahead of time.

The job of the PDC is to be the receptacle for the master Security Account Manager (SAM) database. This is a glorified way of saying the PDC keeps track of who has rights for what. The PDC also authenticates users and is the main administration point on the network.

A BDC also has a copy of the SAM, but it uses it only in case the PDC fails. If the PDC becomes unavailable, the BDC is promoted, in essence becoming the PDC. The BDC will remain as the PDC until it detects that the original PDC is back online. The BDC also authenticates users to take some of the load off the PDC. For example, if you have a large domain with a PDC and multiple BDCs, a user would be authenticated by the machine that is physically closest to him. Before installing PDCs and BDCs, you need to determine which domain model is right for your job.

NT Domain Models

Windows NT provides the capability for three domain models: the single domain, the master domain, and the multiple master domain. Microsoft doesn't mention it in its literature on domains, but there is a fourth domain model, a complete trust domain. Each model serves a different purpose and a different configuration of computers. Which domain is right for you? The following sections go over the technical specifications.

Single Domain Model

A single domain model is exactly what the name implies: a single domain. Usually consisting of one PDC and a few clients, the single domain model is best suited for small networks. Figure 3.2 illustrates the Microsoft single domain model.

NOTE

We both know that you need to plan what to do if the PDC should crash. However, a client will think that you don't have enough faith in your work to leave it alone. Be as diplomatic as possible when stating your needs as a designer. Some companies may cringe when you tell them you want to add the cost of another server to the line and some may not, but the least you can do is deliver the information as harmlessly as possible.

Microsoft's rules on a single domain model are as follows. Windows NT can accommodate a SAM database size of 40Mb. This translates to 26,000 users and 250 groups (thus the 40/26000/250 rule). This is more than most companies will ever need. However, it may not be the most practical solution.

Just because a single PDC theoretically can handle up to 26,000 users does not necessarily mean that it should. In almost every case, I would suggest introducing a BDC to a single domain for fault tolerance. If anything happens to the PDC, you need to have a backup in place. Microsoft's specification on BDCs is one for every 2,000 users. I find that this estimate provides for an unnecessarily low number of BDCs. I like to plan for one BDC regardless of the number of employees. This provides fault tolerance if the PDC should need to be brought offline for maintenance.

I also like to add one BDC for each separate geographic location. If the company is large and is spread out on more than one floor of an office building, I consider each floor another geographic location. I do this to adjust the design, saving on network traffic and possible delays. Also, I add one BDC (in addition to the first BDC on the network) per 500 users in one location. This should give plenty of guidelines to design by.

Figure 3.2 Microsoft single domain model.

Here is the calculation used by Microsoft to arrive at the 40/26,000/250 rule:

Object

Space Used

Users Account

1.0k

Computer Account

.5k

Group Account (up to 300 members)

4.0k

The maximum number of users you can have on a PDC before you hit the 40Mb SAM size limit is 26,000 (with 250 groups). You should make a note of this if you are planning a large network.

Master Domain Model

A master domain is geared more toward large-scale enterprises with multiple geographic locations serving different purposes. In a master domain model, one domain serves as the master. This domain is charged with authenticating users and is the holder of the SAM database. The PDC serves the same purpose in a master domain as in a single domain.

The difference in a master domain is the presence of secondary or resource domains. A resource domain will have a PDC and a unique domain name. However, in the resource domain the users will be authenticated by the PDC of the master domain. The resource domains will contain local resources for the users of the particular domain. This means that the users in the resource domains will use files and printers in their own domains, not the master domain.

This is accomplished through the use of trusts. The smaller resource domains have one-way trusts with the master domain.

Trusts in Windows NT allow one domain to have particular rights or access to resources or users in another domain. There are two different kinds of trusts: one-way and two-way.

The master domain model (because it is similar in function to the single domain model) has the same technical limitations as the single domain model. Figure 3.3 illustrates the master domain model.

Figure 3.3 Microsoft master domain model.

A master domain model is good for companies that span large geographic distances. If you have a main office in New York and equally large offices in Los Angeles and Miami, a master domain model will work best. The New York office will be the master domain, with Los Angeles and Miami as the resource domains.

Multiple Master Domain

A multiple master domain consists of two or more master domains linked at the top by trusts. In this case the master domains function as separate domains. However, the two master PDCs are linked by a two-way trust. The resource domains have a one-way trust with each master domain. This enables users in one master domain to access the resources in the other. A domain model such as this would be used when two large companies with existing master domains merge. Another use of the multiple master domain model would be between a large manufacturing company and its equally large warehouse.

If the warehouse has small offices around the state (or other geographic areas), each with its own internal departments, then the multiple master domain model would be successful. In the multiple master domain model, each master domain is capable of accommodating 26,000 users per master domain. Therefore, a multiple master domain consisting of three master domains would provide for as many as 78,000 users. Figure 3.4 illustrates the multiple master domain model.

Figure 3.4 Microsoft multiple master domain model.

Trusts

A trust in Windows NT is a unique privilege reserved for servers. A trust simply states that one domain has the right to the users and groups from another domain. It is universally recognized that there are two kinds of trusts: one-way trusts and two-way trusts. A one-way trust allows users in one domain to access the resources in another, but the users in the second domain have no rights in the first domain.

A two-way trust, theoretically, goes in both directions. However, this is not entirely true. A two-way trust is actually two one-way trusts. This may seem like nitpicking, but there is a big difference. A two-way trust implies that one person sets up a rule allowing two domains to communicate. In fact, a one-way trust needs to be set up on each domain to create a two-way trust. This assumes a certain level of administrative expertise in running both domains.

Let's look at design for ABCcorp. It has 100 employees occupying two floors of an office building. Which domain model would be the best fit for the company's needs, based on the information you have?

Figure 3.5 shows the network diagram I came up with.

Figure 3.5 Sample network for ABCcorp.

The PDC is located on the first floor with one BDC, which will provide fault tolerance and take some of the load off the PDC. With the small number of users and the relatively small geographic area, the single domain model works best, although the other domain models could be made to work.

Installing Windows NT with Domain Models in Mind

We won't cover the entire process of installing Windows NT Server. Rather, we will look at how to create the domain model you design. You might be asked not only to design the network but also to have some role in its implementation. Even if you have experience installing Windows NT Server, you don't want to skip this.

First, you need a set of Windows NT installation disks. If you don't have a set, make one. I never go on a job without a set of Windows NT startup disks.

Making a set of startup disks is easy. First, make sure you have three preformatted disks on hand. Insert the Windows NT 4.0 Server CD and run winnt.exe (or winnt32.exe, depending upon your situation). Then follow the prompts to create the system disks.

NOTE

We haven't covered server hardware yet (that's the next chapter), but for this installation we will assume that there is a RAID 5 controller in the server.

Once you have a set of setup disks, insert the first one into the server and boot. (Windows NT can be installed with the use of setup disks, and that's why I am so adamant about using them.) Most servers use a third-party hard disk controller or RAID controller (by a different manufacturer than the server itself). When you use the setup disks, you will be prompted to insert the driver disk for the controller between disks two and three. An installation started by booting directly from the CD often bypasses this part of the setup. The section of the installation that I am referring to here is known as Mass Storage Detection. If you do not supply Windows NT with the driver disk for the controller, the installation will fail because the kernel is unable to see the hard drives.

The next phase of installation that we are concerned with is drive partitioning. Here Windows NT asks you to partition the hard drive and format it with the file system of your choice. Use your best judgment here. Generally if I am installing to a PDC that has 30GB of space, I will create a 2GB C: drive. I will then leave the rest unpartitioned. This enables me to use Windows NT Disk Administrator to play around with the remaining 28GB. After you choose the size of the C: drive, the installer will ask you to pick a file system. I suggest you pick FAT.

During Windows NT installation, you have two choices for file systems: FAT and NT File System (NTFS). FAT has been around since the days of DOS, and it offers nothing in the way of file security. Windows NT was built to run on NTFS, which supports file security. Using NTFS is how you implement user access security.

A FAT partition cannot see into an NTFS partition; they are two different animals. If you format the C: drive as NTFS and for some reason you need to boot the server off a boot disk, you will be looking at an empty machine. You won't even be able to see a C: drive. This is because the boot disk you are using is FAT. That is why I format the C: drive as FAT. If I need to, I can boot the server with a standard boot disk. This gives me the ability to edit suspect files in DOS and fix problems. I then use Windows NT Disk Administrator to format the remaining space as one large NTFS drive.

If you format C: as FAT and E: as NTFS, how can you do anything?

Once again there is an exception to everything. In this case the exception is Windows NT itself. Windows NT can view and manipulate both FAT and NTFS. The problem is that when you boot off a boot disk, the machine is no longer using Windows NT, it is using the operating system that made the boot disk (such as Windows 95 or Windows 98). There is no such thing as an NTFS boot disk; the formatting information is just too large.

Finally, after the kernel has installed, the server will reboot itself, and you will begin configuring Windows.

NOTE

The Windows NT kernel is the brain of Windows NT. The kernel is the interface between the programs (including the operating system itself) and the processor.

There are two things you want to pay close attention to during configuration. After you pick a name for the server, Windows NT will ask you to designate the server type. This is the most important option in the setup. This is irreversible, and if you mess up this step, the only way out is to reinstall the server.

The three choices for server type are primary domain controller (PDC), backup domain controller (BDC), and member (or standalone) server. Looking back at our design, we need one PDC and one BDC. (In the next chapter I will discuss what hardware is best to use for which type of controller.) Therefore, we will choose PDC for the server type.

You need to install your PDC first. When you choose BDC as a server type, Windows NT will prompt you for the name of the PDC and try to contact it. If Windows is unsuccessful in contacting the PDC, you will not be allowed to continue setting up as a BDC. You will be forced to pick PDC or member server.

What Is a Member Server?

Member servers are very valuable to a network. Chances are the network you are designing will need more than two servers (the PDC and the BDC). You may need a server to house a large application of some sort, for example. You don't want to set up another BDC for that purpose, so you use a member server. Member servers do not authenticate users, nor do they have a copy of the SAM database. They simply serve as resources, with no responsibility to the domain. Member servers can be moved between domains at will, whereas a PDC or a BDC is bound to the domain on which it is installed.

This is convenient, especially in master or multiple master domains where you have several domains in one company.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020