In this second phase of your Active Directory testing, it’s time to try out the utilities included in Windows 2000 to simplify your networking duties.

AD Administrator’s Toolbelt

In this second phase of your Active Directory testing, it’s time to try out the utilities included in Windows 2000 to simplify your networking duties.

• By Michael Chacon
• 08/01/2000

Last month we left the newly installed Active Directory Domain Controller in pristine condition. With the installation of AD complete, the next step is to verify that it’s properly working on your test machines. You don’t want to discover problems after the users have been added or it’s in production. As with any Windows 2000 or Windows NT service the first place to look for useful information in terms of functionality is through the Event Viewer.

The Event Viewer, found under the Administrators menu, has been expanded beyond the original three System, Application, and Security logs to include service-specific logs for ease of organization. These include Directory and DNS, with other services added to the viewer as they’re installed on the machine as shown in Figure 1.

Figure 1. The Event Viewer shows you what services have been installed on your server.

The first place to look is under the Directory Service log. The obvious things to look for are the red stop signs that are evidence of a problem with Active Directory or a supporting service. As with the previous Event Viewer you can open up each of these entries to display more detailed information, such as a description of the service ("Microsoft Directory startup complete, version 5.00.2160.1"), the type ("Information"), who’s listed as the user ("Everyone"), and which computer it’s installed on ("LUKE").

You also should look in the DNS logs to make sure that this critical service is functioning properly. Remember, if you don’t have a DNS server, your clients won’t be able to locate the AD domain controllers. If you’re not using the Microsoft DNS, then you can use Nslookup instead of the Event Viewer to see if the DNS server you’re relying on is functioning properly. Nslookup emulates the resolver, the client part of DNS name resolution, and is a commonly used command-line tool for troubleshooting DNS problems. While PING is useful for verifying that the server running the DNS is up and available, it doesn’t give you enough information to verify that the actual DNS service is functioning.

To verify communication with a DNS service, just run Nslookup at the command prompt without a server name so you’ll be in interactive mode. At the > prompt type:

SET DEBUG

You’ll get a verbose response to any query. Once the > prompt returns, reflecting that debug was successfully turned on, type in the command SERVER followed by the name of the server that you want to query. Your response will look something like Figure 2.

Figure 2. NSLOOKUP can help you troubleshoot DNS problems for a given server.

The complete details of this response are beyond the scope of this article, but the return of the information above shows that this DNS server was successfully queried and that its response was authoritative. An authoritative response means the information was returned from the actual resource records, not the cache. Under the Questions: section you can see that the resource record for luke.newman.org was returned. From this basic response we can verify that this DNS is functioning properly.

If a DNS problem exists, you’ll probably receive a message like Figure 3.

Figure 3. What a malfunctioning DNS server responds to Nslookup.

Since you’ll eventually be translating your practice sessions to an AD production environment, be forearmed: This type of query should also be a part of your regular monitoring duties. DNS problems are now AD problems.

Another test is the obvious one: Does it work from the client as intended? If AD is properly configured, test workstations and member servers should be able to join a domain and query the database for resources. Since our DNS is verified to be functioning properly, we should be able to join the NEWMAN domain. This is similar to the NT process with a few minor differences, mainly that you must go to a different location to find the place to make the appropriate change. First, right-click on My Network Places and select properties. This brings up the window in Figure 4.

Then select Advanced | Network Identification. This brings up the screen in Figure 5, which looks similar to the old screen for Network Identification.

Figure 4. Once AD is configured, workstations and member servers should be able to join a domain and query AD for resources. This starts through My Network Places...

Figure 5. ...and lands in Network Identification, where you’ll start a wizard to handle the process for joining a domain.

When you click on the Network ID button here, it starts a wizard that takes you through the process of joining a domain. After you complete the wizard and have joined a domain, you can also further test the AD installation by using the directory to locate a resource.

For example, if you click on the Start button and select the Search option, you can look for files, folders, printers, people, and other network objects. Figure 6 shows an example of a search through the directory for a printer. When the Directory is available, you can see the contents of the directory and choose a starting location for the search. Getting this far is a good indication that the directory is available and functioning properly.

Figure 6. After you’ve joined a domain as a user, you can search for resources worldwide as easily as those available locally.

Rearranging the Services

Once you’ve verified that the AD installation is functioning properly and that it can be located through the DNS, it’s time to explore the various interfaces you’ll use to manage the directory. Let’s look at some of the new tools that have been added to the Administrative Tools menu.

Since you’ve probably got a strong Windows NT 4.x background, you’ll no doubt be pleased that you get to relearn all of the places you need to go when you want the right tool. Your garage has been rearranged for you. Here are a few tools worth tracking down:

Active Directory Users and Computers
You’ll probably spend most of your on-going time within this tool. ADUC is used to perform fundamental tasks such as creating, modifying, moving, and deleting user and computer accounts, organizing them with organizational units (OUs). Essentially, this is where you add objects to the directory. Once the objects are created, their properties are accessible from this tool and it allows you to publish network resources such as shared folders and printers.

Active Directory Domains and Trusts
This presents a graphical view of the trusts created as you add domains to the directory tree as shown in Figure 7.

Figure 7. The AD Domains and Trusts window gives a graphical view of trusts as you add domains to the directory tree.

By selecting a domain and right-clicking you can bring up the Properties page (Figure 8) where you can verify and manage the trust relationships.

Figure 8. Looking underneath each domain you’ll find the means to manage the trust relationships.

The General tab is where you change the Domain mode from mixed mode, which supports NT domains, over to native mode—Win2K-only support. This is an important decision: You can’t reverse it, except through reinstallation (sort of like converting a file system to NTFS). The Trusts tab displays the various trusts in relation to this particular domain.

Active Directory Sites and Services
Sites are collections of well-connected subnets, which are characterized as connected to each other at LAN speeds. This tool allows you to manage the connections between each site and the replication process that uses these connections. The AD Sites and Services manager displays a graphical representation of the site relationships as shown in Figure 9.

Figure 9. The AD Sites and Services manager lets you manage the connections between sites and the replication process across sites.

In addition to the site replication control some of the other things that are managed here are licensing, the replication protocol to be used, and delegation of administrative control over the various sites.

Computer Management
Another tool installed on the domain controller, which will probably have more use than all the others, is the Computer Management interface shown in Figure 10.

Figure 10. The Computer Management interface uses MMC to collect in one place all of the miscellaneous tools that don’t fit elsewhere but that will be essential to your day-to-day management of the directory.

This treasure trove of utilities is essential for the day-to-day management of services that support the directory—and all of the other services as well. The tools of Computer Management brings almost all of the disparate utilities available in NT under one roof through the Microsoft Management Console.

This brief overview of the tools used in Active Directory management just touches the edges of what you need to know, but it’s a solid starting point to embark from. If there’s any advice I’d offer you at this point in your Win2K efforts, it’s this: You don’t need to rush this product to production. Spend time with the tools you’ll be using to manage the directory and supporting services. Once the directory is installed, create some temporary accounts and an organization to get a feel for the tools and the relationships between the services and objects that make up the directory. While many of the objects can be torn down or rearranged fairly easily, there are many that can’t be changed once they’ve been created—and you don’t want to affect the work of users who rely upon the system down the road when you determine that perhaps a different approach would be more effective or scale better. When you’re in the early stages of using Win2K, don’t build something you can’t tear down; with the passing of time, new and clearer ideas will move to the forefront.