Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Heidi Moeller: Hello, and welcome to the Microsoft Support WebCasts. We would like to thank all of you for joining us. Our topic will be "Domain Controller Promotion: The Process and How to Troubleshoot It," and our presenters will be Edward Gomes and Mike Resnick.

I'm Heidi Moeller and I'll be your host for today's session. We'll start this session with Ed and Mike's presentation and follow that up with a question-and-answer period when the presentation is finished. Today's presentation should take about 40 minutes.

I'd now like to take just a brief moment to introduce Ed and Mike. Ed works with the Windows^® 2000 Directory Services team. Prior to working at Microsoft, he was with one of Microsoft's partner companies, supporting the Windows NT^® 4.0 IP/RAS team and the Domains team.

Mike is a Support Professional who has served in several roles at Microsoft, including Duty Manager, Lead, and Mentor. He has been part of the Microsoft Windows NT Domain team and is currently focused on the Windows 2000 Directory Services team for Microsoft Platform Support.

Thank you so much for joining us today, both of you. Let's get started.

Mike Resnick: Thank you very much, Heidi. Today Ed and I will be presenting planning and troubleshooting DC promotion. On the first slide, we'll see the planning and troubleshooting the Dcpromo overview.

What we're going to cover in today's presentation is what is the Dcpromo process? Also, we'll cover planning the Active Directory™ implementation, as well as installing the Active Directory, verifying the Active Directory, and installing a replica domain controller. Ed will present the tools that we'll need to help troubleshoot the problems that we run into with the promotion process.

On the next slide (slide 3), we'll see our vocabulary words. The first one is the Dcpromo. Dcpromo is the executable that installs the Active Directory and converts a member server or a Windows NT 4.0 PDC or BDC to the Windows 2000 Domain Controller.

The Ntds.dit is the Active Directory database, which is located by default at the %SystemRoot% in the NTDS directory. However, you can change the location of the database on install, and you can move the database, using Ntdsutil, which Ed will mention later.

SYSVOL is a share created during the Dcpromo process; it is a tree of folders, containing files that need to be available and synchronized between domain controllers in a domain or forest. It includes the SYSVOL share, the NETLOGON share, Windows^® 95, Windows^® 98, or Windows NT forest system policies, Windows 2000 Group Policy settings, and user logon and logoff scripts.

If you want some more information, the Microsoft Windows 2000 Server Resource Kit, in the Microsoft Windows 2000 Server Distributed Systems Guide, Chapter 18, pages 1060 and 1061, provides a little more detail on that.

Domain Naming System: the name resolution advertising mechanism for Windows 2000, and the Internet in general, is very simple to configure in Windows 2000, but it is probably the most common problem that we'll face. And we'll go over that in detail a little later in the presentation.

Flexible Single Master Operation, there are five of these roles. Since Windows 2000 has a multimaster update on every domain controller, it has a writable copy of the database. We ask these five special role holders to limit conflicts and data from replication.

For example, there's the Schema Master, which is only at the forest level. And it's the only domain controller that can perform write operations on the schema database.

The Domain Naming Master is another flexible single master operations role, and the domain controller is responsible for adding a new domain to the forest and removing existing domains from the forest. It is also a per-forest owner.

The Relative Identifier Master, or RID Master: every domain controller can create several hundred objects in the database. However, after a pool of SIDs is empty, a domain controller has to contact the RID Master for security identifier numbers. This is on a per-domain basis, so there can be several of these within your forest.

The Primary Domain Controller Emulator is primarily for compatibility with Windows 2000, Windows NT 3.51, and Windows NT 4.0-based computers. It provides processing for password changes for both users and computers, replication updates to backup domain controllers, and running domain master browser. And this is also on a per-domain basis.

And last, the Infrastructure Master. It handles the movement and renaming of objects in the database and keeps an eye on the distinguished names of other objects that might exist in other domains. It checks for object modification and maintains an integrity list of these objects. This is also on a domain basis.

Global Catalogs — the Global Catalog contains a partial replica of every direct partition in the forest, as well as a full replica of its own domain directory partition, schema, and configuration partitions.

NetBIOS — we thought we got rid of it earlier, but it's still around for your down-level clients. It's the flat namespace for down-level computers. For this WebCast, we'll say NetBIOS is the Windows NT 4.0 domain name or computer names.

Primary domain controller — this is a computer in Windows NT 3.51 or 4.0 that has the writable copy of the same database.

Domain controller — this is a series of peers in Windows 2000. And the Windows 2000 domain controllers all have a writable copy of the database.

Organizational Unit — this is a logic container, in which user groups, computers, and other organizational units are placed in the Active Directory.

Let's go into the next slide (slide 4), which is "What is Dcpromo?" Dcpromo is simply an executable that transitions a Windows 2000 member server or standalone server to an Active Directory domain controller. You can find the file located in %SystemRoot% and \System32. So you'll find it in \WinNT directory \System32, or whatever the %SystemRoot% is.

What it does is it migrates accounts, as an upgrade from a Windows NT 4.0 registry-based database to a Jet database. It creates system vol shares and formats a drive designated by the administrator.

The NETLOGON and system shares are created, SYSVOL shares are created, and the directory tree and the host policies and logon scripts are created. On servers updated from Windows NT 4.0, files in the original NETLOGON share, the \Repl\Export\Scripts directory, are moved to the NETLOGON share in the SYSVOL share tree.

The FRS staging area is also created and the Windows 2000 group policies are also applied. We also do some time synchronization and make some changes in some services.

Go to "Planning Active Directory" (slide 5); this WebCast can't really cover all the possible options that we have in planning your Active Directory. I highly recommend, if you're planning an Active Directory, to read Chapter 9 of the Microsoft Windows 2000 Server Distributed Systems Guide in the resource kit. You can locate it at http://www.microsoft.com/technet/win2000/dguide/chapt-9.asp/.

Here are a few things to consider when you're planning your implementation of Active Directory. First of all, whether you're a small company or a big company, you should spend some time planning your Active Directory implementation.

I'm going to give you a brief overview of things you should think about with your deployment plan, but this is not intended to be an all-inclusive list. This is just a simple cheat sheet version of the planning guide that's Chapter 9. I'd recommend that you read that resource. In this WebCast, we've reduced a 1,100 page book into a 40-minute presentation. So please bear with us.

Deployment planning basics: I'd recommend first that you determine your goals and objectives. What are your goals with your implementation of Windows 2000, and what are your objectives? Second, determine what design and deployment features you want. What feature set do you want to implement, now or later? What training needs do you have, for both your IT department, your users, and also your Help Desk? Third, pilot Windows 2000, if possible. That way you can make sure that there's no lost productivity, and that you understand the potential problems that you may run into. Fourth, do a production rollout. This is where some people will do a phased rollout.

Here are some basic considerations that you should look at. The IP infrastructure for your subnets, how is it laid out? Do you want to upgrade from an Windows NT 4.0-based or third-party OS, or do you want to start with a fresh install and migrate your users, using third-party utilities, or utilities from Microsoft?

What is the current implementation of your network OS and its structure? Do you want to change what you're migrating? For example, if you have a single domain, a single master domain, a multi-master domain, or a full trust domain, how are you going to implement each one of those domains? And where in a domain tree or domain forest do you want to put these?

DNS structure considerations. Is your ISP hosting your external name presence in DNS, or do you want to host your external name presence? What I mean by external name presence is "yourcompany.microsoft.com." For example, in Windows 2000 (we'll get into this little later), you can use corp.company.com and separate your Internet name presence there.

Will users be using the Internet? Are DNS and external name presence even a consideration for your domain?

Additionally, consider your domain structure. DNS is tied to the domain structure in Windows 2000. You can have a very complex domain structure with multiple child domains, as well as multiple trees and multiple forests. Or you can have a very simple namespace with a very top-level, flat domain, where there's one domain in the forest.

There are options with those domains: a flat model with one domain in the forest, one domain tree with multiple children, one forest with several trees, or several autonomous forests.

If you do two forests, they cannot be merged in a simple one-step process, nor can you move a domain between two forests as a one-step operation. It's important: make your decisions now, and you will avoid some time-consuming restructuring later on.

One recommendation Microsoft has in this area is that planning by a geographical basis may be easier than via the name of the department, division, or company name.

Domain controller placement considerations: which sites need a domain controller and which sites do not? Is there a site with a child domain or a forest? What are my replication names?

Another consideration is delegation model. Who has rights to do what tasks and at what level? Do you want it at the OU level, the forest level, or domain level? Do want to decentralize or centralize management of your domains, your OUs, and your users and computers?

Windows 2000 is very flexible in management. However, the more complexity you have, the more time consuming the management may become. But also, you can off-load tasks on the other OUs and domains to other users. You can decide what your OU structure is and where to place the OUs efficiently.

Also consider your operation master placement. A major consideration is the Infrastructure Master. It should not be a Global Catalog server, unless there's only one DC, because the infrastructure master runs on a Global Catalog server, and it will never update anything, because it does not contain any reference objects that it does not already hold. That is because the Global Catalog server holds a partial replica of every object in the forest.

The other consideration in Operation Master placement is the FSMO roles. The Domain Master should be a Global Catalog holder, because the domain master creates an object representing a domain, and it must make sure that no other object has the same name.

Now on our next slide (slide 6), you'll see planning the DNS structure. I would recommend article Q254680. It's on DNS namespace planning. Also I highly recommend Q237675. These article numbers will be at the end of our presentation, so don't worry about it at this point.

The second article (Q237675) is "Setting Up the Domain Name System for Active Directory." I highly recommend using that article. You are concerned with two parts of DNS configuration: at the client level, making sure that your client points to the correct DNS server, and not your ISPs, and pointing to itself on the original DC. You can set up forwarders to point to your ISP if there's an external name presence.

Some basic requirements for DNS: it must support server location resource records, so you can use a third-party DNS server. However, it needs to be able to accept dynamic registration and also server location records.

Microsoft DNS support in Windows 2000 meets these requirements. Additional features are that it is AD integrated. So Active Directory integration is a major advantage, because you don't have to worry about setting up replication with other DNS servers through your DNS if you use Active Directory integration.

Another added feature is Secure Dynamic Updates. This allows an administrator to precisely control which computers can update which names, and prevent unauthorized computers from obtaining existing names from DNS.

Delegation to DNS for your subdomains and Internet domains is a consideration. One recommendation is short names for your DNS. In other words, if you get multiple domains and trees, it's not a bad idea to have short names for ease of use.

I would also recommend that you review your names carefully, because your name might be okay in this country, but internationally we've found that some names are not appropriate.

Removing the DNS suffix: before you Dcpromo or install Windows 2000, I recommend removing the DNS suffix in your Windows NT 4.0-based PDC or backup domain controllers, and reboot them before doing the actual upgrade process. If you don't, you might end up with a mismatched DNS name for the computer machine name versus your domain name. In other words, instead of corporation.com, you might have your old suffix: corporation.com/the old suffix.com.

Use the international standards, or RFC 1123. Don't put any underscore characters in your names. This is a great point, where you can change the name of the server if needed, and also make some adjustments in your IP infrastructure when you're going over to Windows 2000.

Windows 2000 Microsoft DNS server does support underscore characters; however, they are not accepted on the Internet. So if you have some underscore characters, you can keep them. However, if you plan to have that computer on the Internet, it won't be a valid name on the Internet.

One recommendation is using the Internet naming standard that you've already registered on the Internet. For example, "yourcorporation.microsoft.com." However, like I said before, you can add "corp" or "northamerica.com" as well.

We're trying to leave the flat namespace of NetBIOS behind. And the Active Directory structure and DNS structure are highly linked. So consider your NetBIOS name and your DNS host name. It is okay for those two names to match.

On our next slide (slide 7), one thing I would highly recommend is backup, backup, and backup. A lot of customer's plans don't take into account problems they may run into, like hardware incompatibilities and software incompatibilities. I would highly recommend that you have a backup and disaster plan in place and ready, so you can avoid some potential problems.

I also recommend taking a backup domain controller offline and creating a test environment. Test your applications. Test your design and see if it does what you want. See if it meets those planning goals that we originally talked about in the first portion of the WebCast.

Here are a couple of things that you can use to help avoid potential problems that are common issues. Make sure that the Everyone group on the domain controller policy has access. Allow Access This Computer From Network rights to the Everyone group.

File permissions — make sure the system and admin have full control on the file permissions on the partitions. And also make sure the Everyone group has at least Read permissions.

During the upgrade, if you're upgrading Windows NT 4.0, make sure there's at least one other BDC. Also, do not change your environment to native mode until everything is working perfectly.

I would highly recommend the Help files; Microsoft has spent many hours of effort on the Help files in Windows 2000. A long time ago, if you told somebody to look in the Help files, it was almost an insult. We engineers regularly look at the Help files to resolve issues. I would recommend Start, Help, Checklists, and look at the AD section on installing a domain controller for a checklist of things to look for before you do an upgrade to Windows 2000 Active Domain Controller.

In addition to that, I highly recommend, under the DNS service, looking at all checklists and also best practices on both the Active Directory and the DNS service, in the Help files. These are very helpful. And, in addition to that, they're just very strong Help files. They have some great Best Practices sections in there.

Another issue is having third-party LDAP servers using port 389. That's another consideration to think of when you have problems installing a replica DC and accessing your own DC: double-check to make sure that port 389 is available.

"Installing Active Directory" is our next slide (slide 8). When you're running Dcpromo, I would highly recommend you look at Q238369. It's "Promoting and Demoting Domain Controller to Member Server in Windows 2000." That is also at the end of the presentation.

Make sure that when you're promoting, you're pointing to the right DNS server. Also, when it's the first domain controller, choose to be the first DC in the forest. If it's not, there are several other options that are available.

Also, consider your SYSVOL shares. You'll be prompted when you're installing Windows 2000 for the DNS name and NetBIOS name when you're the first domain controller in the forest. This is where your implementation planning becomes useful. This is where you'll put that plan into effect, by entering the option for the DNS name of the fully qualified domain — your domain name.

Another prompt that you'll get after the DNS prompt are the locations of the database, the log files, and the System volume. The system volume requires NTFS version 5. I highly recommend that the log files and database, for security reasons, also be on an NTFS partition. However, they can be run on a FAT partition.

For optimization and DC performance, I'd also recommend selecting separate physical hard drives for the Ntds.dit file and the log files. And that's for system performance.

Another option that you'll run across in the Dcpromo process is a pre-Windows 2000 security group. This option is to minimize permissions to accommodate pre-Windows 2000 applications that will require permissions that are less restricted than those granted by Windows 2000 domain controllers.

The pre-Windows 2000 compatible permission options provide the permissions that those applications require for anonymous read access to particular User and Group object attributes. This adds the Everyone group to the pre-Windows 2000 compatible access group.

If you have a Windows NT 4.0-based remote access server, I would make sure that you check that pre-Windows 2000 compatibility. With Microsoft SQL Server™, running on Windows NT 3.51 or 4.0, as well as applications that are running on Windows 2000 that are located in a Windows NT 3.51 or 4.0 domain, then what will happen, after you complete that section, is the AD automatically configures the sites, based on your subnets and your locator service. Then go in, and at the last prompt, click OK. You'll get a prompt with all the options that you choose. Here's your last chance to double-check, before installation, to make sure that everything is absolutely accurate.

Check to make sure that there are no typos and no misspellings on your domain name. Make sure that all the options that you chose are correct. The Active Directory will also immediately start checking available disk space. We require that there's 200 MB of disk space for the Active Directory, as well as 50 MB for the transaction logs. These are bare minimum requirements for the Active Directory installation. After you choose OK, we start the configuration of the directory services.

During this process, we start changing registry values. We start installing perfmon counters and apply for a X509 DC certificate for the first certificate authority. We start the Kerberos authentication services, and we also set an LSA policy for the domain controller when the computer is restarted. Upgrades for PDCs — there's a little more involved in that process.

We also start adding shortcuts, and we start the creation of the directory partitions. We start creating. There are three partitions: the schema, the configuration, and the domain partitions will be created. The initial DC is created for the forest. All subsequent DCs are to get these directories through replication — not the Dcpromo process, but afterward.

So, we start setting services to go to automatic. The RPC Locator Service, the NETLOGON Service, the KDC, the Intersite Messaging Service, the Distributed Link Tracking Service, and the Windows Time Service are all set to automatic. We start synching the domain in terms of time.

We set security on files and directory objects, as well as set registry keys and file system objects from child objects. The group policy is propagated from only the first domain controller in a domain to additional domain controllers.

The SAM database is removed from within the PDC. On all upgrades from Windows NT 4.0, the PDC process migrates the accounts, deletes the SAM database, and replaces it with a small, very modified form for authentication when the computer is in a Directory Service Restore Mode.

We set the computer's fully qualified domain name to match the domain. Page 136 in the Microsoft Windows 2000 Server Distributed Systems Guide explains some of the other changes.

Create a Computer account on the Domain Controllers container. In addition, we add the domain controllers to the Global group in the Users container.

Cross-reference objects that are also in the Configuration container are added. Then we start creating the System Volume folder, which contains, as I said before in the description, the SYSVOL share, the NETLOGON share, the file system junctions, the user logon scripts, and Group Policy objects. And File Replication Service creates the staging area.

If DNS is not already installed, it installs it. If it can't find it on the network, it will prompt you and will configure it automatically. On reboot, we start the replication process, in which we'll make sure that the SYSVOL share, the NETLOGONs are populated, and also the group objects for the domain in the staging area start taking a place.

Which leads us to our next slide (slide 9), "Verifying Active Directory." After an install, you'll start a reboot process. Make sure that the SYSVOL and all of the other folders inside the SYSVOL that I just mentioned, in the staging areas, are created. There's an article, Q257338, "Troubleshooting Missing SYSVOL and NETLOGON shares." This is a great troubleshooting article on how to resolve any issues that you may have during the Dcpromo process.

Now, we're in product support, and I'm making it sound pretty rough, but this is a fairly easy process, and a lot of people have great success with installation. I only see the ugly stories, so if I make it sound like a horror show, don't take me too seriously on that.

Make sure that the proper folders are shared out, the SYSVOL and the NETLOGON. Check the event logs and see if there are any errors reported. Also, I'd recommend, in the troubleshooting process, to check that the DNS records are registered by the Windows 2000 domain controllers in DNS. That's one great troubleshooting step. That's article Q178169.

Ed will continue now with the next part. He'll cover installing replica domain controllers on the next slide (slide 10).

Ed Gomes: Thanks for being with us today. I will be continuing with "Installing Replica Domain Controllers" and all the troubleshooting tools that we use on a daily basis.

Installing replica domain controllers is a very important process. And to do that, we have to make sure that the first DC that we install is functioning properly, that all the required folders and everything is there, and that the machine is functioning properly. Because whenever you install the replica DCs, it is based off of that first DC. So that's why it is very, very important.

The problems that we usually see are a lot of times, if it's an upgrade from Windows NT 4.0, people will not have the Everyone group in the Access This Computer From Network right. You need to have at least the Enterprise Domain Controller's group (which is a new group in Windows 2000) at least in that Access This Computer From Network right, if not Everyone. But we recommend having both in there.

The replica DC will definitely need to point to the DNS server that's hosting the zone for your Active Directory. Make sure that if your first DC is the DNS server, that you can point your second machine, which is going to be the replica DC, to that same DNS server. If you have a Windows 2000 member server hosting the DNS, then make sure that all the DCs are pointing to that. And it has to be dynamically updating the zone.

And then the third thing is to make sure that the replica DC has access to that the FSMO role and the Global Catalog server.

Now additional steps that occur during the joining process are it creates a Connection object with the domain controller that was used as a source for the installation. During Dcpromo, the server being promoted replicates existing data in the Active Directory from an existing domain controller, unless this is the first DC of the forest. During this process, a connection object is created to establish a replication connection between two machines, so that changes can be replicated, after the promotion.

The computer account is moved to the domain controller's OU; the domain controller's security policy is applied, locate DC in the same site. When Dcpromo is used to promote a server as a replica in an existing domain, Dcpromo will find and record in the Dcpromoul.log file, in the domain controller, that it has established a connection with that used as a source. We will talk about the different logs in a minute.

The troubleshooting tools are on the next slide (slide 11). In today's WebCast, our goal is to introduce you to these troubleshooting tools. We are not by any means going to go into detail on any of these troubleshooting tools, because each of these troubleshooting tools could be a WebCast by itself.

What I recommend doing, if you have more questions, or if you want to know more in detail, is to read some documentation on the Web, especially the Microsoft Windows 2000 Server Distributed Systems Guide of the resource kit, which has more options and explanations on how to use these tools.

These are the troubleshooting tools that we use often for troubleshooting the AD: Adsiedit, which is a low-level editor for the Active Directory; Dcdiag, to diagnose the Active Directory; and Ldp.exe; then we have different log files that we'll talk about; then there is Netdiag; there is Netdom; and there is Nltest (both Netdom and Nltest are secure channel manipulations, and there are other functions of those, too); then there is Nslookup, which is very important to make sure that the DNS is functioning properly; Ntdsutil is a very powerful tool to use with Active Directory; there is Ntfrsutil, which you may use sometimes; and there is Repadmin, which manages replication; and Replmon, which monitors application; and finally, Secedit.

First is Adsiedit (slide 12); it's a low-level editor for the Active Directory. It provides a means to add, delete, and move objects within the directory services. The attributes of each object can be viewed, changed, or deleted. Adsiedit can also be useful for searching Active Directory; you can create a query and scope it to any level in the tree. The query is then created as a container that allows for continued browsing from the results and the result's children. You can also set up permissions through the Adsi.

On the next slide (slide 13), we have Dcdiag. With Dcdiag you can verify the SPN registration, which is the Service Principle Name. You can also fix the domain controller machine account, if there's a problem with that. There's a Q article, Q257288, that has detailed information on how to recover from a deleted domain controller machine account.

The switches that we use most of the time with troubleshooting Active Directory are dcdiag /fix and dcdiag /v, which generate a verbose log. You can do both switches at the same time, and the log can piped to a text file, and that will have a lot of good information on different tests, if it passes or fails. It will give you the error messages if it does fail. That is very helpful information for troubleshooting the problems with Active Directory.

The next thing we have in the list is Ldp.exe on the next slide (slide 14). It can view and look for SPN registrations and DNS source name, user account control, those values. This is a graphical tool that allows users to perform lightweight directory access protocol operations, such as Connect, Bind, Search, Modify, Add, and Delete, against any LDAP-compatible directory, such as Active Directory.

Many objects stored in the Active Directory are not readily displayed using the graphical tool that's shipped with the recent version of Windows 2000. Ldp.exe can be used to view these objects and the metadata, such as security descriptors and replication metadata, to aid in problem determination.

You can also involve LDAP from the command line LDP. The LDP has a Scope pane on the left side for navigation through Active Directory namespace, and the Result pane on the right side for displaying the results of the LDAP operations.

Any text displayed in the Result pane can be selected with the mouse and copied to the clipboard. And that may be necessary if you're doing some operations like copying the whole SPN path for the DN path and modifying that, if you need to.

On the next slide (slide 15) we have the troubleshooting logs for Active Directory. This is very, very important for helping us troubleshoot the Active Directory issues that we may have. First is Dcpromo.log, and then Dcpromos.log, and then we have Dcpromoui.log. I want to talk about those first, before I get into the Event log and Netsetup.log.

The Dcpromo.log is created by using the Active Directory Installation Wizard, its default location is the %SystemRoot% \Debug folder on Windows 2000-based servers. It also records settings used for the promotions or demotions, such as the site name, the path for Active Directory database and log files, time synchronization, and information about the computer accounts. The Dcpromo.log file captures the creation of Active Directory database, seizable trees, and installation and modification of services.

The Dcpromos.log (the Windir/debug/dcpromos.log) is created by that user interface during the graphical user interface mode setup, when a Windows NT 4.0-based domain controller is promoted to Windows 2000 Domain Controller. So it's only created when you're upgrading a Windows NT 4.0 DC to a Windows 2000 DC.

The Dcpromoui.log contains a detailed progress report of the Active Directory installation and removal process. The location is the same as the Dcpromo.log, which is the %SystemRoot% \Debug folder.

Logging begins when the Active Directory Installation Wizard is opened, and continues until the Summary screen appears, regardless of whether it terminated prematurely or completed successfully.

If the installation or removal failed, detailed error messages appear in the log immediately after the step that caused the failure. When the installation or removal process is successful, the log provides positive confirmation of the fact. So just from that, you can understand how important these logs can be when we're troubleshooting Active Directory.

The other things that we need to look at are event logs, especially the Directory Services log, DNS log, File Replication, and System log. Sometimes you may need to look at the Application log, also. These logs usually provide us with events that are related to the promotion or demotion or any failure that it is having, and help point us in the right direction for troubleshooting.

There is also a Netsetup.log that analyzes the file that is located on the system that can join the domain. Look for a function to fail and note the function that fails. All of that is provided in the Netsetup.log.

If the Netsetup DsGetDCname function failed to locate a domain controller, there may be a problem resolving the DNS name. So by looking at that, you know that the problem may be resolving the DNS name. So to test the resolution, you can run Nltest and do a DsGetDCname of the domain and see if it can get to the domain controller.

If the Netsetup DsGetDCname function failed to find a domain controller with a computer account on the domain controller, the client may not have created the account on the domain controller correctly. So that is another important log that you may need to look at when troubleshooting the Active Directory.

On the next slide (slide 16), we have the Netdiag tool. This verifies the SRV records and the network functionality. And like the Dcdiag tool, we also can use the Netdiag /fix and Netdiag /v more often than others.

One article I want to mention here is Q219289, which is helpful information on troubleshooting with the Netdiag utility. This utility tells us if everything is registering with the DNS or not, and if there are any problems with that. So you may want to look at that to make sure that all of those are functioning properly.

The next slide we have is Netdom (slide 17); we use Netdom for secure channel manipulations. You can join the domain, you can reset secure channels, you can create machine accounts, and you can create and manage trusts with Netdom. So if for any reason it fails and you figure out from different logs or troubleshooting that there may be a problem with the machine account, then you may want to use Netdom to reset the machine account, or join the domain and such.

And Nltest, which is on the next slide (slide 18), pretty much does the same thing, but it has some more functionality. It can force a synch, reset a secure channel, and change the database replication. It can query for all types of secure channel issues and query time service, and you can list domain controllers. Netdom and Nltest are very much alike. You can use either one. A lot of times it's a good idea to try both; if one doesn't work, then the other may still work.

Nslookup, which is the next slide, is for querying the DNS tools. If you do an Nslookup, look at the Help files. There is a Q article that describes the using Nslookup, which is Q200525. It has all the switches that you may need to use. So to verify all the SRV records that the servers need to register with DNS, and to make sure that those are registered properly, and that those are seen by other DCs or other machines, you may need to use this tool in the process.

And the next one we have is Ntdsutil (slide 20). This is a very, very useful and very powerful tool to troubleshoot Active Directory. Ntsdutil performs database maintenance of the Active Directory store, the management, and the controls of the single master operations, and does some clean up of the metadata left behind by the abandoned domain controller (those which are removed from the network without being uninstalled).

A lot of times what we find is that if you have a problem updating or upgrading a second DC, and it just does not seem to be working — or you have pretty much tried everything that you can think of, and it just doesn't seem to be replicating the information that it should from the first DC — at that time you can use Ntdsutil to forcefully demote that DC to a standalone server. Then bring it back to the same domain and make sure that your first DC is working properly, and then make sure that on the second DC, all the name and IP configuration and everything seems to fine. Then you can go back and start the Dcpromo process again on that second DC. More than likely, 99 percent of the time, you will have success with that.

A very helpful Q article here that I want mention is Q216498. You can use that Q article and use Ntdsutil on your first DC to get rid of all the information off the second DC. Then you can take your second DC offline, and use the same article to get rid of information on the first DC. And then you can install DNS on the second DC offline and point it to itself. Then you will be able to demote that as the last domain controller in the domain.

Now this is an extreme measure. We don't usually do this, but sometimes it may save time to do this, instead of trying to find out what actually went wrong, which a lot of time is really hard to do. But after you think you have tried everything, and you just feel like there's nothing else to try, or if you're in a time crunch and you just have to do it, then that is what you can do.

The next thing we have is Ntfrsutil (slide 21). Ntfrsutil can show the file replication configuration in the Active Directory. It can list the active replica sets in a domain; it can list the application programming interface and version numbers for FRS, and so forth. So that sometimes is useful to view the FRS configuration in Active Directory and the replica sets. So that may come in handy also.

Then we have Repadmin (slide 22); it allows the administrators to view the replication topology. Sometimes it's referred to as Reps From and Reps To, as seen from the perspective of each domain controller.

In addition, Repadmin can be used to view replication topology, to force replication events between domain controllers, and to view both replication metadata and up-to-dateness vectors.

The Q article that we want to mention here is Q262561. Also look at Q229896 and Q232072. All of these Q articles that we mentioned throughout this WebCast are at the end of our WebCast slide presentation. So if you didn't have a chance to write them down, then you can find them there. Those are good places to look for information, if you need help with troubleshooting Active Directory.

The next slide we have is Replmon; it's a graphical monitor replication tool that detects all directory partitions on the selected server. You can view replication, both directly and transitively. You can display object sequence number values. You can also trigger the Knowledge Consistency Checker with this, and you can see the objects needing replication. So this also is a good tool to use when you're troubleshooting the Active Directory.

And finally, on the troubleshooting tools, we have Secedit. Secedit is a very, very useful tool also. If you need to analyze or configure system security, or if you need to refresh security settings, export security settings, and validate security configuration files, you can do all of that with Secedit. The common one we use is Secedit /refreshpolicy. Because in a lot of cases, if you find that you don't have the Everyone group or the Domain Controllers group in your Access This Computer From Network right, then you may need to refresh the policy after you add those groups in there. Or if you have a problem with the DC itself, and you need to go back to the default, then you may need to use the Secedit tool to do that.

So that's pretty much all the troubleshooting tools that we wanted to talk about that are helpful for troubleshooting with the Active Directory. On the next slide, we have a summary of what we covered today. So let's look at that.

First, we talked about Dcpromo, and what the Dcpromo is. It's the executable that converts the machine to a domain controller or Active Directory machine.

And then we covered how to plan DNS and Active Directory. Again, it is very, very important to put time into planning DNS and Active Directory. The better planning you have, the less likely you are to have any problems. Because in most cases, when we see problems with the DNS or Active Directory, people haven't planned, and they chose one DNS name, but they didn't really want that, they wanted a different DNS name, and things of that nature. They haven't planned well, if they're going to have the same name on the external, Internet side, as well as the internal side, and so forth. So it is very, very important to plan your Active Directory installation before you implement it.

And then we covered how to install the Active Directory. That's just the process that you go through with the Dcpromo: selecting where the Active Directory is going to be and where your log files are going to be, and if it's the first domain controller or the second, where the DNS is, and what the DNS domain name may be, and so forth.

Then we had how to tell if Active Directory was successful. This is very, very important, to check to make sure that the first DC, or any subsequent DC that you have, to make sure that all the folders that are supposed to be there are there. Ensure that all the objects that need to be there are there, like the machine account in the domain controllers OU, and the NTDS objects that are in the Active Directory Sites and Services Snap -in which you can open up by clicking Start, clicking Run, typing dssite.msc, and then clicking OK (or you can do it from the Admin Tools menu). Make sure that all of those are there. Make sure the application runs properly, and check the event logs to see if there are any errors, or if they're pointing to any failure anywhere. That's how you can tell if it is functioning properly or not.

And then we covered how to install replica DCs. The same thing again: make sure your DNS is in place, and it is doing dynamic updates. Ensure that your first DC is working properly, and that other DCs that you may have in the domain are working properly. Make sure that you have the rights to do it. Make sure all the objects are created and so forth.

Then we talked about the tools that we can use to troubleshoot Dcpromo. Again, I wanted to mention that we talked about the tools very briefly, and we haven't gone into much detail at all, because of the time constraint that we have. But the Microsoft Windows 2000 Server Distributed Systems Guide is a very, very useful book to go to look into those tools, and see which options you may need to choose or use to troubleshoot the Dcpromo process or the Active Directory installation process.

At this point I would like to hand it over to Heidi for the Q&A session.

Heidi: Okay, excellent. It is time to move on to the Q&A portion of this session. Mike and Ed mentioned that there were a lot of KB articles and URLs at the end of the presentation. There are six slides that are full of URLs. The URLs are long and cumbersome. I encourage you to download the slides; they are available now. And if you don't have PowerPoint^®, you can always use the PowerPoint Viewer Add-in to have a look at those. That would be your best option there.

A couple of pointers about the Q&A session: we do only take questions during the live event, so this is the best opportunity that you have to ask those questions. The Q&A is intended for further discussion of the topic. However, one-on-one product support issues are outside of the scope of the Support WebCast. So if you do need some one-on-one support, you're going to want to either submit an incident on the Web or call into Microsoft Product Support Services for assistance.

With all of that said, let's get started. Our first question is: What step should we plan out more than any other step in setting up an Active Directory? In other words, where do most of the problems occur?

Mike: Most of the problems occur in the DNS plan. For example, they have an ISP and they decide "Okay, well my people aren't going to go out on the Internet," so they pick a very flat name. They don't even put a .com, or maybe don't even put a valid DNS name on there. And then a week later, they decide, "Oh my goodness, I really want to go out on the Internet and I really want to start hosting my own DNS."

Planning is very big problem with DNS, and it is very common. Pointing the DNS client of the servers to the original DNS server on the domain instead of the ISP DNS server will avoid connectivity problems. Configuring DNS when you are joining a replica domain controller or joining the domain can avoid problems as well. I mentioned that having a DNS suffix already in Windows NT 4.0 is a very common mistake as well. They will have the suffix, and we put that feature in there, because several companies wanted the ability to have a separate machine namespace, versus their DNS space. However, it does cause problems with replication, and it's much easier and cleaner if you have them in the same space.

Ed: There's one other thing I wanted to mention on the same topic: a lot of times people will install one domain controller, and that will run for a while and everything seems to be running fine. And they may have installed the DNS on the machine, during the Dcpromo process, but they may have forgotten to configure the zone that they were planning to have for their Active Directory. And there's a misconception about the settings, a lot of times, because they will have an existing DNS in their ISP who is hosting their Web site.

For example, if they have "companyx.microsoft.com" as their Internet name and their ISP is hosting that, and they also want to have the same domain name on the internal site, companyx.com — at that point what a lot of people will do is point their DNS on the first DC, as well as on the other clients, to the ISP's DNS server, instead of pawning it to its own DNS server. Most of the ISPs will not allow you to have dynamic updates; they will not have that feature. So what is important here is to understand that when you have an ISP hosting your DNS, that is your Internet DNS zone. For your Active Directory, you need to have a DNS server that can do dynamic updates.

In this case, you don't have to use Microsoft DNS; you can use BIND DNS, but make sure that it is at least version 8.1.2, or a later version that can do dynamic updates. So the important thing is to make sure that you have the DNS installed; it does not have to be installed on your domain controller. If you have another Windows 2000 server, you can install it there, but make sure DNS is installed, make sure everybody in your Windows 2000 domain is pointing to the DNS. And make sure that the DNS is doing dynamic updates. Then, from that DNS, as Mike said earlier in the WebCast, you can set up orders pointing to your ISP, which will also do the name resolution for your external Internet names.

Heidi: Okay, excellent. Quickly, before I move on to the next question, I want to encourage everybody to send feedback regarding the Support WebCasts. We're very interested in your feedback about this session or any other session you've seen, topic suggestions that you have for the future, or an overall impression of the Support WebCasts. We'd also be really interested in knowing where you found out about the Support WebCasts. Was it online? Was it from friends? Did you get a NewsFlash sent to you? So once again, if you do have a few moments, we would appreciate some feedback.

You can use the alias feedback@microsoft.com. Be sure to include "Support WebCasts" in the subject line.

Okay, moving on to the next question: In a mixed environment of NDS and ADSI, would replicating the NDS structure make sense for the design of ADSI?

Mike: [Editor's note: Additional research was required and the answers are included here. To answer the question, I have come up with the Microsoft Directory Synchronization Services (MSDSS), included with Services for NetWare 5. It will do one- or two-way replication. However, it's still in beta at this point. The link below will describe additional information about the synchronization of the Active Directory and NDS. I also found additional links. You can go to the http://msdn.microsoft.com/ Web site and find additional ADSI and NDS information.

Synchronizing Windows 2000 Active Directory with Novell Directories http://www.microsoft.com/WINDOWS2000/library/planning/interop/dirsync.asp

Q227207: "Novell NDS v2.0 for Windows NT Does Not Function on Windows 2000" http://support.microsoft.com/support/kb/articles/q227/2/07.asp

Q244030: "Cannot Find Active Directory Domain Controller Upgrading PDC" http://support.microsoft.com/support/kb/articles/q244/0/30.asp

Q248079: "Directory Object Not Found Error Message During Dcpromo.exe" http://support.microsoft.com/support/kb/articles/q248/0/79.asp]

Heidi: Okay, the next question is: Can BIND DNS or the DNS server at my ISP be used instead of the Microsoft DNS?

Mike: Yes it can. One advantage, though, is it is nice to manage your own DNS namespace , instead of relying on your ISP to do it. It sounds like we're really hard on Microsoft DNS, but we're really not. I love the product and it's very easy to configure. The article in the references (Q237674) points to setting up DNS for Active Directory. It's a very simple several-step article on how to do it. And it doesn't take a whole lot, it's just a matter of setting a simple forwarder up to your ISP. You can do it the other way, as long as they do accept the dynamic updates and SRV records. However, my preference, if I'm a network admin, is to keep that in house.

Ed: Yes, that is very, very important, to make sure that when you're doing it through BIND or through your ISP, that they have dynamic updates enabled. Or that they can do dynamic updates, because otherwise you will have problems.

And the other thing is not only the dynamic updates, but make sure that they can register their SRV records as well. So yes, it is possible, but those are the conditions that have to be met.

Heidi: The next question is: What initial steps can be taken when Dcpromo fails?

Ed: Well the initial steps that anyone should take is find out at what point does Dcpromo fail? Does it give you any error messages? Does it immediately pop up with any error message? If it doesn't, then the next thing to check is the event logs. Check the other log files that we talked about, the Dcpromo.log, Dcpromoui.log, and the Netsetup.log we talked about. Those should have some indication of where the problem lies.

Also check to see if the replication happened or not. Make sure the SYSVOL and all the folders underneath the SYSVOL folder are there. If they're not there, that would indicate that there's a problem with the replication. So once you check those logs and event logs and so forth, and you get those error messages, that should get you started as to what may be the problem. And then you can also do a verbose log, using Netdiag and Dcdiag, and take a look at those to see what may be the problem.

Another thing to check is to make sure the time is synched up between the forest DC and whichever other DC your are trying to promote. Make sure the times are synching with each other, because if the time is more than five minutes of each other, then you may have a problem. So make sure that that is okay.

And once you do some troubleshooting and you have some event logs or error messages, at that point you can try different things and maybe use some of the tools that we talked about.

Mike: Also, it never hurts to do a network trace on some of the issues as well. With a trace, you can see exactly where you're failing. It's another valuable tool that we didn't necessarily list. You can get some great information out of the network trace as well.

Heidi: Okay. The next question: How would you plan for the size of the Active Directory?

Ed: Actually, there is a good piece of information in the Microsoft Windows 2000 Server Distributed Systems Guide. If you look at the second chapter of that book, on pages 83 – 85. It has a very good description of how much space it may take. It depends on how big your domain or your enterprise is. It lists how much space it may take for user accounts, organizational units, attributes, and so forth. So if you look at Chapter 2 on page 83 – 85, that has real good information there. Overall, Chapter 2 is a good place to find out how to plan for the size of your Active Directory.

Heidi: Okay. Do you happen to know if that's online as well?

Mike: I would check the http://www.microsoft.com/technet/win2000/dguide/ and see what chapters are available there.

Heidi: Yes, that's what I was thinking. I know that they do put some of the chapters from those resource kits into TechNet, onto the TechNet site and into the subscription CDs. So that might be a good option, if you don't have a hard copy of the resource kit.

Mike: Now Ed and I sound like salesmen for the resource kit, but we use this tool every day. And I highly recommend it —we have several locations on the Internet with the resource kit, at least several selected chapters of it — it's a great resource, and it can save you a lot of headaches and aggravation, by just spending a little time in looking at it and reading those sections.

Heidi: The next question is: Can you Dcpromo a machine over VPN connections?

Ed: Yes, you can. But make sure that you have a good connection between the DC that you're going to replicate from and where you're at. Make sure the connection is good, that there is not really any difference between the VPN and being in the same LAN. The only difference is the speed and the way you connect them.

Our recommendation, though, is at least a minimum of a 56-Kbps connection between the two sites for which you're going to do this. Now a lot of people have successfully done it, even at a lower speed than that. We do not recommend it, because of all the replications and everything that needs to happen initially. That's why it is very, very important that you have a good connection between the two locations.

So yes, it is possible, but make sure that communication is good.

Heidi: Okay, next question. The scenario is you have just migrated your Windows NT 4.0 primary domain controller to Active Directory. What tools would you run first to check to see if all is well, besides the logs?

I'm guessing what they mean is: Besides looking at the logs, what tool would you run first to check to see if all is well?

Mike: I'm not sure if he's gone through the Dcpromo process already, but I'll answer it in two ways. First that he hasn't done the Dcpromo process: I'd probably look at the NETLOGON; I would also look at a Netdiag and see the network configuration. I would also do an IP config /all and make sure my IP properties are correct, my name is correct. And then I would also check connectivity to myself, as well as other boxes.

If they have Dcpromo'd, and they're saying it's failing: usually it will give you an error, an access denied, which could be a file permission on a share on the SYSVOL — the system or the admin or some denial process. So you can go in and check the file permissions. Or it could be a permission like Access This Computer From Network; you'll get an access denied there as well.

It's possible that you could get a file replication problem, and the SYSVOL share is failing to show it. There's a great article that I mentioned earlier on the SYSVOL of the Netlogon shares failing to share out. It's a common issue that we run across, and there are many possible reasons for it. But Dcdiag and Netdiag are great resources for troubleshooting after the Dcpromo process.

Ed: You can also use tools like Adsiedit and find out if the objects that need to be created are there. You can also use Ldp.exe. Once you bind and connect to the server, you can check and see if your SPN, which is Service Principle Name, is registered properly for the DC that your are promoting.

And the DNS host name record, make sure that is there, and also the user account control, make sure those are there. If those are missing, then that will be a pretty good indication of the problems that you may have with your second DC. So, besides looking at the logs, these are some of the tools that you can do.

But usually, before we use any tools, we look at the logs and see what the errors are. And based on those errors, we go in using different tools. Because for one error, when access is denied, it would probably not be very helpful using LDP at that time, immediately. It may be better to check into other things before you do that. So it is always helpful to look at the logs first. Then, depending on what error you are seeing, you may want to use different tools.

Heidi: Okay. Moving on to the next question, and what looks to be just about the last question at the moment: How do you recommend setting up an Active Directory in an ISP or ASP environment?

Ed: When you are saying ISP or ASP environment, it really depends on the organization itself. We do not want to give any recommendations in general, because it is always so dependent on each business's individual environment.

In an ISP environment, what I'm assuming that people may mean is that usually the ISPs will host multiple zones for different companies. Now when you're talking about that, that is part of DNS. And that part of DNS, which you're hosting on the Internet namespace, doesn't affect anything with the Active Directory.

You can support multiple zones from the same DNS server. And the thing is that most of the time, those zones that you're serving for the other companies, for their Internet namespace, don't have to be turned on for dynamic updates. The only important thing is for the Windows 2000 zone that you're going to have for your Windows 2000 domain or forest, you need to make sure that that is set to dynamic update.

And then, if you have multiple levels of domains, then you create your, for example, "corpx.microsoft.com" zone, and that's your root zone for the forest. And in that tree, which is corpx.com, you may have other child domains and grandchild domains and so forth, which you will just create as a folder under that. The setup of those can be different, depending on your particular need.

You can set up a child zone and you can delegate control to other DNS servers, or you can do it just in the same DNS server. And for that, I would really recommend you look into the DNS white papers or namespace planning white papers, and it's going more into DNS. And that's probably what is more important to the ISP organizations than anything else.

But as far as your Windows 2000 domain goes: if you have a small environment where you may have 10, 15, or 20 servers, usually the number of users for the domain, the actual Windows 2000 domain, will probably be a lot less than the actual different kind of business. And for that matter, you may get away with just one single domain. And again, for hosting multiple zones on the Internet, that is completely different than it is for the DNS, so don't get those mixed together.

Mike: Another consideration for the ISP person who was asking the question is, there are two known issues with the number of IP addresses in Windows 2000. There is an over 15 IP addresses and also there's a 51 IP addresses issue. There are some fixes out for those, and they are available to you. I think you may have to call in for additional for those hotfixes, but the incident would be free.

Now it's only for people that use a high number of IP addresses on a NIC card or NICs. Another additional consideration is that when you have multiple NICS, I would recommend that on the external NIC, you disable NetBIOS over TCP/IP. If the computer that's hosting the DNS is also the PDC Emulator, you may have some browsing issues internally as well. So if you can move the PDC Emulator off that box, that's probably not a bad choice as well.

Other possibilities are, if you have more than one NIC, you can have that one NIC just do your domain, and then the other NIC could do your external hosting. So you can disable a registration off the second NIC as well, so you don't automatically register all the SRV records for the domain controller into DNS. So that's another possibility as well.

Ed: One thing I wanted to mention, what Mike just told us about the multiple IPs on 15 or 51 IP addresses. Keep in mind that it's only true for domain controllers, not for regular member servers. So if you have a Windows 2000 domain controller that has a whole lot of IP addresses bound to it, then you may run into an issue where when you try to go into Active Directory Users and Computers or Active Directory Sites and Services, it may not work properly. And at that time, you will need to get the hotfix that Mike just talked about. But that is only true on the domain controllers, not on the member servers.

Heidi: Okay, and with that question answered, we have cleared the queue of all the questions that were submitted during today's event. Once again, I want to encourage all of you to send us some quick feedback, via the alias feedback@microsoft.com; be sure to include "Support WebCast" in the subject. We are very interested in your feedback, so I do want to encourage all of you to send us that feedback.

We do hope that you enjoyed this session today. We have 8 to 12 live Support WebCasts every month, and the on-demand content is available within about eight hours of the live session.

So, with all that said, we have finished for today. Have a great day, and we hope that you can join us again in the near future. Thanks, and bye-bye.