Active Directory Computer Accounts

Active Directory requires that computer accounts be created for both Windows 2000 and Windows NT-based operating systems. Similar to NT 4, Windows 9x-based systems do not require this, on account on the fact that these systems do not have a SID. Computer accounts can be created in the built-in Computers container or other containers in advance. If you create the computer account as part of joining a domain, the account will automatically be placed in the Computers container. Of course, it can be moved at any time, according to your management and administration needs.

Active Directory Groups

Group accounts have also changed in Windows 2000. Unlike NT 4 where we only found Global and Local groups, Windows 2000 includes new group types, scopes and abilities. Before we discuss these however, we need to take a look at something referred to as the ‘mode’ of a domain. By default, all domains are created in something called Mixed Mode. In this mode, NT 4 BDCs can still exist, and many of the rules associated with an NT 4 domain still apply. Once all domain controllers have been switched to Windows 2000, the domain can be switched into what is referred to as Native Mode. This is a one-way process. Note that even if you are not upgrading an NT 4 domain, a Windows 2000 domain is still automatically created in Mixed Mode, and the change to Native mode must be made before many of the new feature with respect to users and groups can be used.

Windows 2000 supports two types of groups. The first are very similar to groups in NT 4, and are referred to as Security groups. Quite simply, a security group has a SID, and as such can be part of a Discretionary Access Control List (DACL), the list of users and groups that have permissions to access a resource. The second type of group is called a Distribution group, and exists for the purposes of sending email messages to a group of users. This functionality largely exists for the purpose of Exchange 2000 integration. Distribution groups have no SID, and as such cannot be added to a DACL. You may be asking why it is necessary to make a distinction. The reason relates to what happens when a user logs on – a security token gets created that lists their SID, and the SIDs of the groups they are part of. The larger the number of security groups, the larger the security token for a user, and the longer it will take to log on. Distribution groups provide an easy and less resource-intensive way to be able to integrate messaging technologies with Active Directory.

User Accounts in Active Directory

Every User that needs to log into the domain will require a user account. Note that the account can be created within any container (built-in, or OU that you create), since these are all still technically ‘domain’ accounts. The user will still only need to supply the domain they wish to log into, not the container in which their account actually exists. Unlike NT 4 where the properties relating to a user account were very limited, in Active Directory user account properties are actually quite extensive. Most of these are not configured during the account creation process, but actually afterwards by accessing the properties of an account. Like NT 4, you can change the properties of multiple accounts simulataneously by selecting many accounts and then accessing their properties collectively. The property tabs found on a domain user account differ based on the services installed. For example, if Exchange 2000 is installed, a user’s mail configuration is done from the property sheets. Note that to view some tabs, you must choose Advanced Features from the View menu. The default tabs and their purposes are listed below:

  • General – contains basic information about the user including first name, last name, email address, etc.
  • Address – home address of the user
  • Account – user account details, including logon name, logon hours, account options, and account expiry.
  • Profile – user profile and logon script information, as well as home directory details.
  • Telephones – various phone numbers for the user.
  • Organization – information on title, department, and manager.
  • Environment – Terminal services startup information.
  • Sessions – settings relating to Terminal service sessions, such as idle session disconnect.
  • Remote Control – settings relating to Terminal service remote control options.
  • Terminal Services Profile – information relating to Terminal service profile, home directory, and allowing/disallowing logon to terminal server.
  • Published Certificates – listing of user’s X.509 certificates and purposes.
  • Member Of – listing of groups the user is a member of.
  • Dial-in – Dial-in settings for this user, including items such as callback settings.
  • Object – shows fully qualified name of the user object, when it was created.
  • Security – show access control list associated with this object.

Managing Active Directory Objects

The administration of Active Directory involves the management of domain objects and their associated properties. The objects managed within a domain include user accounts, group accounts, computer accounts, and organizational units primarily. Unlike NT 4 where we used one tool to manage users and groups (User Manager for Domains) and another to manage computer accounts (Server Manager), in a Windows 2000 domain all management of these objects is handled via a tool called Active Directory Users and Computers, an MMC snap-in. Note that this tool can quickly be accessed from the Run command, by running dsa.msc.

When opened, Active Directory Users and Computers will be focused on a particular domain controller. This will be the domain controller to which updates and additions will be written. It can be changed by right-clicking the domain object and choosing to connect to another domain controller instead. This is actually quite useful – because replication between sites can have associated schedules, you might decide to change a user’s properties on their local domain controller instead of another, and thus not have to wait for the changes to replicate. The AD Users and Computers program displays the domain object, and then a series of containers.

First and foremost, the folders that appear beneath the domain object are actually containers. Two types of containers exist – built-in containers, and OUs. A built-in container appears as a plain folder, while an OU looks like a folder with a book icon on it. Note that OUs can have group policies applied to them, while built-in containers cannot. However, both types of container allow you to delegate administrative control. The containers which are created automatically are described below:

  • Built-in: This container houses all built-in user and group accounts created when Active Directory is installed.
  • Computers: This container houses any upgraded computer accounts, or any new accounts added as part of joining a domain from a client system.
  • Domain Controllers: This OU contains all domain controllers for the domain.
  • ForeignSecurityPrincipals: Container for SIDs of user accounts from external trusted domains.
  • Users: This container is where upgraded user accounts are stored. You will also find the domain Administrator and Guest accounts here.

These are not the only built-in containers that exist, however. If you choose Advanced Features from the View menu, you will also find the following containers:

  • LostAndFound: This container houses orphaned objects. For example, imagine if an OU was deleted on one domain controller, and before replication had completed, a user was created in that OU on another domain controller. This user would be placed into the LostAndFound container, since its container object no longer exists.
  • System: This container holds settings relating to domain operational information, including AD-integrated DNS, domain DFS configuration, and so forth.

Within these containers (or the root of the domain) other objects can be created such as users, computers, groups and so forth. Note that there is no requirement to actually create users in the Users container, or computer accounts within the Computers container. You can use these, or create additional OUs according to your organizational needs and place accounts there instead. You can also easily move objects between contains by right-clicking the object and choosing Move. To create a new object within a container, right-click the object and choose New, and then choose the appropriate object type you wish to create.

Windows DNS Servers

The Domain Name System is the Internet-standard name service used by Windows 2000 to help clients resolve host names to IP addresses and find services on the network. Before getting into the details of what is new in Windows 2000 DNS, I think we should first review how DNS itself works.

DNS is a distributed system of name servers. In this system, groups of name servers are responsible for records relating to hosts in domains and or subdomains. These groups are called zones. Zones are authoritative, or responsible for, the records relating to a given domain or group of domains. For example, Microsoft might have a few servers responsible for the domain, and all associated subdomains might be part of the same zone. The DNS servers that carry the host records relating to are said to have authority for that domain. As such, if these servers could not provide an answer for the IP address associated with, it is assumed not to exist.

Name servers hold what are referred to as resource records. A resource record maps a hostname to an IP address, or a particular service to a hostname. For example, a DNS server might contain a host record (called an A record) for a server called server2 that resolves to IP address If a client or another DNS server were to ask for the associated IP address, it would be found and returned. By the same token, a mail server might query DNS looking for the mail server associated with the domain. In this case, it is querying DNS for the mail exchanger record (an MX record), which would provide the fully qualified name of the mail server, which could then be resolved to an IP address and contacted.

Windows DHCP Servers

The Dynamic Host Configuration Protocol is a core networking service offered in Windows 2000 Server used to dynamically allocate IP addresses and associated information to TCP/IP-based clients. Although the function provided by DHCP is similar to what was provided in NT 4, a number of minor changes have taken place that you should be aware of. Again, note that this section is meant as an introduction to DHCP, and is provided as a basis for the Server portion of the exam. A much more detailed explanation of the configuration of DHCP will be covered during the networking services exam portion of the series.

The DHCP Server service is installed automatically by Windows 2000 Server, but is not configured (and may even be disabled) without further input. It can be removed or added if necessary, using the Add/Remove Windows Components option in Add/Remove Programs in Control Panel (it falls under Networking Services). Once installed, the DHCP server is configured using the DHCP MMC snap-in, which can be found under Administrative Tools. If the server running Windows 2000 is part of a workgroup or non-Windows 2000 domain, the DHCP service will be started, but you will need to manually configure scopes of addresses for the DHCP service to hand out (more on this in a bit). If DHCP is installed on a system that is part of a Windows 2000 domain, the DHCP service cannot be started until the DHCP server is authorized in Active Directory.

The authorization of a DHCP server in Active Directory can only be done by a member of the Enterprise Admins group. This is meant to be used as a control mechanism in order to alleviate the problems caused by people (such as other administrators) installing ‘rogue’ DHCP servers which end up having an impact on the configuration of a TCP/IP-based network (since a client receives an IP address from the first server that responds to its request). In a Windows 2000 Active Directory domain, only authorized Windows 2000 DHCP servers can hand out IP addresses. Note that this only works in conjunction with Windows 2000. A Windows NT 4 DHCP server can (and will) still hand out addresses, and will not be impacted by authorization. However, if another administrator tried to install a Windows 2000 DHCP server and start the service without it being authorized, the server would query AD, and then not start the service since it would find it is not authorized on the network. Note that an unauthorized DHCP server appears in the DHCP tool with a downwards-pointing red arrow (which can also mean that the service is not started, or a scope is not configured).
In order to authorize a DHCP server, right-click on the server and choose Authorize. To manage authorized DHCP servers (including adding or removing authorized servers), right click the DHCP icon, and choose Manage Authorized Servers.

Gateway Services for NetWare and Client Services for NetWare

Often referred to by its acronym CSNW, Client Services for NetWare is a client redirector, which allows a Windows 2000-based system to connect and authenticate to a NetWare-based server and access the file system. CSNW should be installed when clients need to regularly access NetWare file or print servers. Often, CSNW is not installed in favor of the native Novell client for NetWare, which ships with the Netware product. Installing CSNW is accomplished by choosing to install a Client in the properties of a connection object.

It is worth noting that the installation of CSNW on a Windows 2000 Server is actually done as part of the installation of Gateway Services for NetWare, or GSNW. GSNW will also automatically install NWLink if it hasn’t already been installed on the system. On a Windows 2000 Professional system, an option exists for installing CSNW alone.

Once installed, configuration of the client and gateway elements is actually handled via the GSNW applet in Control Panel. The configuration includes the selection of either a preferred server (in a bindery-based NetWare environment) or of a default tree and context (in an NDS-based environment).

Gateway Services for NetWare is meant to be used in environments in which clients require less frequent access to NetWare-based servers. GSNW makes a Windows 2000 Server act as a gateway (or access point) to resources located on a NetWare server. Using GSNW allows you to eliminate the need for each client system to have CSNW or NWLink installed. Instead, clients access a shared folder on the Windows 2000 system running GSNW, which in turn allows them access to files and folders on the associated NetWare server. In order to configure Windows 2000 as a gateway, a gateway account must be configured using GSNW in Control Panel.

The account used must exist on the NetWare server, and must be a member of a group created on the NetWare server called NTGATEWAY. You must also ensure that the NTGATEWAY group has appropriate trustee rights to access resources on the NetWare server. Once the account has been set up, one or more shares must be created that access the netware server.

In this example, when users access the share called ‘netware’ on the Windows 2000 server, they will actually be accessing the folder ‘resources’ on NetWare server NW1.

NetWare Connectivity in Windows

Windows 2000 still supports some of the NetWare connectivity elements that you may be familiar with from Windows NT 4. The three main elements that you’ll need to be aware of are the configuration of NWLink, Client Services for NetWare (CSNW), and finally Gateway Services for NetWare (GSNW).


NWLink is Microsoft’s version of Novell’s IPX/SPX transport protocol, the native transport protocol in releases of NetWare prior to version 5. Since IPX/SPX is still run in many enterprise networks, it is important to know how Windows 2000 communicates with systems running the IPX/SPX protocol. NWLink is configured in Windows 2000 by choosing to install the protocol in the properties of a connection object, such as a Local Area Connection.

Once the protocol is added, it can be configured by accessing its properties. Note that adding NWLink to a system only makes that computer capable of communicating with another IPX/SPX or NWLink-based system. It does not mean that this computer can access the file system of another IPX based system. That level of access requires that an appropriate client redirector be installed, which will be discussed in a moment.

Once NWLink has been installed, it might be appropriate to check your network binding order, in order to ensure that it is optimized correctly for your network. For example, if TCP/IP is listed first in your binding order and NWLink second, a client will always try to communicate using TCP/IP first, followed by NWLink. If IPX/SPX is the primary protocol used on your network, this may not be appropriate, and may cause unnecessary network traffic. The binding order for a connection is set via the Advanced Settings option under the Advanced menu item in Network and Dial-up Connections. The binding order is controlled according to the adapter and then the client or service, and can be changed via the up or down arrows to the right.

Upgrading to Windows 2000

You should be familiar with the process of upgrading a domain from Windows NT 4 to Windows 2000 for the Server portion of exam. Creating your new Active Directory domain involves upgrading your existing domain controllers to Windows 2000. Note that member servers and workstations can be upgrading at any time, whether before or after the domain upgrade takes place.

When upgrading a domain, the first machine to be upgraded should be the current PDC. Upgrading the domain will allow all user, group, and computer information that currently exists to be migrated to Active Directory. Before you upgrade the PDC however, Microsoft recommends that you do a full domain synchronization, and then take one BDC offline. If the upgrade were to fail, you could then place the BDC back on the network, promote it to the PDC, and be back to where you originally started.

After you upgrade the PDC and get Windows 2000 installed, dcpromo will run automatically to turn the system into a domain controller. Your domain will now be in something referred to as Mixed mode, or a state where NT 4 BDCs can continue to exist, using the upgraded PDC (who is now the PDC emulator) as their domain synchronization source. Once all domain controllers have been upgraded to Windows 2000, you can switch the domain to Native mode. The differences between Mixed and Native mode are discussed below:

Mixed Mode: A mode that allows for NT BDC to continue to exists, and allows you to revert to an NT 4 domain if necessary. Even in a non-upgrade scenario, Windows 2000 automatically creates new domains in Mixed mode, requiring you to explicitly switch the domain to Native mode.

Native Mode: In Native mode, all domain controllers run Windows 2000. The switch to native mode provides the ability to create Universal groups, nest groups, and control remote access via RAS policy amongst other things.

Note that changing from Mixed mode to Native mode is a one-way process and cannot be reversed. Some possible problems / issues with respect to upgrading domains that you should be aware of:

  • All domain controllers running Windows 2000 require at least one NTFS partition to house the SYSVOL folder. This is the folder structure that needs to be replicated amongst domain controllers.
  • A system being upgraded must be configured to use a DNS server that supports SRV (service) records.
  • If no DNS server is available, Windows 2000 will create one for you, making the system an Active Directory Integrated DNS server (more on this later in the series).
  • If the dcpromo process fails or returns an error, ensure that domain names provided are entered correctly, that proper network connectivity exists, and that there is enough disk space (dcpromo requires approximately 250 MB of space total).

Active Directory Physical Structure

The physical structure of Active Directory relates to two main types of objects – sites and domain controllers.


Unlike NT 4, Windows 2000 Active Directory provides for the concept of physical locations within its design. In Active Directory, a site is a collection of TCP/IP subnets connected at high speed. Though ‘high-speed’ is relative, usually it refers to a collection of subnets connected at LAN-type speeds. You define sites in Active Directory to control replication, authentication, and the location of services. Once sites have been defined, a client computer will attempt to authenticate to a domain controller that is part of the same site, instead of sending the request over the WAN.

Sites also allow you to control when replication can occur between domain controllers. For example, in NT 4, all BDCs replicated with their PDC using a 5-minute interval change notification process. Since there wasn’t any easy way to control replication between physical locations (it was possible by batch scripting to the registry), replication traffic often saturated links and degraded performance. Once you have defined sites in Active Directory, you can also specify the times and days at which replication between sites can occur, how often during these times, and the preferred path that replication should follow. You should note, however, that only one site exists by default, and until you define more sites, replication will continue to occur on the same old 5-minute change notification interval. It is also important to note that sites are another element that allow large companies to have only a single domain – since there is no correlation between the logical and physical structures of Active Directory, you could have one domain and hundred of sites. The ability to control replication traffic is a big part of what makes this more manageable than in the past.