In this chapter, we explore workgroup and domain environments in more detail than we covered in Chapter 1. A common mistake when taking the Windows NT Workstation certification exam is to assume you don’t need to know much about domains, figuring that they’ll be covered in the Windows NT Server exams. But workgroup and domain environments figure prominently in networking and security for Windows NT, as well. To pass the Workstation exam, you must have a good understanding of domains.

Related to workgroups and domains is browsing, a process computers use to find each other on the network. The whole purpose of workgroups lies in their capability to browse together, and that feature is no less important in the domain environment.

Every Windows NT Workstation computer must belong to either a workgroup or a domain. If you’re not joining a domain, you must belong to a workgroup. A workgroup simply consists of a set of one or more computers that specify a particular workgroup name in their network identification configuration. The first computer to specify a workgroup name "creates" that workgroup.

In practical terms, workgroups do very little for you. In fact, every Windows NT Workstation computer in your organization could belong to a different workgroup, and your security setup would be the same as if they were all in the same workgroup! Where workgroups do make a difference is in network browsing, or finding other computers on the network. Computers participating in a workgroup (or a domain) delegate the responsibility of keeping track of the names of other computers on the network to a few systems, reducing the load on systems that don’t need to browse. We cover browsing in detail in the last section of this chapter.

Workgroups are typically used in small offices, where there are only a few computers and which need only peer-to-peer networking. Someone must be responsible for setting up user accounts and security on each workstation. If a user must change a password, for example, the change must be made on each workstation. You can see why this arrangement is impractical for larger networks.

A Windows NT Domain is like a workgroup that shares a common account database, and provides other features we’ll discuss shortly. Basically, a domain is an area of authority. For Windows NT 4.0, the domain is in the Windows networking (NetBIOS) namespace.

Where Windows NT really shines is in the domain environment. Domains are more formal than workgroups, and require planning. For example, a Windows NT Server computer must be installed as a Primary Domain Controller to create a domain. Domains are typically larger than workgroups, and offer a much wider range of services.

Now that the Internet is so popular, you may be familiar with another usage of the word domain. An Internet domain like "microsoft.com" is in the Internet domain namespace, and lets you know that systems within it, like "www.microsoft.com" are within that domain. The Internet meaning and the Windows NT meaning are entirely different. For Windows NT 4.0 usage, you can ignore the Internet meaning. The usage will blur once Windows NT 5.0 is released with its NDS-based active directory, but we’ll have a new book for that.

The same username and password may be used on any system participating in a particular domain. While a user can be restricted to as many as eight workstations, by default he may ' anywhere in the domain. This is in stark contrast to the username and password required for each workstation under the workgroup model.

The administrator has the option of setting up a roaming profile for each user, which gives the user the same desktop environment on any workstation he logs on to. In practical terms, a roaming profile is only useful if the computers are similarly configured. What good is a user’s desktop shortcut to Microsoft Outlook on a computer that doesn’t have it installed, or has it installed in a different location? The "master copy" of a roaming profile is stored on a server. Each workstation the user logs on to has the profile copied down to it. The profiles for the user are synchronized at every login and logout. Since a profile contains a user’s personal folder as well as temporary Internet files, it can become quite large.

Another option for user accounts in a domain is a home directory, which can give the user an accessible place to store files from anywhere in the domain. Some applications use the home directory as the default location to open or save files. The home directory is usually bound to a directory under a share on a server. If you wish to use this feature, you’ll probably also be in the market for a third-party software package to provide disk quotas, since neither Windows NT Workstation nor Server provide any disk quota management.

A user in one domain also can be authenticated to another domain by establishing trust relationships. When one domain trusts another, the users and groups of the trusted domain become available to the trusting domain. If both domains in question trust each other, they have a two-way trust relationship. We’ll go further into trust relationships in the Domain Models section.

A user logging on to their usual workstation can still log on if all the domain controllers are down. Cached information from their last successful logon is used to authenticate them. Of course, logon scripts, roaming profiles, and any file and printer shares or other services on those servers would be unavailable.

All account information is kept on the domain controllers. There is only one place to maintain accounts for all the users in the domain. This is what allows a few administrators to manage a large number of user accounts and workstations. Any additions or modifications are made only once.

Centralized administration doesn’t mean you have to be sitting at a domain controller to perform administration tasks, however. Any system that has domain administration tools such as Server Manager or User Manager for Domains installed can view or modify (assuming the appropriate user rights) the same domain information. These client-based network administration tools for Windows NT Workstation and Windows 95 are found on the Windows NT Server CD.

By joining a domain, a computer can view and use domain user accounts and global groups, just as if they were in its own local account database. Any computer within a domain can use the domain user accounts and global groups to provide or restrict access to systems and resources. For example, a Windows NT Workstation computer in a domain can allow access to a shared printer on that workstation to members of a global group, called Sales, defined in the domain. This frees users from having to add local accounts and passwords, or from having to keep track of which users are in the Sales group at a given time.

A domain administrator can control resources on any system within the domain. The Domain Administrators global group is added automatically to the local Administrators group on all Windows NT systems that join the domain. It provides administrative access to the computers within the domain. Centralized security also provides centralized access control to the domain resources.

Products such as Microsoft Systems Management Server extend the ability of an administrator to manage and troubleshoot the systems and resources within the domain.

As I mentioned in the workgroup discussion, all that’s required to create or join a workgroup is to mention its name in your network configuration. Just about every site where the setup of computers isn’t centralized has several computers that are members of the workgroup called Workgroup, because that’s the default in the dialog box at setup time. Most people either don’t know what a workgroup is, or can’t think of a better name. At my site, browsing Workgroup currently shows 58 systems! If this were a real workgroup, so many systems would make it unmanageable.

1. Select Start | Settings | Control Panel.
2. Double-click the Network icon. The Network window appears.
3. Select the Identification tab. Here you can see your computer name and current workgroup or domain. Click the Change button.
4. From this window, seen in Figure 11-1, you may change your computer name and workgroup or domain. Click the Workgroup option, and then the dialog box to its right.
5. Type in the name of a workgroup you’d like to create or join. For this example, I’ve chosen CH11EX1.



Figure 1: Joining a Workgroup.

6. Click OK. You’ll have to reboot before the change will take effect.

In order for a Windows NT Workstation to join a domain, a special account for that computer must first be created in the domain. While other Windows systems, like Windows 95, may participate at some level in a domain, they can’t be full members, and no computer account need be created for them in the domain. We often still refer to non-Windows NT systems as domain members, even though their role is more cooperation than integration, and they can’t take advantage of all the domain features.

This is similar to Exercise 11-1, except now we need a domain to join.

1. Repeat steps 1-3 in Exercise 11-1. You see the window in Figure 11-2.
2. Click Domain and then the dialog box to its right.
3. Now type in the name of a domain that you’re allowed to join. For this example, I’ve chosen EX2DOMAIN. If you’re not allowed to join a domain, just type anything, and let it fail, or don’t click OK later.

If your workstation hasn’t been added to the domain with Server Manager, you’ll need to check the box labeled Create a Computer Account in the Domain, and enter a domain administrator’s username and password in the appropriate dialog boxes.



Figure 2: Joining a Domain

4. Click OK if you have a valid domain. You’ll be welcomed to the domain, then you’ll have to reboot.

1. Logon to the Primary Domain Controller for your domain using an account with administrator rights.
2. Select Start | Programs | Administrative Tools | User Manager for Domains. The User Manager window appears.
3. Select User, New User. The New User window, shown in Figure 11-3, appears.
4. Fill out the fields. You may leave the Description or Full Name fields blank. I usually fill in the name field for a person, and the description field for a service account.



Figure 3: Naming a new user account.

5. If you want to set the Groups, Profile, Hours, Logon To, Account, or Dialin options, click those buttons. When you’re finished with them, you’ll be back at the New User window.
6. Click the Add button to add the account. Once it’s added, click the Cancel button, and exit User Manager for Domains.

If you’ve successfully completed exercises 11-2 and 11-3, you’re ready to log in to the domain from the workstation.

1. Bring up the logon window that you used in exercise 11-2.
2. Enter the username and password from exercise 11-3.
3. In the Domain window, click the down arrowhead on the right of the dialog box.
4. You should see both the workstation name and the domain name as available options. Select the domain name.
5. Click OK. You’ll be asked to change your password, unless you cleared the checkbox for User Must Change Password at Next Logon during exercise 11-3.

You’re now logged on to the workstation as a domain user. If you didn’t set up an existing profile when you created the account, you’ll get a new default profile. Even if you have the same username on the workstation and in the domain, you are considered a separate user on the workstation, and it keeps a separate profile.

Windows NT Server computers may have any one of three roles in a domain: Primary Domain Controller, Backup Domain Controller, and Member Server.

The Primary Domain Controller (PDC) must be installed in order to create a domain. The PDC is the heart (or brain, if you prefer) of a domain. All account creation and maintenance is performed on the PDC, though the User Manager for Domains may be run on another system. Logon scripts are typically created and maintained on the PDC as well. In smaller domains, it might also serve most of the resources in the domain, and it could be the only Windows NT Server system present.

One or more Windows NT Servers may be installed as Backup Domain Controllers (BDC) after a domain has been created. The entire account database is basically mirrored on each BDC, and the PDC keeps the information updated within five minutes by default. If your PDC becomes unavailable, you may promote a BDC to be the PDC, which allows you to make account changes while your primary server is down. A BDC isn’t automatically selected and promoted to a PDC when it becomes unavailable. This is in contrast to a PDC’s role as Master Browser where a new Master Browser is selected, which is discussed later.

In addition to keeping another copy of critical account information, each BDC acts as another logon server. This means that the account database on a BDC may authenticate user logons in the domain, as well as serve any logon scripts. Adding a BDC is useful in spreading the logon load among more domain controllers. In order to keep the PDC and BDC logon scripts synchronized, the servers usually have the replication service installed. Typically, a shared export directory keeps the updated logon scripts and files, which are then replicated, on a regular basis, to the import directories of all the domain controllers. Remember that the user accounts database is automatically kept synchronized as part of Windows NT domain handling; only the logon script directory tree requires replication setup.

A Member Server is any Windows NT Server computer in a domain that is not acting as a domain controller. Its participation in the domain is almost identical to a system running Windows NT Workstation. Member Servers are typically used as resource-intensive servers, running applications such as Microsoft SQL Server.

If a stand-alone server is being set up, it’s best to make it part of a workgroup, instead of yielding to the temptation to create a domain with it. That’s a common mistake, and makes the process of moving the server later to a specific domain much more painful. While a workgroup server may join a domain at any time and become a member server, a PDC or BDC requires a re-install of Windows NT Server to join another domain. You may also move a member server from one domain to another, if the need arises.

As the number of users and computers in a single domain grows, it may become too complex to be handled as a single domain. Also, you may wish to distribute into smaller groups, tasks which it was once advantageous to centralize: administration, security, or control of resources. The four domain models—single domain, complete trust, master domain, and multiple-master domain—represent various stages of growth and decentralization.

In the Single User Logon section, we briefly described trust relationships. Understanding three of the models requires an understanding of trust relationships. Basically, in a trust relationship one domain trusts the authentication done by another domain. For example, if a domain called Nashville trusts a domain called Memphis, then a Memphis user could log on to a workstation in the Nashville domain using his Memphis domain authentication. Unless Memphis trusts Nashville as well, the reverse (a Nashville user logging on to a computer in the Memphis domain) is not true.

In representing trust relationships, we typically use arrows. The arrowheads point to the domain being trusted; a two-headed arrow represents a two-way trust relationship. If you always remember that a domain only knows about users in its own account database, and those in the domains to which it points, trust relationships won’t give you any trouble. Using our Nashville trusting Memphis example, the arrow would point from Nashville to Memphis, like so:

Nashville Þ Memphis

The single domain model is the one we’ve been describing so far: it has a PDC and zero or more BDCs, along with whatever workstations it contains. It is the basis for the other models. It is the most centralized domain model.

When two or more domains want to start sharing their accounts and resources with each other, you set up two-way trust relationships with each of them. Figure 11-4 illustrates complete trust relationships among four domains. These relationships are set up when, for example, departments of a company have been using separate domains, and they decide they need to share resources with each other. They keep control of their own accounts and resources, but make them available, as they wish, with other domains. This can quickly become unwieldy with more than a handful of domains. Complete Trust is the most decentralized domain model.

The master domain model is most popular in large organizations that wish to keep centralized account maintenance, but utilize distributed resources. Figure 11-5 illustrates such a relationship, with Memphis as the master domain. The master domain contains all of the user accounts for the entire organization. Resource domains are created which trust the master domain, and offer file, print, or application services to the master domain users. The PDC in the master domain acts as the central account administration point for the entire organization. There are usually several BDCs in the master domain for an organization of considerable size, although the resource domains may be small or large.

If an organization using the master domain model becomes so large that it must break up the users into more than one domain, it may use a multiple master domain model. Another good candidate for multiple master domains is a geographically diverse organization with slow network links between sites—the occasional user from one site can authenticate from his own site when visiting. In Figure 11-6, Memphis and Nashville are both master domains; Knoxville and Chattanooga are resource domains. In the multiple master domain model, the master domains establish two-way trust relationships with each other, while the resource domains have one-way trusts with each of the master domains. Now there are multiple account maintenance points, and tasks such as group membership assignments must be duplicated manually on all master domains to keep them consistent.

While the Workstation exam doesn’t emphasize domain models, a basic understanding of them adds to your understanding of domains.

Let’s take a moment for a quick question and answer session on workgroups and domains.

Q: "My home office business uses three Windows NT Workstation computers…"

A: Use a common workgroup.

Q: "I’m setting up a SQL Server on a new Windows NT Server in an existing domain…"

A: Install the Windows NT Server as a member server, then install SQL Server on it.

Q: "I commonly work on two different domains. How do I set up my Windows NT Workstation for both?"

A: If at all possible, a trust relationship should be set up. If one domain trusts another, set up your workstation in the trusted domain. If you have two-way trust, add it to the domain you use most. A computer can’t be a member of multiple domains.

Q: "I’m in a domain, but would like to share the printer attached to my workstation with others…"

A: Set up a share with permissions for a local group, to which you’ve added the domain users or global groups you want to allow to print there.

Q: "I want to log on to the domain but still have administrative access to my Windows NT Workstation…"

A: Log on to your workstation as an administrator and add your domain account to the local Administrators group.

Q: "I don’t want my Windows NT Workstation to be in a workgroup or domain…"

A: You have to be in one or the other. You may choose a workgroup not in use.

Q: "I have trouble with users keeping their Windows 95 and domain passwords synchronized…"

A: If feasible, migrate to Windows NT Workstation. Then you’ll only need one password.

No one would bother to install a network if they didn’t need to communicate with other systems. In order to communicate with other systems, you first have to be able to locate them. A network browser keeps a list of domains, workgroups, computers, and other shared resources it sees on the network. This list is often called the browse list. When you explore the Network Neighborhood, a browser provides the information you see.

It’s important to make a distinction at this point between a computer such as Windows 95 or Windows NT Workstation running a server service, and a system running Windows NT Server. Any system capable of sharing resources like printers or file shares is running a server service, and is part of the browse list. When discussing browsing, we always use the term server to mean server service, and not a Windows NT Server, unless it is specifically mentioned.

If you’ve done much work with computers on networks, you’ve probably browsed the network many times, without knowing all the work that goes on behind the scenes. This exercise is just a quick tour of the neighborhood, for those of you who aren’t familiar with the territory.

1. Double-click Network Neighborhood on the desktop. The Network Neighborhood window appears. You see an icon for the Entire Network, and your computer listed below it, perhaps with other computers in your workgroup or domain.
2. Double-click Entire Network. Which window you see depends whether you have both Microsoft Windows Network and NetWare, or Compatible Network protocols running on your computer. If you have both, double-click Microsoft Windows Network.
3. You should be looking at little three-computer pyramid icons next to all the workgroups and domains available on your network. Find your domain or workgroup, and double-click it.
4. You should have a screen remarkably similar to the one you brought up in step 1. If you’re in a domain, you should be able to double-click your domain controller and see some shares there.
5. Close out the window for your workgroup or domain, and explore some others. There’s a good chance you won’t have access to the shares those systems have. If you’re able to get to something you think you shouldn’t, contact your network administrator. He or she may need to have a security discussion with someone.

A computer on the network can have one of many browser roles. The role it plays can change as nodes come and go. Although it’s easier to imagine one role per computer, a single computer may in fact have multiple roles, if it is using multiple network protocols. A system may be a Potential Browser with TCP/IP, and a Backup Browser with IPX, for example. The roles are really only meaningful within a particular protocol, so we’ll discuss each role as if we are running only one protocol.

The Master Browser keeps the browse list for all the systems in its workgroup or domain. The browse list for which it’s responsible includes all the server resources inside its workgroup or domain, and a list of the other workgroups and domains about which it has information. In a domain, the PDC is always the Master Browser. If you have a TCP/IP network with routers, there is a Master Browser for each subnetwork, in each domain that spans subnetworks. Workgroups are not permitted to span subnetworks.

The Backup Browser is to the Master Browser much like the BDC is to the PDC. It receives the updated browse list from the Master Browser, and can distribute it on request to other systems in the workgroup or domain. It updates the list every 15 minutes from the Master Browser. The number of Backup Browsers you have depends on the number of systems in the workgroup or domain.

Any system that is capable of browsing, but isn’t currently browsing, is a potential browser. Computers running Windows NT 3.1 or higher, Windows for Workgroups 3.11, or Windows 9x can be browsers. In a later section, we’ll cover what determines which computers actually are elected to the position.

I mentioned already that, in a domain that spans subnetworks, there is a Master Browser for each subnetwork.. The Domain Master Browser is responsible for keeping track of all the Master Browsers, and keeps a master list of domain resources for them. The PDC is always the Domain Master Browser for a domain.

A system can be designated as a Preferred Master Browser. This gives the system preference over similarly configured systems to become a Master Browser.

A system that could browse can be designated as a Non-Browser. This designation totally eliminates it from being selected as a Master or Backup Browser.

You can influence some of the factors used to determine browsing status for a computer. We’ve already mentioned Preferred Master Browser and Non-Browser. Now let’s discuss how to configure a Windows NT Workstation as one of these roles.

There is a Registry setting IsDomainMaster, which is false by default. If you wish to give preference to a computer to become the Master Browser, you can change this value to true. It gives the computer a slightly higher vote over others of its class in browser elections. The Preferred Master setting isn’t sufficient for a Windows NT Server to be elected over the PDC. See Exercise 11-6 for Registry details.

Both this exercise and exercise 11-7 require making modifications to your computer’s Registry. There’s no user interface for these options, other than the Registry editor. You should exercise extreme caution when editing your Registry, as mistakes can be fatal to your system, and Microsoft won’t lift a finger to help if you were playing with the Registry. Now that you’ve been warned, let’s go edit the Registry!

1. Select Start | Run and type regedt32 in the dialog box, and click OK.
2. If you were just going to browse around, now would be a good place to select Options, and check Read Only Mode. Since we’re actually going to make changes, make sure it’s not checked.
3. Inside Registry Editor, open the window titled HKEY_LOCAL_MACHINE.
4. Double-click SYSTEM in the left panel. This should show you more folders under SYSTEM in the left panel. You can ignore anything in the right panel until we get where we’re going.
5. Double-click CurrentControlSet, then Services, then Browser, and finally click Parameters. You should end up with something similar to the window in Figure 11-7.



Figure 7: Changing parameters with the Registry Editor.

6. In the right panel, you should see IsDomainMaster. Double-click it to change the value.
7. Type TRUE to replace FALSE in the String Editor window, and click OK.
8. The value showing in the right panel should now show TRUE.
9. If you plan to do exercise 11-7, stop here to keep from having to navigate back. Otherwise, select Registry and Exit.

Registry entries are typically listed with their full path, just as if they were actual folders. We just edited

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters\IsDomainMaster

and changed it’s value.

There is another Registry setting "MaintainServerList" which is "Auto" by default on Windows NT Workstations, and "Yes" by default on Windows NT Servers. If you change the value to "No", the computer will never be a browser. See Exercise 11-7 for Registry details.

The automatic setting lets the Master Browser tell the system whether or not it needs to become a Backup Browser. The Master Browser determines the number of Backup Browsers the system needs, based on the size of the workgroup or domain. If there aren’t enough existing browsers, one of the systems with the automatic setting is be told to become a Backup Browser.

1. Read the caution in exercise 11-6 again, and perform steps 1-5 if you don’t have the Registry editor window left from exercise 11-6.
2. Note what value MaintainServerList has. You may wish to reset your Registry back to this value later.
3. Double-click MaintainServerList. You can set the value to Yes, No, or Auto, which have already been explained. Click OK after you’ve typed in the value you want.
4. Select Registry and Exit.

Browsing is somewhat more organized than the name might imply. "Designated listener" would probably be a more descriptive term than Master Browser, but it’s called browsing, for better or worse. The basic elements of the browsing process are:

1. Announcing. Each computer acting as a server sends an announcement of the services it has available. The Master Browser maintains a list of these announcements, and makes them available to the Backup Browsers.
2. Browse List Copy Pass. Each Backup Browser retrieves an updated list every 15 minutes.
3. Call Master Browser (Initial List Request). The first time a system wishes to browse the network, it sends a request to the Master Browser for a list of Backup Browsers. It selects and stores three of the names. It then continues with step 4.
4. Call Backup Browser (Server List Request). The actual request for a list of network resources is sent to a Backup Browser. One of the three stored in step 3 is selected at random.
5. Contact Resource Server. Once the resource server has been identified, it can be contacted about the resource in question.
6. Access Resource. Finally, the server contacted provides access to the resource it announced in step 1.

Browser elections are often viewed as things of great mystery. Heads nod knowingly when you speak of browsing trouble and browser elections. Actually, understanding which browser wins an election is not that complicated. But the cause of an election can be difficult to determine, if you’re having network connectivity problems.

A browser election occurs when a system sends out an election datagram. This is a packet that includes that system’s election criteria. All browsers receive the datagram. A system whose own criteria beat the criteria it receives sends out its own datagram, and enters an election in progress state. It’s similar to a bid process at an auction, but you can only bid a predetermined amount. If the bidding has already passed what you can "afford", you keep silent and listen to see who wins. In order to speed up the election process, each bid is made after a delay, with likely winners having a shorter delay. This usually means that systems unlikely to win the election remain silent during the process.

A system should send out an election datagram when any one of the following happen:

The major determining factor of who wins a browser election is the operating system. Windows NT Server beats Windows NT Workstation, which beats Windows 95 or Windows for Workgroups.

Since Windows NT makes a much better browser than other Windows systems, you can improve the browsing in a workgroup with other Windows operating systems by adding a couple of Windows NT Workstations to the mix. They’ll automatically end up as the browsers for the workgroup.

Later versions of operating systems get preference over earlier versions. There are certain other "version bonuses" which are given. Here they are in order of importance:

1. Being the Primary Domain Controller (PDC) (huge bonus)
2. Running a WINS server (fairly large bonus)
3. Preferred Master Browser
4. Currently the Master Browser
5. MaintainServerList is Yes instead of Auto
6. Currently a Backup Browser

The bonuses are cumulative, so a system running a WINS server, Preferred Master Browser set, and MaintainServerList set to Auto beats out a system running a WINS server, without Preferred Master Browser set, and MaintainServerList set to Yes.

If all the previous criteria match, the system that has been browsing the longest wins. This is more likely to be the tiebreaker in a workgroup, with all systems having the same operating system and default settings.

In the unlikely event that the browsers also have been running the same length of time, the final tiebreaker is the node name. The node that comes first alphabetically wins. At this point, one system would have no advantage over the other, so an arbitrary choice based on node name is as good as any other method.

We’ve seen how the browsing process and browser elections work. There are just a few more items worth mentioning before we can conclude our discussion on browsing.

In the section on the browsing process, we briefly described routine browser communications. The announcements happen every 1-12 minutes. (The new announcements happen in intervals of 1, 2, 4, 8, and 12 minutes. Once 12 minutes is reached, it remains the interval between subsequent announcements.) The Master Browser listens to these announcements, and maintains a list.

If you can see Microsoft Networking workgroups and domains, but are having trouble browsing IPX servers, the trouble is often with the frame type on the Master Browser. This is a problem especially when you select the default auto-detection of frame types, and someone adds a system using a preferred frame type over the one you were using. For example: If you’re using Ethernet II on your servers as the frame type, and someone adds a node using 802.2-type frames, communications and browsing will be disrupted the next time networking is started on a system and it’s elected a Master Browser (because of the preference order in auto-detection).

If you want to tell which systems are your Master and Backup Browsers, there’s a diagnostic utility in the Windows NT Server Resource Kit called Browser Monitor (BROWMON.EXE). It shows the Master Browser for each protocol, and double-clicking a Master Browser shows all Backup Browsers, as well as the list of systems and domains they are maintaining in their lists.

If a server makes no announcement for three consecutive announcement intervals, the Master Browser removes the system from the list. If the system that crashes is the Master Browser, we’ve already seen that the first system that notices it’s gone will force a new election.

Backup Browsers get an updated list from the Master Browser every 15 minutes. This interval is long enough to ensure that a complete announcement cycle has passed and been processed. Since it’s the Backup Browsers that serve the lists to clients, there is some lag time after a system actually disappears, before it disappears from a client’s browse list. The maximum length of time to be removed from the Master Browser list is: 36 minutes (3 times 12 minutes), plus up to 15 minutes for the Backup Browser to get the updated list, for a total of 51 minutes.

The number of Backup Browsers depends on the size of the workgroup or domain. With one computer, there’s just a Master Browser and no backups. With 2-31 computers, there is one Backup Browser. For each additional 32 computers in the workgroup or domain, another Backup Browser is added. If you’re dealing with subnetworks, the rules apply for each subnetwork.

Workgroups and domains are important Windows NT concepts to master. Workgroups do little more than determine the systems that participate in browsing together. Windows NT Workstations and Servers may participate in workgroups, as can Windows 95 and Windows for Workgroups 3.11. The only time a Windows NT Server can’t enter and leave workgroups or domains is when it’s a domain controller.

Domains are the cornerstone of Windows NT networking, and offer much more than just browsing groups. Single-user logon and centralized administration, security, and control of resources are a domain’s main features. A Windows NT Server may be a primary domain controller (PDC), a backup domain controller (BDC), or a member server. You must have a PDC to start a new domain.

Browsing allows computers on a network to find each other. A Master Browser listens to all the server announcements, and maintains a list. This list is periodically retrieved by Backup Browsers, which in turn serve the information to Non-Browsers whenever requested. The primary determining factor of who is elected Master Browser is the operating system type. Other factors include the operating system version, certain Registry settings, other roles of the computer, and current browsing status.

In order to pass the certification exam, you should have a through knowledge of workgroups and domains, and understand the role of browsing and the fundamentals of how it works.

1. Sally, Bob, and Ed are engineers using computers running Windows NT Workstation. They occasionally like to share files with each other, and the files are too big to fit on a floppy, but they don’t want just anyone to be able to access the files. What is the best solution to their problem?
1. Buy another computer, install Windows NT Server, and have them all join the domain. Then, set up a shared directory on the new server for the files.
2. Buy them all larger removable drives, and let them swap them around the office.
3. Use a software compression program to pack the files on floppies.
4. Set up accounts for all three of them on each workstation, and set up shares for the files with these accounts.
5. Tell them to use whatever workstation has the files they need.
2. A workgroup consists of a Windows NT Server, a Windows NT Workstation, a Windows 95 system, and a Windows for Workgroups system. The Windows NT Workstation has MaintainServerList set to Yes and Preferred Master Browser set. Each of the others has default browser settings, and all are using the same network protocol. Which of the following is true:
1. The Windows NT Server will be the Master Browser, and the Windows NT Workstation will be the Backup Browser.
2. The Windows NT Workstation will be the Master Browser, and the Windows NT Server will be the Backup Browser.
3. The Windows for Workgroups system will be the Master Browser, and the other systems will be Backup Browsers.
4. Each system will browse for itself, because they’re running different operating systems.
5. None of the above, because you can’t have a Windows NT Server in a workgroup.
3. A system shows up in the Network Neighborhood, but the user is unable to connect to its resources as he has in the past. Which of the following are good hypotheses to troubleshoot the problem:
1. The user just thought he was able to connect to the resources in the past. Ignore him.
2. The system is actually down, but hasn’t been down long enough to be removed from the browse list as yet.
3. It must be a problem with user security access to the resource.
4. The target system is in the same workgroup, and the user has changed his password recently.
5. The target system is in the same domain, and the user has changed his password recently.
4. A user has just changed his password while logged into the domain on one workstation. He logs out and immediately goes to another workstation in the domain and can’t get logged in. Which of the following might be true:
1. Caps Lock might be in a different state.
2. He’s trying his old password, thinking he hasn’t changed it on this workstation yet.
3. The current workstation happened to authenticate from the Backup Domain Controller, and it hasn’t been updated yet.
4. He’s not allowed to log on at that workstation.
5. This workstation was down when the password change was made.
5. Ted, Jill, and Janet are users on Windows NT Workstations belonging to a domain. They always log on to the domain at their workstations. They have administrator access to their workstations, but aren’t domain administrators. They’d like to share files on their workstations with each other using group access, with the ability to make changes themselves (without a domain administrator). Which option is the best:
1. Each one should set up workstation accounts for the others, just as they would in a workgroup, and add them to a local group.
2. Each one should create a local group on their workstation, and add the domain usernames of all of them to the group.
3. One of them should create a global group on their workstation, letting the others use it.
4. One of them should create a global group on a member server, letting the others use it.
5. What they want to do can’t be done without the aid of a domain administrator.
6. Which of the following give a computer preference in browser elections?
1. Being a Backup Domain Controller
2. Being a Primary Domain Controller
3. Running Windows Internet Naming Service
4. Currently the Master Browser
5. MaintainServerList is Auto
7. Which of the following are true statements about workgroup and domain membership?
1. A workstation can be a member of both a workgroup and a domain
2. A user logging on to a domain has only one username and password to remember
3. A system running Windows NT Server may be a member of a workgroup
4. A system running Windows NT Server is required for domain creation
5. If you give a workstation a workgroup name that matches an existing domain, it will browse with that domain without being a domain member.
8. David is a domain administrator running Windows NT Workstation at his desk. Which of the following are true statements:
1. David can log on to the domain and have administrator access to his workstation.
2. David can log on to the domain and have administrator access to the domain.
3. David must have a roaming profile to log on to another workstation.
4. David enjoys the power he wields over other users, who are subject to his every whim.
5. David is always the Master Browser.
9. Jane wants her Windows NT Workstation to join the domain. She has selected Domain and typed in the correct name in the Identification Changes window. What can she do:
1. If she’s a domain administrator, she can check the box Create a Computer Account in the Domain and enter her username and password and click OK to join.
2. Even if she’s not an administrator, she could do as in answer A, as long as she’s the current logged on user.
3. She can contact a domain administrator to add her node name in Server Manager before clicking OK to join.
4. She can have a domain administrator come to her workstation and enter his own username and password as in answer A.
5. Since Windows NT Workstations must select their workgroup or domain at installation, she can't join the domain without reinstalling.
10. Twenty-five users running Windows NT Workstations in a workgroup wish to share resources. What’s their best solution?
1. Set up accounts for everyone on each workstation.
2. Invest in a Windows NT Server and add it to the workgroup. Place all the resources on the server.
3. Invest in a Windows NT Server and create a domain, adding all the workstations to the domain. Any resources may be moved to the server if desired.
4. Same as answer A, but publish and maintain a list of usernames and passwords, so that each user can keep his own workstation’s account information for all users synchronized with the rest.
5. Invest in a Windows NT Server and create a domain. Have each workstation join its own individual workgroup, so that no two are in the same group.
11. The Marketing domain spans multiple subnetworks on a routed network. The PDC server becomes unavailable due to hardware problems, but you have a couple of BDCs. After a while, users report problems seeing other nodes on the network. What happened, and how do you fix the problem?
1. Since the PDC must be the Master Browser for the domain, there is none now, and other nodes are unreachable. Wait for a BDC to automatically be promoted to PDC.
2. Since the PDC was the domain Master Browser, each subnetwork’s Master Browser only sees computers on its subnetwork. Promote a BDC to PDC, so that it will become a new domain Master Browser.
3. Since a domain requires a PDC to run, quickly promote your workstation to be a new PDC for the domain. Disappearing nodes are the least of your problems!
4. The problem is temporary, and will go away once a browser election is held and a new domain Master Browser is elected.
5. Since the PDC was both domain Master Browser and Master Browser for its subnetwork, browsing can’t continue in the domain until you replace the server with another.
12. Ned and Lonnie work different shifts at the rock quarry. They use the same Windows NT Workstation, which is a member of a domain. Which of the following could be true for Ned to log on to the workstation:
1. Ned has a local account on the workstation.
2. Ned has a domain account in the workstation’s domain.
3. Ned has a domain account in a domain trusted by the workstation’s domain.
4. Ned has a domain account in a domain that trusts the workstation’s domain.
5. Ned has a local account on a workstation that this workstation trusts.
13. Ned’s shift has been changed, and he now works with Lonnie. There are now two Windows NT Workstations that either may log on to, with identical software setups. What’s the best way to preserve their desktops for both computers?
1. Have an administrator copy their last used profile over to the other workstation every day.
2. Use the same mandatory profile for everyone, so the desktop is consistent everywhere without tracking changes.
3. Set up roaming profiles for Ned and Lonnie.
4. Assign each his own workstation, and tell them to log on only to the one to which they’re assigned.
5. Tell them if they can’t agree on a desktop, they’re going back to busting rock!
14. Earnest has an account in each of the two domains, Seeming and Being. Earnest is a domain administrator in Being, but just a normal user in Seeming. Domain Seeming trusts Being, and also has added Being\Domain Admins to the local Administrator’s group on the PDC for Seeming. If Earnest wants to log on to the PDC for Seeming to administer it, what must he do?
1. He can’t do anything; he’s just a user in the Seeming domain.
2. He can log on to the Seeming PDC using his Seeming account, then switch to an administrative user.
3. He can log on to the Being PDC using his Being account and set his environment to the Seeming PDC.
4. He can log on to the Seeming PDC using his Being account.
5. He can log on to the Being PDC using his Seeming account.
15. You’re looking at the Network Neighborhood for your domain. You see systems listed for which you know you haven’t set up a computer account in the domain, and they don’t appear in Server Manager. Which of the following could explain the situation?
1. The systems aren’t Windows NT Workstations or Servers, and have been configured to participate in the domain.
2. The systems used your domain name as their workgroup name.
3. Someone added the Windows NT Workstations or Servers by checking Create a Computer Account in the Domain instead of using Server Manager
4. The Master Browser for your domain is on the same subnetwork as the Master Browser for their domain.
5. Your domain didn’t have any potential browsers after your PDC crashed, so the other systems were added to make browsing possible.

1. D. Setting up two extra accounts on each workstation is manageable, and allows the users to share resources however they wish. Answer A is overkill for this situation, and is expensive. The other options are cumbersome and unnecessary.
2. A. Since there are four systems, there will be a Master Browser and one Backup Browser. Windows NT Server wins the browser election based on operating system, which is the predominant criterion. While the Windows NT Workstation would probably have been the Backup Browser anyway, having MaintainServerList set to Yes means the Master Browser won’t even have to ask one set to Auto to start browsing.
3. B and D. For B, remember that it can take up to 51 minutes for a system to be removed from the Network Neighborhood. If the system in question had been up a while, it would take at least 24 minutes to disappear from the neighborhood, assuming it went down just before its announcement, and that the Backup Browser updated its list immediately after the Master Browser removed it. For D, remembering that the passwords have to be maintained on each system in a workgroup is a clue, if the user tells you he had recently changed his password. While security might be the problem, C is wrong because it could have been one of the other things mentioned. E is unlikely in a domain, though user access could still have been set up using a local user database. A is only an option after you’ve eliminated everything else and determined that he never had access to begin with.
4. A, B, C, and D. The Caps Lock problem is so common, it’s mentioned in the error window that pops up when a failed logon attempt occurs. B would be a misunderstanding on the part of the user. Since the BDC may take up to 5 minutes to get the update from the PDC, scenario C occasionally happens. The administrator could have filled out workstation names using the Logon To button in User Manager for Domains, so D is also correct. E is false because the new workstation would have played no part in the change; the information is kept on the domain controllers.
5. B. In order to use groups while not involving a domain administrator, local workstation groups must be used. Using the domain user accounts will make the access work. Option A would require the users to log on to their workstations instead of the domain, and maintain additional passwords on each workstation. Option C is impossible: global groups don’t exist on Windows NT Workstation. Option D won’t work because only global groups on a domain controller are available to the domain. Since B works, E is also false.
6. B, C, and D. Being the PDC has the most effect, so B is true. Running a WINS server gives the next biggest bonus, so C is also true. Being the current Master Browser does give an advantage as well, so D is true. BDCs get no special treatment, so A is false. If MaintainServerList were Yes, it would help, but it is of no advantage when set to Auto, so E is false.
7. B, C, D, and E. Option E can be used to improve browsing for workstations that may later be joining the domain. They will show up in the Network Neighborhood just like the domain members, although they can’t participate in any other domain functions.
8. A and B. Since David is a domain administrator, and the Domain Administrator group is added to the local Administrators group on every workstation that joins the domain, he’s also a local administrator. Not only is he a domain administrator, but he may install the domain administrator tools on his workstation, and run User Manager for Domains as well as the local workstation User Manager. Roaming profiles aren’t required to logon to different workstations; they just help keep the same desktop environment if they have been set up, so C is false. While D is just a humorous response, if it were true, David’s career as an administrator would be very short. E is false because users aren’t browsers, computers are. Since David is using a domain, the Master Browser will be the PDC if it’s available.
9. A, C, and D. An administrator is required to create a computer account in the domain before the computer may join. This can be accomplished either in Server Manager or by entering any domain administrator’s username and password after selecting Create a Computer Account in the Domain. B is false because she’s not a domain administrator in that answer. E is also false: the only time a reinstall is required is when a Windows NT Server that was installed as the BDC or PDC for another domain wishes to join.
10. C. This is the only option that gives a central account database that can be used by all the workstations. Option A is basically unmanageable, while the additional suggestion in D just does away with any security you might have had. Just adding a Windows NT Server to the workgroup doesn’t change the situation, so B is out. Option E is actually worse than B, because now the systems aren’t even browsing together.
11. B. While the subnetwork the PDC was on will elect a new Master Browser, there is no domain Master Browser to tie the subnetworks together without a PDC. Therefore, promoting a BDC is the quickest way to restore network connectivity. Option A has pretty much everything wrong: the domain Master Browser is missing, not a Master Browser (one would have been elected), and promoting a BDC to the PDC is a manual process. Option C is also totally wrong: domains will still run with no PDC (though not well in the case of browsing subnetworks), NT Workstations can’t be domain controllers, and systems must be installed as domain controllers before they may be promoted. Option D is false because there is no election process for a domain Master Browser; it’s always the PDC, though a new Master Browser would have been elected for the old PDC’s subnetwork. While the first half of the statement in E is true, the Master Browser is a red herring, and you should promote a BDC instead of trying to replace the hardware and restore the old server (takes too long), though you might end up doing that in addition after promoting a BDC).
12. A, B, and C. The workstation can validate from it’s local account database, the account database of the domain of which it’s a member, or another domain trusted by that domain. If you said D, you’d better review the direction of trust relationships. E is totally bogus, since a workstation (or even a server) can’t enter a trust relationship; it’s a domain attribute.
13. C, though B gets honorable mention. Roaming profiles will provide them with their desktop regardless of which workstation they log on to. Option B gets honorable mention because it’s probably easier to maintain in their environment, though it doesn’t preserve any modifications they might make. Option A would work, but would be a lot of manual work. Option D might work depending on the situation, but begs the question of preserving the desktop across systems, so it’s not the best answer. Option E won’t make for very happy employees, and may not be what you want to say to someone who can bust rock.
14. D. The importance of Being\Earnest lies in Earnest as a member of Being\Domain Admins, and that group is a member of Administrators on the PDC. The Seeming\Earnest is a totally different account, and by default wouldn’t even be able to log on locally to the PDC, so option B is out. There’s no way to set environments as mentioned in C. E isn’t possible because there’s no trust relationship mentioned of Being trusting Seeming, and he wouldn’t be able to log on locally by default with that account, even if the trust existed.
15. A and B. Only Windows NT computers need computer accounts in the domain to participate. Any Windows system, even a Windows NT one, may give your domain name as its workgroup name and participate in browsing, but not the domain. Any computers added as in option C would also show up in Server Manager. Options D and E are total fabrications, and have no validity under any circumstances.