Chapter 11 from Windows NT Power Toolkit, published by New Riders Publishing

You must make some basic infrastructure decisions when planning for a network installation. As part of that process, you need to consider items such as security, information sharing, connectivity, user and resource location, and network administrative skills in your enterprise. You also need to determine the available skill set of your employees when deciding what type of networking model to employ.

This chapter focuses on the key elements in choosing and maintaining the network model that's most appropriate for your organization. Because the technology environment remains a moving target, this chapter also focuses on the long-term viability of your decision. It addresses often overlooked issues such as moving from a workgroup to a domain model or from one domain model to another. It also reviews the domain models that Microsoft recommends for most situations. Finally, this chapter reviews some third-party software tools related to network and domain management tasks.


Workgroup Networks Back to Top

Workgroup networks, or peer-to-peer networks, are network models that offer ease of setup, noncentralized security, and low costs as their key benefits. The workgroup networking model can contain a mixture of operating systems and hardware spread across a large geographic area. Typically, though, workgroups are smaller network installations used when employees have minimal network administrative skills, when money is an issue, when there are few networked computers or users, or when security is not a major concern.

The definition of a workgroup is a group of computers on a common network that are linked by a workgroup name. You can view the computers that are part of your workgroup in Network Neighborhood in Windows NT Workstation. You can easily move a particular computer from one workgroup to another.

To move a computer from one workgroup to another, do the following:

  1. Open Settings from the Start menu.
  2. Select the Control Panel.
  3. Double-click the Network icon.
  4. Select the Identification tab.
  5. Click the Change button.
  6. Specify the new workgroup name and then exit.

If the workgroup name you enter doesn't already exist, a new workgroup is created.

You can join a domain from this same dialog box if one exists. Instead of entering a different workgroup name, select the domain radio button and enter the name of the domain you want to join. For Windows NT machines, you must create a computer account in the domain by supplying a domain administrator ID and password. Assuming the account and password information is valid, you will be welcomed into the domain.

Security in a workgroup model is based on share-level security. In Windows NT Workstation, a local Security Accounts Manager (SAM) database contains local account information for user validation on that workstation. Resources can be password-protected. Users are not granted explicit access because there is no central authority for user validation as in a domain model; rather, resources are shared and, when required, protected with passwords. Workgroup models do not provide a robust security model; therefore, if security is of even moderate concern, you're better off using a domain model.

As previously mentioned, typical workgroups are small and are used for logical organization of a small group of computers. A network can consist of multiple workgroups. Assuming that your network is organized into workgroups, you can browse the network within Network Neighborhood. The view shows several workgroups rather than many individual computers, but those computers can be found within their specific workgroups at a lower level in the browser hierarchy. Workgroups do not, however, offer much in the way of centralized administration or user-level security. Domain-based networks were created to address these issues.


Domain-Based Networks Back to Top

A domain-based network differs from a workgroup-based network in that it contains users and computers that share a centralized security model and user account information. In a Windows NT network, a domain is like a medieval kingdom with a central authority or monarch (the PDC), members that participate in the monarchy as potential rulers (the BDCs), members that provide services to the kingdom but cannot participate in ruling the kingdom (member servers), and ordinary users as the commoners in that kingdom. A domain consists of users and resources just like a kingdom is made up of people and property.

Domain members do not necessarily need to be in the same geographical area; however, members all belong to the same domain. In fact, the purpose of a domain is to provide a more secure relationship among its members and better, more centralized control over its resources.

Domains, like kingdoms, do not trust one another without some negotiation. Advanced domain models use trust relationships to define trusts. Windows NT trusts are one-way, intransitive relationships. Using the kingdom metaphor, King George trusting Queen Alice does not imply that Alice trusts George. In addition, Alice trusting King Henry does not imply that George trusts Henry or that Henry trusts George. According to Microsoft documentation, Microsoft Windows 2000 will offer transitive trust relationships that will make such relationships possible.

When a computer running Windows NT Workstation or Windows NT Server logs on to a network, the NetLogon service on the client computer creates a secure communications channel with the NetLogon service on a domain controller. A secure communications channel exists when computers at each end of a connection are satisfied that the computer on the other end has correctly identified itself. Computers identify themselves using their computer accounts. When the secure channel is established, secure communications can take place between the two computers.

To maintain security during a communications session, internal trust accounts are set up between a workstation and a server, between the primary domain controllers (PDCs) and the backup domain controllers (BDCs), and between domain controllers in both domains when a trust relationship exists between the two domains.

Trust relationships and the secure channels they provide enable administrators to remotely manage workstations and member servers. Trusts also affect the relationships between workstations and domain servers and between PDCs and BDCs.

Primary and Backup Domain Controllers

The first Windows NT Server domain controller installed in a network automatically is designated a PDC. A PDC maintains the master copy of the security accounts (SAM) database. When a domain user password is changed, it is changed on the PDC, not the BDC. The BDC authenticates user logons. The BDC's copy of the SAM is exactly that, a copy. Changes to account and group information occur on the PDC. These changes are then replicated to the BDCs in the domain.

The NetLogon service provides users with a single access point to a domain's PDC and BDCs. NetLogon also synchronizes changes to the directory database stored on the PDC. The size of the directory database is limited only by the number of Registry entries permitted and by the performance limits of the computers and network connections involved.

The Windows NT Server NetLogon service automatically synchronizes the directory databases from the PDC to all BDCs. Based on settings in the Registry, the PDC sends timed notices that signal the BDCs to request directory changes from the PDC. These notices are staggered so that not all BDCs request changes at the same time. When a BDC requests changes, it informs the PDC of the last change it received so that the PDC always is aware of which BDC needs changes. If a BDC is up-to-date, the NetLogon service on the BDC does not request changes.

PDC and BDC Deployment

To successfully implement domains, you must clearly understand the roles of the PDC and BDC. The PDC is the first Windows NT Server created in a domain. Each domain can have only one PDC. The PDC contains the master SAM database. The SAM database is used to validate NetLogon requests; in fact, the primary role of the PDC is to manage this database.

The SAM houses all domain account information including user accounts, groups, and computer accounts. The primary identifier for each object in a domain is its security identifier, known as a SID. The SID uniquely identifies each component in a domain. When a PDC is renamed, its SID still identifies it uniquely. In fact, some Windows NT experts state this succinctly as "Users care about names; Windows NT cares about SIDs."

A BDC is responsible for authenticating user logon requests. BDCs maintain a replica of the master SAM that resides on the PDC. Therefore, the secondary responsibility for any PDC is to replicate its master SAM to all BDCs within the domain of the PDC. Should the PDC become unavailable, BDCs within a domain can authenticate user logon requests. This property makes BDCs a networking necessity. You should add an additional BDC to a domain for approximately every 2,000 users. For a domain in which users are located centrally, an additional BDC for every 4,000 to 5,000 users might be appropriate. Performance monitoring is essential when planning for and deploying BDCs.

The physical distribution of BDCs is determined by several factors, including line speed, link reliability, administrative access, protocols used, user authentication requirements, the number of users to be supported at a site, and locally available resources. For a domain model in which users are geographically dispersed, Microsoft recommends that you place a BDC in close proximity to each group of users.

Installing a BDC also is recommended for fault tolerance. You might, for example, have users in Houston, San Francisco, and New York who are upset that network logon requests take an extraordinary amount of time. If your PDC is located in Houston, place a BDC in San Francisco and another in New York. User logon requests will be validated through the local BDCs instead of traversing the WAN links back to Houston for authentication. If both the New York and Houston domain _controllers go down, San Francisco still can handle user authentication requests.

As BDCs are added to a domain, the PDC keeps each of them updated periodically. Therein lies a potential problem. If there are too many BDCs in a domain, unnecessary network traffic might be transmitted from the PDC to the BDCs as it works to keep their SAM replicas updated. We recommend that, on slow WAN links, you place a BDC on the remote subnet to handle local user authentication. The PDC will replicate on a periodic basis to the remote BDCs.

Also consider how much traffic the periodic account synchronization will cause on the WAN or Remote Access Service (RAS) dial-up lines. Avoid full synchronization across WAN links. Full synchronization is required when first setting up a new BDC or when bringing a new location online. Full synchronization also is initiated by default when more than 2,000 changes happen to users or groups in less than one hour. If you anticipate a large volume of change activity, increase the value for the size of the change log. If the preceding conditions do not exist, the synchronization process includes only those changes made to the directory database since the last time synchronization occurred.

Ask the following questions when considering placement of BDCs:

Configuring Replication

The following Registry entries relate to PDC and BDC replication. If a large number of BDCs are required or if replication is not completing because of overloaded WAN connections, the following settings can be added or changed to better manage replication. Note that Windows NT does not add any of these value entries to the Registry. You must add them by editing the Registry.

You can configure different replication rates at different times of the day by using REGINI.EXE, a tool on the Microsoft Windows NT Server 4.0 Resource Kit CD, and the AT utility, which is included in Windows NT. Write REGINI scripts that set and change the value of ReplicationGovernor and then use AT to execute the REGINI scripts when you want to change these values.

Choosing a Domain Model

A domain model defines the relationships between domains in a networked environment. Choosing a domain model depends on several factors. This section reviews Microsoft's recommendations including factors you should consider when choosing a domain model.

The size of a domain is restricted to the maximum size of a Windows NT security accounts (SAM) database. Microsoft's recommendation for maximum SAM size is 40MB. Unless you are part of an enormous organization, such as IBM or General Electric, a 40MB SAM satisfies the requirements for a very large domain. Every user account consumes about 1KB of SAM space. Every computer account uses 0.5KB of SAM space. Depending on the number of users in a group, groups consume between 3KB and 4KB of space on average.

The size limitation on the SAM database rarely comes into play. For larger networks that choose to maintain a single domain model, however, you might reach this limit. In any domain model, four types of computers can exist: PDCs, BDCs, member servers (Windows NT Servers that do not perform domain controller duties such as servers, print servers, and so on), and workstations (Microsoft Windows 95, Microsoft Windows 98, Windows NT Workstations, Microsoft Windows 3.11). When installed as domain controllers, Windows NT Servers are either PDCs or BDCs. The first one installed in a domain always is the PDC. The remaining domain controllers installed within the same domain are BDCs.

Table 11.1 Domain Model Recommendations by Domain Attribute

Domain Attribute
Single Domain
Single Master
Multiple Master
Independent Single with Trust Relationships
< 40,000 users per domain










> 40,000 users per domain










Centralized account management










Centralized resource management










Decentralized account management










Decentralized resource management










Central MIS










No central MIS










Single Domain Model

The single domain model consists of exactly one domain. It is like one castle with one lord, so to speak. According to Microsoft, "For ease of administration, the preferred domain model is the single domain model. If the single domain model cannot be used, the second choice should be the single master domain model. If neither of these is available, an administrator can use trust relationships to centralize all user administration into a single domain, eliminating the need to administer each domain separately." Further, "In a single domain network, network administrators can always administer all network servers because the ability to administer servers is at the domain level. The single domain model is an appropriate choice for organizations that require both centralized management of user accounts and the simplest domain model for ease of administration."

In the single domain model, the domain Administrators group can oversee all servers within the domain. This simplifies administration tremendously. A single administrator can manage the domain as long as the number of elements in it remains relatively small.

The single domain model allows expansion using multiple domains that have their own administrator or administrators. You can establish trust relationships to expand a single domain model. Each single domain is a separate entity, and trusts allow one domain's users to use another domain's resources. Trusts are discussed in greater detail in the "Single Master Domain Model" section that follows. A trust relationship involves users and resources. The domain with the resources trusts users to use the resources properly. The domain containing the resources is the one that must trust the other domain and therefore is called a trusting domain. The domain with the users is trusted with some resource and is known as the trusted domain.

A trust does not, however, ease administrative burdens. Each domain is separate and has its own users and administrator. With large enterprise networks that include numerous domains and trust relationships, tracking and managing trusts can be a time-consuming endeavor. As networks increase in size or scope, the single master domain model often is a more efficient option.

Single Master Domain Model

The single master domain model consists of a number of domains, one of which—the single master domain—acts as a centralized administrative domain for user accounts named.

All user and machine accounts are defined in the master domain, and all user accounts belong to the master domain. Resources such as printers and file servers are located in the resource domains. Each resource domain establishes a one-way trust with the master domain that enables users with accounts in the master domain to access resources in all the resource domains. A system administrator can manage the entire multidomain network, users, and resources. This model balances the requirements for account security with the need for readily available resources on a network because users obtain permission to access resources based on their master domain logon identity.

The single master domain model offers numerous benefits including the following:

To construct a single master domain:

  1. Create a domain.
  2. Install Windows NT Server as a domain controller. As the first controller in the domain, it becomes the PDC and maintains the master SAM database. Designate this domain as the master.
  3. Add all user accounts to this domain.
  4. Install a BDC for logon fault tolerance and load balancing.
  5. Create one or more resource domains.
  6. Install Windows NT Server as a domain controller for each resource domain. As the first server in the resource domain, it becomes a PDC and contains the master SAM database for this domain.
  7. This domain and any others will function as resource domains.
  8. Even in resource domains, it makes sense to install BDCs for the master domain, especially if users log on locally in those parts of the network. Larger departments also should consider installing BDCs for resource domains.
  9. Establish a trust relationship. The master domain contains the domain users, and the resource domains contain their respective resources such as files and printers. Remember that the domain with the resources always is the trusting domain, and the people domain always is the trusted domain. In Microsoft documentation, the trust arrow always points to the users.
  10. Using User Manager for Domains, select Trust Relationships from the Policies menu.
  11. Next to Trusted Domains, click the Add button. Enter the name of the master domain in the dialog box along with a password. The password is for the trust relationship, not a Windows NT account.
  12. From the User menu, choose Select Domain.
  13. Select the resource domain with which you want to establish the trust _relationship.
  14. Next to the Trusting Domains field, click the Add button. Enter the name of the resource domain with a password for the trust relationship. Remember that trusting domains trust domains containing users (in this case, the master domain).

If either the trusted or trusting domain cancels its trust relationship, the trust is over. In User Manager for Domains, perform the following steps to completely remove a trust:

  1. Choose Select Domain from the User menu and choose the Trusted domain.
  2. From the Policies menu, select Trust Relationships.
  3. Select the domain name from the Trusted Domains window and click Remove.
  4. Choose Select Domain from the User menu and choose the Trusting domain.
  5. From the Policies menu, select Trust Relationships.
  6. Select the domain name from the Trusting Domains windows and click Remove.

The single master domain model is a two-tiered model in which every resource domain must have a trust set up with the master domain because these trust relationships are nontransitive. Microsoft's recommended 15,000 object limit now applies to user IDs and groups only because the file, print, and application server objects exist in the resource domains.

Multiple Master Domain Model

Use the multiple master domain model when you reach the recommended 15,000 user ID and group object limit within a master domain. To implement the multiple master domain model, set up a one-way trust between each resource domain and every master domain. In addition, two one-way trusts must be established between each pair of master domains.

In addition to object counts, other factors must be considered in an enterprise Windows NT domain design. Among these factors are organization, geography, administration, security, and scalability for future growth.

Organizational issues might include budget issues. Keep in mind that the fewer domains there are, the lower the cost of associated equipment will be to implement the multiple master domain model. If resources are separated for each organizational unit, however, it might be in the best interest of the organization to use separate domains. If these domains are dispersed geographically, political factors can influence the location and control of the master domains involved.

Several geographical issues can influence whether you decide to use the multiple master domain model. For example, how robust is your wide area network (WAN)? The more robust the WAN, the more flexibility your domain design can tolerate. Because domains can be separated geographically, additional local resources might be required to manage this model, especially when 24-7 operation might be required.

You can use the following equation to calculate the number of trusts needed in the multiple master domain model (where n is the number of domains and m is the number of master domains):

(n-m)*m + m / (m-2)

Complete Trust Domain Model

The complete trust model is basically a multiple master domain model in which every pair of domains has two one-way trusts. Every domain effectively becomes a peer to every other domain. Each domain can contain users and resources. The key administrative overhead item with this model is maintaining the trusts. This is the best model for large, decentralized organizations in which providing access for any user to any resource is the most important factor.

To calculate the number of trust relationships required, use the following formula (where n is a domain):

Number of domains equals n [infin] (n–1)

For 10 domains, 10[infin]9=90 trusts must be established to fulfill the requirements for a complete trust domain model. For 100 domains, this number grows to a staggering 9900 (100[infin]99)!


Understanding Groups Back to Top

Groups are the most frequently mismanaged element in Windows NT or any other network operating system. Understanding group creation and management is essential to minimizing administrative overhead, managing security, and assuring maintainability of Windows NT Servers and domains. Windows NT supports two types of groups: global and local.

Microsoft has an acronym for user management in Windows NT: AGLP. AGLP stands for domain Accounts go in Global groups, global groups go in Local groups, and local groups are assigned Permissions. Although this might seem simple, Windows NT includes built-in local groups and default permissions that can complicate group management if you are unaware of them. Without knowledge of default groups and permissions related to domain controllers, member servers, Windows NT Workstations, shares, and the Registry, you can open your network to security risks. This section reviews default groups, built-in groups, default permissions for those groups, and how to apply proper security.

Global groups are essentially domain groups and are created on the PDC. A global group can contain only user accounts from the domain in which they were created. Global groups cannot contain local groups. On the other hand, local groups can contain user accounts and global groups from any trusted domain. A local group cannot contain other local groups. Given an appropriate strategy for managing users and groups, this makes perfect sense.

When defining a domain strategy for groups, the key is to minimize local group creation. As with database normalization, find the least common denominator—the most common thread—that links users and place those user accounts into a common group. The benefit of this strategy is that you can assign common user rights without the need to create superfluous groups. Default groups predefined in Windows NT can aid this process.

A computer will have different built-in groups depending on the role it plays in a network. Windows NT domain controllers include the following default local groups:

In addition to the preceding groups, Windows NT domain controllers have the following global groups:

Windows NT member servers and Windows NT Workstations include the following built-in groups:

Windows NT provides more than we ask for. Some of these built-in groups contain other groups by default. Being aware of these groups is essential to managing security properly and to minimizing administrative overhead (see Table 11.2).

Table 11.2 Default Group Members in Windows NT

Default Members
Administrators (local)


Domain Admins (global)


Domain Admins (global)


Administrator (default user)


Domain Guests (global)


Guest (default user)


Domain Users (global)


Administrator (default user)


Guests (local)


Domain Guests (global)


Users (local)


Domain Users (global)


In addition to default global groups within default local groups, Windows NT specifies another relationship that exists inherently within the system. The Everyone group is an intrinsic group whose membership consists of all local and network domain users logged in at any time. Known security issues that exist with Everyone include shares, New Technology File System (NTFS) drives, and the Registry. By default, when a new share is created, Everyone is granted Full Control. When a new NTFS partition is created, Everyone is granted Full Control. In the Registry, the HKEY_LOCAL_MACHINE root gives Everyone Read permissions. Some Registry keys also give Everyone Full Control. You must be aware of what the Everyone group is given by default so you can close up such breaches in security.

Assigning users to the proper group simplifies user and group management. The following sections explore the groups built into Windows NT by default.


The Administrators group has complete control over the domain as well as servers, workstations, groups, and resources within the domain. Administrators are superusers in the domain and therefore have rights and permissions to manage all aspects of the domain. Administrators, by default, have Take Ownership permissions. Although you might think NTFS permissions forbid the Administrator to access your files, the Administrator can take ownership of those files and change the NTFS permissions.

Account Operators

The Account Operators group does not contain any users or other groups by default. Account Operators can create and manage user account information in the domain to which they belong. It is interesting to note that Account Operators cannot manage user and group accounts created by Administrators; rather, Account Operators create accounts and add those accounts into groups that have been previously set up by an Administrator. Account Operators cannot assign user rights.

Backup Operators

By default, Administrators, Backup Operators, and Server Operators have the rights to back up and restore Windows NT volumes, directories, and files. Backup Operators can specifically back up and restore files even when Read and Write permissions have not been explicitly given to the group's members.

The Backup Operators group is empty by default. It is common practice in an enterprise environment to define a global group named Backup Operators into which the personnel responsible for backups are added. On each domain controller and member server, the global Backup Operators group is added to the local Backup Operators group. This promotes simplified group management. Backup Operators can shut down servers, but they cannot change security settings on the files they are permitted to back up.

Domain Admins

Each local Administrators group contains a global group called Domain Admins. This group is added by default to the local Administrators group to give domain administrators access to newly created Windows NT computers. This implies that all Domain Admins are domain administrators. Depending on your networking model and your definition of administration, new administrators can be added either into the global Domain Admins, effectively granting permissions to all servers in the domain, or into the local Administrators group on specific machines, thereby granting permissions only to the specified computers.


The Guest account is disabled by default. Guests are exactly that—guests. Just like someone visiting your home, you don't have complete knowledge of or confidence in a Guest. Guests must log into resources over a network and cannot log on locally. Typical installations never use the Guest account, and it is recommended that you leave the Guest account disabled.

Domain Guests

The Guest account is included by default in the Domain Guests group, and the Domain Guests group is a default member of local Guests. This group is specifically used to grant Guests permissions across multiple domains.

Domain Users

When an account is created in a domain, it automatically becomes a member of the Domain Users group. Because the Domain Users group is a default group within the local group Users, each member of Domain Users can connect to the network from any machine on the network unless specific policies prevent this practice.

Power Users

The Power Users group is commonly misunderstood. A Power User has rights and privileges much like a Server Operator except that the Power User group appears by default on only Windows NT Workstation machines. Power Users have default administrative-like rights that permit user management for the users they create. Power users also can add users to the Guests, Power Users, and Users groups. Power Users have local machine permissions to share and remove file and printer shares.

Print Operators

In addition to complete management of printer-related duties, Print Operators have the capability to log on locally to a server and to shut down a server.


Replicator is a system-level group used only for Windows NT's built-in directory replication service. This group has no default members. If you make a Windows NT Server or Windows NT Workstation computer a replication partner, however, the account associated with the replication service on that machine must be inserted into this group.

Server Operators

Server Operators exist only on domain controllers and exist specifically for the purpose of managing servers. Server Operators can do everything an Administrator can do except manage security. The Server Operators group can perform all duties related to the file system, can perform backups and restores, can manage shares, can manage disks, and can shut down the server.


Who are Users? Unlike the Everyone group, the Users group is permitted to use the Log on Locally right on all Windows NT machines except domain controllers. On a Windows NT Workstation, members of the Users group can create and delete local groups, can shut down and lock the local workstation, and can maintain a local profile.


Integrating Workgroups into Domains Back to Top

This section addresses some of the preparatory issues in domain planning. Let's assume you have a hypothetical network that contains 25 Windows NT Workstations and 10 Windows NT Servers configured as member servers. You now want to add another workgroup containing Windows 95 and Windows 98 clients and combine these into a domain. Centralized user management is an issue because of limited administrative resources. How might you go about planning this migration?

Domain models require domain controllers so that users can obtain logon authentication services and can pass domain security checks when requesting access to domain resources. With the limited number of computers described for this environment, a single domain model makes sense.

Based on the roles that the member servers play in their current network, take two of these member servers that match the requirements for a domain controller and move any applications or services to other Windows NT member servers. On one of these servers, reinstall Windows NT Server. This machine will become the domain's PDC. After this machine is installed and up on the network, you can start on the second server.

On the second server, move all applications and services to one of the other member servers and then reinstall Windows NT Server. This machine will become a BDC. In this example, we'll format the drives and start from scratch. The BDC joins the domain during the installation process. This requires an administrative account and a password for the PDC. After the BDC is running, master SAM replication occurs automatically. As soon as all service packs and hotfixes are applied, make an Emergency Repair Disk (ERD) for each domain controller. (The rdisk /s command creates an ERD.) Make one for the PDC as well as the BDC. Keep them handy because you'll be working with them again shortly.

At this point, you are ready to begin creating computer accounts in the domain for the member servers and workstations. You can do this from within Server Manager or separately on each Windows NT computer. From within Server Manager, select the Computer menu and then select the Add to Domain menu item.

After all the Windows NT member servers and workstations are added to the domain, it's time to add the Windows 95 and Windows 98 machines. You must add each of these clients individually. On each machine, choose the Network applet in the Control Panel, double-click Client For Microsoft Networks, select the General Properties page, select the Log On To Windows NT Domain check box, and click OK. Restart the Windows 95 and Windows 98 clients. To enable a user to log into the domain, you must use User Manager for Domains to add a domain user account. The user will be able to log in from any client, assuming no logon restrictions exist.

To move a slightly larger number of clients (say, several hundred) into a domain, this change is better accomplished by remotely manipulating the Registry on each Windows 95 and Windows 98 client. Chapters 8, "Editing the Windows NT Registry," and 9, "Important Registry Keys and Values," discuss just such procedures. Using REGINI or some of the other remote Registry tools, you can perform an upgrade of several thousand clients. Managing domain controllers, however, can be a little more difficult.

Managing domain controllers is not quite a black art, but it does require an understanding of what a PDC can do, how BDCs function in a domain, and how PDCs and BDCs communicate. Other interesting issues crop up as well, as you'll learn in the following sections.

Understanding the Security ID

SIDs are part of Windows NT's security system. A SID is a unique key that identifies objects in a Windows NT domain. Each user, group, and computer has a unique key. A username or computer name can change, and Windows NT needs some a to track what's going on in the system.

Upgrading a Member Server

There is no way to upgrade a member server to a domain controller without reinstalling Windows NT.

Enter the SID. Let's say you have a BDC named Matthew, and for whatever reason, you decide to rebuild Matthew from the ground up. Even if you name the new BDC Matthew, it really isn't Matthew—just as a clone isn't the original but a close copy. Because the system SID changes based on a new installation of Windows NT—even though the machine name is the same and it is built to be identical to the original—Windows NT won't be fooled into letting this machine enter the domain and assume Matthew's responsibilities. If a PDC is damaged, it is imperative not to rebuild Windows NT on that machine. It can cause harmful effects on your domain that will require additional work to repair.

The topics of moving a server and domain controller promotion and demotion are discussed shortly. For now, suffice it to say that individuals are handled nearly the same way as computers so that each user account has a unique SID matched to an account name. If any account, group, or computer is deleted, its SID cannot be reused nor can that account, group, or computer be restored to its original condition. Two instances of an object with the same name will always have different SIDs and, therefore, do not represent the same object!

Moving a Domain Controller to a New Domain

You can relocate a domain controller into a new domain in two ways: create a new domain or rename an existing domain. Each of these methods has the same net effect. BDCs cannot be moved from one domain to another. Windows NT must be re-installed, and these newly minted BDCs must join the new domain.

When you want to create a new domain, it is possible (but not advisable) to change a PDC's domain designation. You can change the domain for the PDC within the Network applet in the Control Panel. This moves all user and group accounts into the new domain; however, all Windows NT member server and workstation accounts must be re-created in that new domain. You must also re-establish trust relationships with the newly named domain. You must modify existing Windows clients (Windows 3.11, Windows 95, or Windows 98) to change their logon domains in Control Panel and then reboot.

Creating a New Domain

When you create a new domain, you can move the PDC alone and change the domain name, but it _usually is simpler to start from scratch.

Promotion and Demotion

BDCs maintain a copy of the PDC's master SAM database to perform user logon authentication. When a user attempts to log on, a broadcast is sent out to contact a BDC. The first BDC to respond—not necessarily the closest—authenticates the user. BDCs are particularly handy when the PDC needs to be taken offline for scheduled maintenance or when the PDC fails. In this scenario, the BDCs continue to authenticate user logon requests. When a PDC fails or is scheduled to be taken down for maintenance, one BDC should be promoted to assume the PDC's responsibilities in the interim.

Promoting a BDC to PDC Status

When you modify a user's account, the change is written to the master SAM on the PDC and then is replicated to the BDCs within the domain. If the PDC is rebooted during the time that password is being changed, the change does not take place. Only a PDC can accept changes to the SAM database. If no PDC is available, changes are not accepted. This is why it's important to promote a BDC to take over for the PDC when the PDC fails or is unavailable; otherwise, the SAM database becomes static and no changes are possible.

Use Server Manager to promote and demote domain controllers. Member servers cannot become domain controllers, just as domain controllers cannot become member servers. To switch from member server to domain controller or vice versa, you must reinstall Windows NT.

You can perform the following steps to promote a BDC to a PDC:

  1. Notify users that the PDC will be shut down.
  2. On the PDC, open the Control Panel and then the Services applet.
  3. Stop the Server service. This prevents new user logons while the change is taking place.
  4. On a domain controller, open Server Manager.
  5. Select Properties from the Users menu and click the Computer button.
  6. Click the Disconnect All button to disconnect all users.
  7. Select the BDC to be promoted.
  8. Select Promote To Primary Domain Controller from the Computer menu.
  9. Restart the Server service on the PDC.

Promoting a BDC

A PDC that is online when a BDC gets promoted will automatically be demoted to a BDC.

Demoting a PDC to BDC Status

If you need to demote a PDC manually and the preceding procedure won't work (possibly due to hardware or Registry-related failure), try the following approach to perform a PDC demotion:

  1. Notify the users that the PDC will be shut down.
  2. On the PDC, open the Control Panel and then the Services applet.
  3. Stop the Server service. This prevents new user logons while the change is underway.
  4. Open Server Manager.
  5. Select Properties from the Users menu and click the Computer button.
  6. Click the Disconnect All button to disconnect all users.
  7. Select the PDC.
  8. Select Demote To Backup Domain Controller from the Computer menu.
  9. Restart the Server service on the former PDC.

Synchronizing Domains

There are times when a user's password gets changed, and it is unable to authenticate against some network resource or application even after several hours. This condition seems to occur when the copy of the SAM on a BDC becomes corrupted or when one BDC's information differs from the another domain controller's SAM, making the two systems out of sync. Here is how to ensure that the PDC's and all BDCs' SAMs stay properly synchronized:

  1. Open Server Manager.
  2. Select the PDC.
  3. Select Synchronize Entire Domain from the Computer menu.


Domain Management Tools Back to Top

The following sections cover some important utilities from the Microsoft Windows NT Server 4.0 Resource Kit CD. These utilities make it easier and more convenient to manage Windows NT domains than ever before.

Domain Monitor

The Domain Monitor utility monitors the status of servers in a specified domain and its secure channel status to the local domain controller and to domain controllers in trusted domains. If any status shows errors, Domain Monitor displays various status icons along with the domain controller name and a list of trusted domains. You can find the cause of errors by checking the error numbers reported in the Windows NT Messages database.

Domain Monitor connects to servers to retrieve status information using the current user's username and password. If the current user account doesn't exist in a domain or in the database of a trusted domain, the status query can fail. Any user who is logged on can query the status information, but only administrators can use the Disconnect button to disconnect and restore connections.


NetWatch enables you to view all connections to a particular machine on the network. This is a useful tool for finding out whether a user is attempting to access information to which he or she shouldn't have access.


QuickSlice enables you to view which process ID is consuming the most CPU utilization including its Process ID, PagedPool and NonPagedPool memory consumption, and its percentage of process CPU utilization statistics.


GroupCopy performs the sometimes cumbersome task of moving a whole group from one domain to another without being forced to re-create it. Using GroupCopy, you can specify the source and target domains and the specified groups to copy. You also can take a global or local group and use it to create a new global or local group in the new domain. GroupCopy is a very handy utility.


Troubleshooting Techniques for Networks Back to Top

There are many ways in which domain controllers can become the focus for networking problems. The symptoms and fixes described in the following sections cover the most common problems and their related workarounds.

BDC Fails to Authenticate a User's Password

If the computer that provides authentication for a logon is a BDC for the domain in which the user account is defined and that BDC fails to authenticate a valid user password, this usually indicates that the password has changed but the BDC is not synchronized with the PDC when the user attempts to log on. When this happens, the BDC should pass that logon request to its PDC.

As a precaution, users who change their passwords should log on to all computers to which they have access within 15 minutes of making the change. This ensures that cached credentials are up-to-date on each machine and that the user can log on using these credentials even if the PDC is unavailable during a later logon.

IP Address Connection Works but Name Resolution Fails

If you encounter a situation in which the IP address connection works but name resolution fails, try the following:

  1. Make sure the appropriate HOSTS file and DNS setup are configured for the computer. First, check the host name resolution configuration using the Network applet in the Control Panel. Then choose the DNS tab in the Microsoft TCP/IP Properties dialog box and make sure the settings are correct.
  2. If you are using a HOSTS file, make sure the name of the remote computer is correct and is capitalized exactly as it appears in Network Neighborhood, in the file and in the application that uses the file.
  3. If you are using DNS, make sure the IP addresses for all DNS servers are correct and are entered in the proper order. Use PING with the remote computer by typing both the host name and its IP address to determine whether the host name is being resolved properly.

TCP/IP Connection to Remote Host Hangs

If a TCP/IP connection to a remote host hangs, you can use the Windows NT NETSTAT command to display protocol statistics and current TCP/IP network connections that can be helpful in diagnosing problems. The NBTSTAT command displays statistics and connections related to NetBIOS connections that run over TCP/IP.

Here is the syntax involved in using the NETSTAT command:

NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval]

The following list details the switches used with NETSTAT:


You can obtain a listing of all NETSTAT commands at any time by typing NETSTAT /? at the command prompt.

Use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer. The state of a good TCP connection usually is established with 0 bytes in the send and receive queues. If data is blocked in either queue or if the state is irregular, it is likely that there is a problem with the connection. If not, you are probably experiencing network or application delay.

Unable to Resolve a NetBIOS Name

NBTSTAT displays protocol statistics and current TCP/IP connections using NetBIOS over TCP, which also is known as NBT. NBTSTAT is one of the primary tools to use whenever you fail to connect to a specific Windows NT Server where TCP/IP is the primary (or only) networking protocol in use. To determine the cause of connection problems, use the nbtstat -n command to determine what name the server registered when it came up on the network. The output of this command lists several names that the computer registers. A name that resembles or matches the computer's name should appear. If not, try one of the other unique names that NBTSTAT displays.

The following is a syntax description for the NBTSTAT command:

NBTSTAT [-a RemoteName] [-A IP address]

[-c] [-n] [-r] [-R] [-s] [-S] [interval] ]

You also can use the NBTSTAT utility to display cached entries for remote computers from either #PRE entries in LMHOSTS or recently resolved names. If the name remote computers use for the server is the same, and other computers are on a remote subnet, make sure they have a name-to-address mapping for that computer in their LMHOSTS files. To troubleshoot a problematic connection or an apparent name-resolution problem, try the following commands:

Host on the Same Network Fails to Resolve

The Address Resolution Protocol (ARP) enables a host to find the MAC address of a destination host on the same physical network when given the destination host's IP address. To make ARP efficient, each computer caches IP-to-MAC address mappings to eliminate repetitive ARP broadcast requests.

The arp command enables a user to view and modify ARP table entries on the local computer. The arp command is useful for viewing the ARP cache and for resolving address-resolution problems. The arp command displays and modifies the IP-to-physical address translation tables used by the built-in TCP/IP ARP.

The following is the syntax for the arp command:

ARP -s inet_addr eth_addr [if_addr]

ARP -d inet_addr [if_addr]

ARP -a [inet_addr] [-N if_addr]

NET Commands

The NET commands comprise a NetBIOS-based set of networking commands that cover the full range of network capabilities on a Microsoft network. Several useful domain-related commands and utilities are covered in the following sections.


Use the NET COMPUTER command to add or remove a computer from a Windows NT domain. The following is the syntax for the NET COMPUTER command:

NET COMPUTER \\computername {/ADD | /DEL}

In the preceding, \\computername is the name of the computer, and /ADD or /DEL specify whether the computer is to be added or deleted from a domain.


Use the NET START command to manage your installed Windows NT services from the command line. The following is the syntax for the NET START command:

NET START ServiceName

The following Windows NT services can be started by NET START:


For More Information Back to Top

To find out more information about domain models and troubleshooting network problems, access one of the following resources:

About The Authors

Stu Sjouwerman has been in computing since 1979. He is executive vice president of Sunbelt Software, Inc., the world's largest distributor of Windows NT system management utilities. Stu is the editor of Sunbelt's Ntools E-News, which goes to over 300,000 NT administrators.

Ed Tittel, an 18-year computer industry veteran, runs LANWrights, Inc., a seven-person research, training, and writing company that specializes in Microsoft and Novell software, and in Web technologies.

Copyright © 1999 by New Riders Publishing, Pearson PTR

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.