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.

Arren Conner: My name is Arren Conner, I'm a Supportability PM in the Microsoft® Beta Technology Support Group, and I primarily work with JDP and other large customers supporting the betas and trying to make the product better.

Andreas Luther: My name is Andreas Luther. I am Program Manager in the Active Directory® Development Group, and I specifically focus on Active Directory designs and deployments.

Arren: Our objective (slide 2) today is to help administrators, consultants, and support professionals and to give you a framework for how to optimally upgrade your Windows NT® 4.0 domain to Windows® Server 2003. We'll be striving to reduce the downtime between domain controllers and clients during the upgrade process. Non-goals for today's presentation are to tell you about Active Directory design themes, such as optimal organizational unit structure or domain controller placement. These key topics were well covered in Windows 2000, and there are numerous resources, some of which we have references to in our slides.

We'll use a lot of abbreviations or conventions in this deck, so the next two slides talk about these conventions. When we use NT4 (slide 3), we're referring to Windows NT 4.0 domain controllers or domains; 2000 refers to the Windows 2000 Server family; 2003 refers to the Windows Server 2003 server family. The rest of these are pretty self-explanatory.

Moving to slide 4, some other abbreviations that we'll use during the slides is we'll use the triangle or the delta symbol to indicate some kind of change in behavior of the operating system or some kind of configuration change, or the replication of some object in a replication engine, like Active Directory or FRS. If you see the term AD, we're referring to the Active Directory, and this could be on either a Windows 2000 or a Windows 2003 domain controller.

IB and OB refer to inbound and outbound replications. Oftentimes we have to validate replication success in either Active Directory or FRS. LO refers to lingering objects, and we have a slide specifically covering this. And CO will be a change order or a connection object that is used by Active Directory and FRS to replicate objects.

We have an aggressive agenda today (slide 5) and quite a few slides, and we are going to try to move through the content very quickly. But our goal for today is to give you an overview of functional levels and what operating systems and features are reported at each functional level. We'll talk about some lightweight AD planning. We'll talk about how to inventory your clients to make sure that they're going to be compatible with the upgrade. And we'll go over domain controllers, how to make sure that they're healthy before and after the upgrade. We'll give you a process for upgrading your NT4 domain controllers to 2003. And we'll talk about some very detailed post-upgrade operations that we want you to perform.

Andreas: We're moving on to slide 6. We'll give you an overview of the functional levels. Functional levels is a new concept in Windows Server 2003 Active Directory. Basically when we shipped Windows 2000 Active Directory we did not need a versioning mechanism because Active Directory was kind of in its version 1.0 form. But now, because we are advancing the technology and because we delivered a new version of the operating system, we also have new and additional functionality in the directory service, and some of the functionality will be available right away. Some new functionality requires that you upgrade all of the domain controllers in a domain or in the entire forest to Windows 2003 before you can start using these new functionalities.

This is to some degree the same concept that we had in Windows 2000, where we started with mixed-mode domains, and after all of the domain controllers were upgraded to Windows 2000, we could switch the domains to native mode, and then we could start using some additional functionalities in the directory service, like universal groups and changing group types.

What's important to note about functional levels is that client systems or member servers are never affected by functional levels. Functional levels are only something that concerns domain controllers, so the functional level only affects your domain controllers. And only after you upgrade your domain controllers can you advance to the next functional level.

The operating system that runs on your client does not matter at all for functional levels. That means that even if you advance the functional level to the highest level that we have today, which is the Windows 2003 forest functional level, even at that level your client systems can run Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003; it does not have any effect on the functional level, or the clients or servers are not affected by the functional level.

The functional levels that we see in Windows Server 2003 include the Windows Server 2003 domain functional level. This basically affects a single domain. Then we have the Windows Server 2003 interim forest functional level. This is a specific functional level we will discuss in more detail, and it's especially interesting when you migrate from Windows NT 4.0 directly to Windows Server 2003. Then, eventually, we have the Windows Server 2003 forest functional level, which is the most interesting level when you are thinking about an upgrade process.

Moving on to slide 7, we will start by giving you an overview of the functionalities and when they will become available. There are some new functionalities in Active Directory that you will get right away, after you deploy the first Windows 2003 domain controller in your forest or in your domain. These functionalities do not depend on a specific functional level.

I want to give you an overview of all these functionalities. There will not be sufficient time in this WebCast to go into detail on all the new functionalities that you will get. However, we still want to give you an overview so that you know when you get what. We will start with the features that you will get right away and that do not depend on any functional level.

First of all, we see application partitions. Applications partitions are a new functionality in Active Directory where you can store data in the Active Directory database outside of the naming context that you have already known from Windows 2000. So you don't have to start new schema, config, or domain naming contexts, but you can create a new naming context for application-specific data, and this application naming context can then be replicated to any domain controller of your choice.

Universal group caching is especially important in branch office deployments. It allows you to have sites where users log on to the domain controllers, and the domain controllers will not have to contact global catalog servers for the user logon. So that will give you some relief for replication traffic, because you don't have to replicate the global catalog server to all the sites where users need to log on.

Install from media is a new version in the Active Directory Installation Wizard. It allows you to install a new domain controller from backup media. So you can create the backup of Active Directory; you can restore it to what we call an alternate location, which basically creates a bunch of files that you can later use to install Active Directory from these files. And then you can either ship these files with the machines to a location, or you can ship the files on a CD or DVD and then install Active Directory from there. So the initial replication traffic that you need to build a new domain controller will be very, very small, and is basically only the delta of the information after you took the backup and the time when you ran the Active Directory Installation Wizard.

No-GC-Full-Sync, that is very important, again, for deployments where you have slow network connections. In Windows 2000 we created a GC-Full-Sync if we extended the schema in a way that we changed the partial attribute set, which is the set of attributes that we replicate to a global catalog server. In Windows 2003 we removed this so you will never see a GC-Full-Sync in any scenario.

Quotas help you to identify how many objects a user can create in the directory service. This is especially important if you are concerned about denial-of-service attacks where malicious data administrators or users could create as many objects as they want in the directory service and basically run the domain controllers out of disk space.

When you migrate from NT4 over and you restructure users and groups between Active Directory domains, sometimes you want to migrate SIDs into sIDHistories. In Windows 2000 you have to be an administrator in the target domain to get a SID into the sIDHistory of the user object. In Windows 2003 we allow you to delegate that operation to either a specific user or to specific groups.

To improve the performance of the LDAP functionality in Active Directory, we add concurrent LDAP binds. This is especially important in e-commerce scenarios or in outward-facing directory services where you have large numbers of users logging on, and you just want to use simple binds or simple logons to the directory service.

For domain controllers and global catalog servers we not only improved the installation of these DCs and GCs, but we also improved how you can demote the global catalog server or how you can demote the domain controller.

For rapid global catalog demotion, we added the mechanism where you can remove the global catalog server in a very fast fashion. In Windows 2000 this sometimes took a long time.

To save disk space on your domain controllers, we added the single-instance store. The single-instance store will allow you to store security descriptors for objects in the directory services only once in a specific table, and then you will have pointers from all objects that share the same security descriptor to the security descriptor table. So that will relieve disk space requirements for your domain controllers, and what we found with our internal deployments is that you will probably get approximately 40 percent of your disk space back for your domain controllers after you upgrade them from Windows 2000 to Windows 2003.

For account lockouts we made a lot of improvements and we added more tools, and we also improved the events and messages that we had in the directory service.

Moving on to slide 8, I will give you an overview of the functional levels that we now have with Windows 2003 Active Directory. Whenever we start a deployment, we start with the lowest available functional level, which is the Windows 2000 mixed functional level for a domain level, and the Windows 2000 functional level for the forest. I want to give you an overview of all the new functionalities that you get as you're increasing the functional levels, and we want to start on the per-domain level.

When you start with the Windows 2000 mixed-mode domain, you basically get the functionalities that you know from Windows 2000. You have universal groups, but not a security-enabled group. So you can only use them for Exchange 2000, for example. Supported domain controllers in those domains are NT4 DCs, Windows 2000, and Windows 2003 domain controllers, so you can already see that your Windows 2003 domain controllers can also play a part in Windows 2000 deployment.

After we switch from domain into native mode, we have additional features available; we have group nesting, we have universal groups, and we can start using sIDHistory. We can also convert the groups between the different group levels. Now these new features will no longer be understood by NT4 domain controllers, so the only supported domain controllers in these environments are Windows 2000 DCs and Windows 2003. The Windows 2003 Server interim mode is kind of an interesting mode, both on the domain level and on the forest level. On the domain level, you don't really see any additional functionalities, and you don't really need the specific mode. You will need the forest functional level, but we'll cover that later in more detail.

Moving on to slide 9, we'll give you an overview of the new functionalities that you get in a domain after you switch to the Windows 2003 domain functional level. Now within the domain you get additional functionalities, because there are updated logon time stamp attributes used to find standard computer and user accounts.

You get Kerberos KDC versioning; that is more of an internal functionality that we need in the KDC. You get user password for INetOrgPerson. This is especially important for LDAP applications that are using INetOrgPerson and want to protect user and resource access by passwords for these users. You get a DC rename with netdom, which is basically a two-stage rename process, but a domain controller will listen to both the old name and the new name for a while.

You will be able to redirect users and computers, which we'll cover in more detail later.

And we have some functionalities for Web-based applications, like the Authorization Manager. The Authorization Manager can start storing authorization policies in the directory service, which you can use for role-based access control for Web applications. We also have constrained delegation for computer switches, a security feature, again, that allows you to restrict delegation functionalities. And we have selective authentication cross-forest, which would allow you to kind of find out whether a user who wants to log on to a resource comes from your own forest or from a different forest.

So as you can see from the overview of the domain functional levels, there are not really that many advances in the domain functional levels; more advances come with the forest functional levels. So when you think about an upgrade process, you should focus more on setting the forest functional levels, and only in very minor cases would you have to worry about the domain functional levels. The reason for that is that after you advance a forest functional level it will automatically advance your domain functional levels. So let's focus more on slide 10, on the forest functional levels.

When you start a fresh deployment of Active Directory, you will start in the lowest forest functional level that we know, which is the Windows 2000 functional level, exactly what you have seen in Windows 2000. When you start in that functional level, you can, again, use NT4 domain controllers, Windows 2000, and Windows 2003 domain controllers.

The next available functional level is the Windows Server 2003 interim level. This is a very interesting level because, as you can see in the supported domain controllers column, in this level we will support Windows NT 4.0 domain controllers and Windows 2003 domain controllers, but we no longer support Windows 2000 domain controllers. So you might wonder why we actually need this level.

The reason for that is because in Windows 2000 we had a limitation for the number of members in a group, which was that a group could not have more than 5,000 members. If you had more than 5,000 members, you got into an unsupported state. We know that there are many NT4 deployments today where large NT4 groups exist and have more than 5,000 members.

To give these deployments a clean upgrade path to Windows 2003, we needed to create a mode where we can already use the new replication protocol in Active Directory that allows you to have more than 5,000 members in groups, which is linked value replication. In this mode we also needed to be able to support NT4 domain controllers — because your upgrade will take a long time — and Windows 2003 domain controllers. So this is what we call the Windows Server 2003 interim mode.

In this mode we already switched to the new Active Directory replication protocol LDR replication, so that we can support large groups, and that will give you a clean upgrade path from NT4 if you have large groups in your NT4 deployments. We also added some new features and functionalities to this mode, which is the improved ISTG. The ISTG is the Intersite Topology Generator that is responsible for creating the replication topology between different locations. So you will also get that immediately if you deploy the Windows Server 2003 Interim mode. And we will add some new attributes to the global catalog server.

After all of your domain controllers are upgraded to Windows Server 2003, you can switch to the Windows Server 2003 functional level. In this mode we only support Windows 2003 domain controllers and no old domain controller operating systems. In this mode you have all of the Windows Server 2003 interim functionalities, plus you get some more, which are dynamic aux classes, which allow you to add auxiliary classes to already existing or instantiated objects of, let's say, the user class or INetOrgPerson.

We can switch users to INetOrgPerson. We know that many customers want to use INetOrgPerson instead of the user class, because they already have LDAP deployments that use INetOrgPerson classes, and they want to make synchronization between the directories easier.

We have a new functionally in the schema that will allow you to deactivate and reactivate schema extensions, so that will help you in those scenarios where you were afraid that you made a schema extension that might have been the wrong extension. Now you can deactivate the extension and reactivate it again using a different syntax. We have domain rename that will allow you to rename your domains. So by doing that you can basically rename your entire forest. We have cross-forest trust relationships that will make it easier to create trusts between domains and different forests. And we have basic and query-based groups, which are, again, useful role-based applications for Web applications.

In addition to that, we also changed the replication frequency, so now within the sites we will replicate much faster between domain controllers — 15 seconds is the new threshold — and that will basically allow you to synchronize the content of a site within a minute.

Moving on to slide 11, in this slide we will talk about strategies for your forest root domain. When you start your Windows 2003 deployment you need to find out what the best strategy for you is in terms of your forest root domain. First you need to think about a strategy of how you should upgrade your existing Windows NT 4.0 domains. Should you just use an in-place upgrade for all your existing NT4 account domains and consolidate those account domains later, after you upgraded them to Active Directory? Or should you do your consolidation process as part of your upgrade process?

A strategy that we have seen many customers use in Windows 2000 was that they picked one or several large account domains, NT4 account domains, and upgraded them to Active Directory. And then after the small number of account domains were upgraded, they migrated users from the remaining account domains, and then migrated them into the Active Directory account domains.

When you start the upgrade process, the first domain controller that you upgrade to Windows Server 2003 always needs to be the primary domain controller in an NT4 domain. So for each NT4 domain, you start the upgrade process by upgrading the PDC to Windows 2003. The strategy that you need to find out is what will be the upgrade or installation process for your forest root domain?

If your forest root domain will be a domain that you upgraded in-place from an existing NT4 domain, then you will be able to set the forest functional level as part of the upgrade process when you go through the Active Directory Installation Wizard. However, if you install your forest root domain as a fresh or brand new Windows 2003 Active Directory domain, then the default installation will actually start in the Windows 2000 domain and forest functional level.

In that scenario, if you plan on upgrading additional NT4 account domains into child domains of the already existing forest root domain, then you need to make sure that you get into the interim level before you start the upgrade process on the NT4 child domains. Because only if you upgrade an NT4 domain into a forest root domain will you be able to select the forest functional level as part of the Active Directory Installation Wizard. So you need to think about that strategy. If you newly create your Active Directory forest root domain, then you need a tool like LDP to put the forest into the Windows 2003 forest functional level.

Some more background on the interim mode and security groups (slide 12): Again, we already told you why we created this interim mode. Just to add some more clarification on that, in Windows NT 4.0 we have no limit for the members in a security group, so groups could be really, really large. In Windows 2000 we have this limitation of 5,000 members in a group. This limitation was not really enforced by the system. So we theoretically allowed you to create groups that were larger than 5,000 members. And in most cases, this did not create any problems.

Your groups, if they were slightly bigger than 5,000 members, they probably worked fine; they replicated fine. However, the success of replication always depended on the loads of the domain controller that replicated group membership changes. So what we saw is that sometimes replication worked, sometimes replication did not work. So by creating this 5,000-user limit, we knew the customers were in the safe state, so that's where this limitation came from. Again, the interim mode was created to give you a safe upgrade path from NT4 deployments where you have larger groups than 5,000 members.

If you have an NT4 deployment today, and you know that you have applications that are running on domain controllers, and maybe you already put Windows 2000 domain controllers into the mix, then you might be in a situation where you cannot go straight to the interim mode (slide 13). A reason for not going into the interim mode cannot be NT4 domain controllers, because you can use NT4 DCs in the interim mode.

Reasons for not going into the interim mode can only be that you already have existing Windows 2000 domain controllers or that you are thinking about adding Windows 2000 domain controllers to your deployment later. If you're thinking about having Windows 2000 domain controllers as part of your deployment, then you need to think about a strategy — what you should do with your groups if you have more than 5,000 members in existing Windows NT 4.0 groups.

One strategy would be to break up groups into multiple groups. For example, you can create multiple groups and then add members from A to L to one group and members from M to Z to the other group. After you have multiple groups, you need to think about how you can re-permission your resources. So you need to run security translations on the resources to make sure that everywhere you have the old group's access control list, you replace the single old group with the multiple new groups that you have. Again, it is a much easier, much more cost-efficient way to upgrade from NT4 to Active Directory if you go to the Windows Server 2003 forest interim level right away.

Arren: We've given you some specifics on what to do. Now we want to build a framework around some pre-upgrade tasks that you want to take a look at (slide 14). First of all, you want to inventory applications that you have in your domain and your forest and make sure that they're compliant with the Windows Server 2003 operating system.

Next, you should have defined your Active Directory namespace and your forest structure and so forth. In NT4 the domain was a defined security boundary, and this is not the case in Windows 2000 and 2003 domains. We have another slide with some resources that discuss that topic.

Next, you'll have defined your organizational unit namespace and your delegation model. We had some information about a best-practice OU structure that we'd like to implement. So you'll have defined the site links and site link definitions, and defined your DNS namespace and how you'll delegate that throughout your organization. And then your DC placement will be defined, how many DCs you'll place in the different Active Directory sites, or whether DCs will even exist in Active Directory sites. Then you'll upgrade your existing DCs, or discuss whether to do virgin upgrades on those or upgrade in place. And then you can define how you get to interim mode versus doing a fresh upgrade.

We didn't want to cover much on the Active Directory namespace because it has been well defined in the Windows 2000 timeframe in the last three years, but we did want to talk about some areas that we've seen some problems with, so that's what we'll cover here (slide 15).

First of all, the maximum number of characters for the fully qualified domain name in a forest is 63 ASCII or UTF-8 byte characters. Non-ASCII characters, like those using the Far East character set, for example, use more UTF-8 byte characters in this name. But for U.S. ASCII names, you can place your Active Directory domain names under the ruler in this slide and see if you're going to be in compliance. So all root, child, and subordinate domains need to live under this 63-character limit.

For the forest structure, the best-practice domain structure is to be no more than two to three levels deep in the forest structure. You can go deeper, technically, but there is just no value in doing so, and it becomes cumbersome. The other strategy that we've seen that doesn't work is to create a large number of subordinate domains under a single parent. That's quite a problem to administer. In fact, there are some limits in Active Directory where you can't have more than 850 subordinate domains under single parent. So you can have an extremely large number of names on a forest, but there's a limit to the number of domains that can exist under a single parent.

As far as the number of domains in the forest, the fewer the better (slide 16). But you may be required to create new forests to satisfy political requirements, to define who owns the schema, to control replication traffic, or you might have specific security or legal requirements that require the creation of additional forests.

As far as the organizational unit structure, we get quite a few questions about how deep the OU structure can be. The reality is you can make the structure quite deep, but a practical level is to have no more than three or four levels, as you'll realize this becomes cumbersome to manage, particularly when you're in a tool like LDP or at a command-line utility, and you have to specify the DN path for that object.

In NT4 the domain was a rigid security boundary (slide 17). That means that if you had a master account domain with multiple user account domains and resource domains, that the domain was a rigid forest security boundary. This is not the case in Windows 2000 and 2003 domains, because there is some information that is shared between all domain controllers in the forest. It's possible for a malicious administrator to cause some problems for other domains in the forest. And so where you have strict requirements for isolation between domains, you may want to consider additional forests (http://www.microsoft.com/downloads/details.aspx?FamilyID=b717bfcd-6c1c-4af6-8b2c-b604e60067ba&DisplayLang=en).

We spent a great deal of time locking down the operating system in Windows Server 2003, and we want to talk about some of the interoperability issues that those security changes require. The first thing is that all Active Directory administrative tools on Windows XP, 2003, and 2000 SP4 clients now enable LDAP signing so that they're secure and encrypted on the wire. This has some implications when you're administering Windows 2000 domain controllers that are running SP1, SP2, or earlier.

If a client is running these admin tools and performs NTLM fallback authentication to these pre-SP3 Windows 2000 machines, then the admin tool won't be able to authenticate performance operations unless one of two things happen; either we install Windows 2000 SP3 or later on the 2000 domain controllers that we're administering, or we relax the security setting that's documented in the KB to enable NTLM authentication to occur. So here's an argument for installing SP3 or later on any domain controllers that you administer.

Two more common situations that cause NTLM fallback authentications are when you're administering 2000 domain controllers across a trust relationship or if you start the admin tool, focusing on the target DC, using its IP address.

The next thing that was disabled in Windows Server 2003 was the ability for an anonymous user to resolve a SID to a name, and this is a security setting that's enabled in the Group Policy Object Editor. You'll commonly see if this is a problem when you go into ACL editor and try to add a user from an NT4 resource domain for a user account that exists in a 2003 server account domain. You'll initially be able to add the user account, but when you subsequently go back into ACL editor to view the account, you might see "Account Unknown."

You might also see authentication failures by Microsoft Outlook® clients in the same scenarios. And even worse, the success of the operation may be intermittent, as secure channels between domain controllers move between NT4 or 2003 domain controllers, or even 2000 domain controllers, because this setting is defined in the local security policies of 2003 DCs.

The pre-Windows 2000-compatible access group is also an important group to take a look at (slide 19). If the Everyone group was a member of this group in Windows 2000, then we added Anonymous Logon and Authenticated Users. But if Everyone wasn't a member of this group, then we had problems authenticating, so you'll want to take a look at that.

It's probably rare that you have LDAP applications in your NT4 domain, but in Windows 2003 anonymous LDAP access is disabled, and there's a KB article (326690) that discuses how to enable that.

We've talked about some security settings, and there are a couple more that affect clients specifically, and you have some choices (slide 20). One of the things that happens is that we've enforced SMB signing on Windows 2003 domain controllers. This setting is incompatible with Windows 95 clients specifically. Windows 95 and NT4 computers, with SP3 or earlier, fail.

So what you want to do is either install the updated DS client on the Windows 95 machine or install SP3 or later on the NT4 machines. If you can't do that, then there's a security setting that you'll need to relax to make these clients compatible with 2003 domain controllers.

NT4 allows some names for computer names and NetBIOS names that were not supported by Windows 2000 and Windows 2003 domain controllers (slide 21). There's a KB article on this topic. What you'll want to do is take a look at this KB article and inventory all of the domain controllers in your domain to make sure that their names are legal. If they aren't illegal, then you'll want to upgrade them prior to the operating system version upgrade. An example of an illegal name would be an all numeric NetBIOS computer name.

NetBIOS domain names have similar requirements, and so legal characters for these were A through Z upper case and lower case, 0 through 9, and the dot and the dash. The maximum domain name length, as we discussed earlier, is 63 characters, and we have a very detailed article on this (245809).

Single-label domain names, you won't seen those in NT4, but a single-label domain name in Active Directory would be something like Active Directory with no extension at the end of it. This is not a recommended namespace for Active Directory domains, either in Windows 2000 or 2003. Another detailed article talks about that (300684). You'll want to use the fully qualified computer name if you are able. Again, you should re-label any non-compliant domain names prior to the OS version upgrade.

In the Windows 2000 timeframe, we had a situation where if a DNS suffix was defined on NT4 domains, then we made the assumption that you wanted to have your Active Directory domain name use the name assigned in the Active Directory Installation Wizard, but the fully qualified computer name would be based on the DNS suffix that was defined in NT4 (slide 22). This is now resolved, and so you get the intended namespace when you upgrade NT4 domains to 2003.

Going back to legal names, as you define your Active Directory site names, all numeric site names are not allowed and break the Active Directory Installation Wizard. So there's another example of where you want to stay away from numerics.

Andreas: In the following slides we want to give you a step-by-step road map to upgrading your NT4 account domains to Windows 2003 Active Directory (slide 23). So we'll address some step-by-step instructions on that process. The first step that you start with is that you want to check your domain controllers and your domains.

The first part of the check is that you look into the hardware of your existing domain controllers and you find out whether you have sufficient disk space on these machines, if you have enough memory in these machines, if the CPU is good enough to run Windows 2003, and if you have the correct service pack releases on all domain controllers. Hopefully you have Service Pack 6a deployed on all NT4 domain controllers.

Then when you look into the domain names, for both domain controls and domains, the names should be legal DNS names. Otherwise you might run into issues later on. In domains or in deployments where you have a really large SAM database, you need to increase the size of the registry so that the upgrade process, the migration of the accounts from the registry-based database in NT4 to the Active Directory database, will really work smoothly.

After you've finished with the domain controllers, you should also look at servers and workstations. What you should try to find out is whether you have servers or workstations that have services running as local systems. In Windows NT 4.0, when you had services running as local systems, when these services had to connect to other machines over the network, they always used anonymous access to talk to the other machines.

In Active Directory anonymous access is not allowed by default, so you have two strategies. Either you reconfigure all the service accounts to use an explicit user account, and then the access is not anonymous anymore, but it uses that user account for the authentication; or the second strategy is that you decrease the security in your domain or forest by allowing earlier-version access in the Active Directory Installation Wizard for the domain controllers. And by allowing earlier-version access, you basically allow anonymous access to domain controllers. So if you have services running as local system, you need to decide on one of these two strategies.

In step 3 (slide 24), if you use the LMREPL file replication service in Windows NT 4.0 to replicate, for example, logon scripts, or user roaming profiles or mandatory profiles, then you need to configure the LMREPL export service. Typically the LMREPL export service runs on the PDC in the NT4 domain. That is not really necessary from a technology standpoint, but it's usually a convenient thing to do, so that the PDC is the one machine where changes happen, and that's it.

So if your PDC is configured to run the LMREPL export server, then you should reconfigure the service in a way that you should select one of the BDCs to be the LMREPL export server. On that server you should make changes to the files that are replicated between NT4 domain controllers, and that domain controller should then be the last domain controller if you upgrade to Windows Server 2003, or that you remove from your deployment.

The next step in the upgrade process is that you should secure one of the existing Windows NT 4.0 backup domain controllers. The way you secure it is you sync it up with the PDC for the very last time. Then you take the backup tape and you test that you can actually restore from that backup tape. If that test is successful, then you take the PDC offline and you keep it in the storage room, together with the backup tape. Why should you do this?

We have not really heard about any big problems in the upgrade process when PDCs were upgraded, but you never know. You always want to have a plan B in your drawer so that if things go wrong, you can easily roll back into your old NT4 system. If you were afraid that the data in your domain was corrupted by the upgrade process or by an up-level domain controller, then you can always fall back to the old NT4 state by just bringing this domain controller back to your deployment and promoting it to the PDC, so that it becomes authoritative for the NT4 domain. And you need to do this after you've removed all the Active Directory domain controllers from the domain. So there should always be a backup procedure in place here.

In the next step (slide 25) you should look at your existing domain controllers again. First, you should check whether the PDC is really capable of running the Windows 2003 operating system. You can do this by running winnt32 /checkupgradeonly, which is a variation of winnt32 that verifies if the machine is powerful enough to run Windows 2003, and it also checks whether there are any applications or services installed on the machine that would prevent these applications or services from running correctly after the machine was upgraded to Windows 2003.

Then you need to think about the upgrade process. What you have to keep in mind is that while you are upgrading the operating system on the primary domain controller, the PDC will not be able to fulfill its normal PDC role. This means that in a pure NT4 domain you will not be able to create, delete, or make any changes to user objects. You cannot add any computers. Users cannot change their passwords. The same is true for computers; they cannot change their passwords while the upgrade process is running.

So to summarize, you have to plan for some downtime. You have to plan for a freeze in your directory for the time necessary for the PDCs to be upgraded. This typically only takes a couple of hours, so a good way of approaching this is to upgrade the PDC either on the weekends or at nighttime.

After you've upgraded the PDC to the new operating system, the Active Directory Installation Wizard, or dcpromo, will automatically start up. If you upgrade the NT4 domain into the forest root domain in a brand new forest, then the Active Directory Installation Wizard will show you a page in the wizard that will allow you to select the forest mode. So you can go directly into interim mode if you want to. Again, this is something that you should do if you have more than 5,000 members in any of your groups in the NT4 domain.

You can also configure the pre-Windows 2000 – compatible access, which, again, allows anonymous access of services to the directory service to retrieve information.

Another thing that you should think about is setting the NT4Emulator key. The scenario where you want to do this is if you already have clients in this domain that are running either Windows 2000 Professional or Windows XP operating systems.

If you have these clients, and after you've upgraded the domain from a pure NT4 domain, which consists of NT4 domain controllers only, to an Active Directory domain where you have one or more Active Directory domain controllers, then these will only be able to authenticate with Active Directory domain controllers. So they were basically tied onto the existing domain controllers. There's a KB article that will explain in great detail how you should set the key, and what the scenario is where you want to set this.

In the next step of your upgrade process (slide 26) you need to think about whether you need to relax security settings as required. The two security settings that are important for earlier-version client systems, which are Windows 95 and NT4 systems earlier than Service Pack 3, are "SMB Signing" and "Anonymous SID to Name Translation." And you can set these security settings easily through Group Policy objects.

The next step is that you need to verify the domain controller health. You need to look into outbound replication from the NT4 PDC to all the BDCs; that's what you do before the upgrade. After you finish the upgrade, after the PDC was upgraded, you again need to go to the Active Directory PDC Operations Master, which emulates the PDC to the NT4 BDCs, and you need to find out where this can replicate outbound to all the NT4 backup domain controllers.

You need to verify whether authentication and password changes of all clients and users will work in the domain. Can the clients really communicate with the new primary domain controller? You need to verify incoming and outgoing trusts and secure channels with tools like NLTEST, so you need to find out will the PDC now perform the same level of operations and services that the PDC did before? And you need to verify that all clients in this domain and in other resource domains can select and view security principles in the domains.

They basically use the ACL editor to talk now to the new PDC or the new domain controllers, and you need to verify whether the ACL editors are working and whether the secure channels to the domain controllers are working correctly or not.

After you upgraded the PDC — and in those scenarios where you used logon scripts and Group Policy files for NT4 systems — you need to create a service or a system that will also replicate files between the NT4 LMREPL export server and the FRS service on the Windows Server 2003 domain controllers (slide 27). The tool that you use is LBRIDGE. LBRIDGE is a tool that is shipped in the resource kit, both in the Windows 2000 and the Windows 2003 resource kits. You use it to synchronize files between the NT4 world and the Windows 2003 world.

How you set this up is you make changes in the future on the Windows 2003 PDC only in the Netlogon share. And then LBRIDGE will take these files and put them on the LMREPL export server, and from there on they will be automatically replicated to the all the NT4 PDCs.

The next step is, after you've finished upgrading the PDC and making the configuration changes, you can continue upgrading NT4 BDCs. Again, for each BDC you should start by running winnt32 /checkupgradeonly to verify that you can upgrade the machine and that you have no software or services running on the machines that would not run on Windows 2003 operating systems anymore. Again, if you need to use the NT4Emulator key, make sure that you set the key before you run the Active Directory Installation Wizard. Maybe you should evaluate whether you want to set the key while the machine is running on NT4 already.

After the last domain controller in the forest is upgraded to Windows 2003, you can remove all the NT4Emulation registry keys and you can now start switching to the Windows 2003 forest functional level. Again, as we said before, you don't really have to bother about the single domain levels that you have in your domain. After you increase the forest functional level to the Windows 2003 forest functional level, it will automatically increase the domain functional level of all the domains in your forest. So switching to the forest functional level should be your goal, and you shouldn't have to worry about the single domain modes.

As the very last step, you can also remove LMBRIDGE, because after all the domain controllers are running Windows 2003, you don't need that anymore.

Moving on to slide 28, this slide shows you a screen shot of the Active Directory Installation Wizard. This specific wizard page is only presented to you if you upgrade a PDC in an NT4 domain to Windows 2003, and you're running the Active Directory Installation Wizard, and you are promoting this domain to be the very first domain in a brand new forest. Only then can you select the forest functional level, and you have the choice between the Windows 2000 forest functional level and the Windows 2003 interim functional level.

On slide 29 we have a screen shot of the SMB signing policy. Again, if you have earlier-version clients running Windows 95 or NT4 Service Pack 3 or lower, you need to think about setting this policy so that the domain controllers can actually communicate with these earlier-version client systems. As you can see, this is very easy to do. So we created a Group Policy for you, and you just have to disable the settings, and then the earlier-version clients will be able to communicate with your domain controllers. And you have to do this in the single place per domain only, and then this Group Policy is automatically applied to all your domain controllers.

Arren: As you upgrade the various domain controllers from NT4 to Windows Server 2003, there are various upgrade checks that we would like you to do (slide 30). One thing is to make sure that the DC is healthy from the start, and there are several attributes of a healthy DC. The first is that the NETLOGON and the SYSVOL shares exist. NETLOGON you're familiar from your NT4 domains. SYSVOL is a new share that's used to store up-level policy for 2000, XP, and 2003 clients.

Windows 2003 domain controllers respond to more protocols than the NT4 counterparts, so we want to make sure that such machines respond to LDAP, RPC, and logon requests from all clients in the domain.

Windows 2003 domain controllers can be discovered through WINS records, just like NT4 domains could, but they also register themselves in DNS. There are specific records registered by 2003 domain controllers that are very important. There are the SRV and the CNAME records, and those SRV and CNAMEs are registered in the forest group DNS zone, and then A records are registered in each zone for that particular Active Directory domain.

FRS is the new replication engine for the NETLOGON and SYSVOL shares, so good idea is to add a canary file to a particular machine and make sure that replicates to all other domain controllers in a particular domain.

For Active Directory replication we have a utility called Repadmin. A version of this shipped in Windows 2000 and it was greatly enhanced in 2003. The /showreps command is available to test the inbound replication of a specific domain controller. So it's a good idea to make sure that each new domain controller that's upgraded can replicate inbound changes, that it has a connection object, and that its outbound partners can successfully replicate from the upgraded machine.

The event log should have been cleaned before the upgrade, but you also want to check it after the upgrade to make sure things are healthy. We shouldn't see any red or yellow lines in the event log. You may see the event ID 1931, particularly when upgrading 2000 to 2003 upgrades, and you can safely ignore this event.

Andreas mentioned application partitions earlier in his slide, and it's possible to create DNS and put DNS data in domain or forest-wide application partitions. You don't want to do this until all DNS servers in the domain or forest are running 2003.

There are some other post-upgrade installation operations that we would like you to do on slide 31. We just made a backup of the new operating systems, and that voids the backup that existed for the upgraded DCs. So this is a great opportunity to create new backups and mark the old backups to these particular machine names as "old," so that we don't take an NT4 backup and restore it over a machine that's now been upgraded to the 2003 operating system.

In NT4 we had the primary domain controller, which was a single DC designated to create, delete, and modify all objectives in the Active Directory. In 2003 we have additional roles or operations that need to be performed on a single domain controller, and we call these operations masters or use the old term, flexible single master operations, or FSMO. And there is a process where we want to relocate these FSMO roles to an optimal DC. There's a KB article (223346) that discusses this process.

Group Policy is an excellent way to manage your environment, and new tools are coming out in the 2003 launch time frame that will allow you to optimally manage Group Policy across all domains and forests. And it also has an excellent way to back up your Group Policy, which is a very important operation, because we sometimes see this deleted. So we recommend the installation of Group Policy Management console (GPMC) as soon as it becomes available with your 2003 deployment. GPMC can run on XP clients, and it can even be used to manage pure Windows 2000 domains as well.

We found a great deal of misconfigured account lockout settings in NT4 domains and 2000 domains. Specifically, the account lockout threshold is set too low, so you would artificially get a large number of false account lockouts. What we prefer to see you do is set complex passwords, set long passwords, and change them relatively often as a way to protect the user accounts in your forest.

There is a file called Dcfirst.inf that has the settings that we recommend. If you happen to create a brand new 2003 domain, you'll see the settings that we want you to have. One note is that you shouldn't import Dcfirst.inf as a security template; that's not our intention there.

Finally, as you begin to deploy Active Directory, it's extremely important to monitor the events in the event log and the replication status of the domain. We see that this is not happening, and as soon as you don't monitor, you're likely to fail in your deployment.

Andreas has already walked you through the process of upgrading your account domains, and now it's time to take care of the resources domains that are in your organization (slide 32). For the resource domains, the best practice is to create OUs that map to the resource domains that you had in your NT4 environment, and use ADMT, or a similar tool, and migrate the objects, mainly computer accounts, directly into those OUs.

Moving on to slide 33, by now we have a pure 2003 environment and we can start to take advantage of the functional levels that Andreas mentioned at the beginning of the slides. There are certain features that are very interesting for us to see deployed in your environments.

The first is the ability to redirect users and computers. In NT4 you had the Users and Computer container where all users or computers lived, and we had that same paradigm in Windows 2000 domains — and 2003 has those same containers. As you upgrade NT4 domains to 2003, the users and computers remain in these new containers called CN=Users and CN=Computers. And the downside of having these objects in these particular containers is that Group Policy cannot be applied on the containers that are hosting those users and computers. So what we want you to do is get to the domain functional level, or forest functional level, which implicitly means being in a domain functional level, and redirecting CN=Users and CN=Computers to OUs, and then applying policy directly on the containers that are hosting users and computer accounts.

We talked about DNS and application partitions and being able to host that. After all DNS servers in a given replication scope — that is, all DCs in the domain for a domain-wide DNS application partition or all DNS servers in a forest for a forest-wide DNS application partition — are running the 2003 operating system, that is an appropriate time to move DNS into DNS application partitions or to enabling stub zones.

In the third functional level there are other features that we like to see used. First of all, the KCC becomes able to support up to 3,000 sites. That much has been tested so far, and I believe we will try to test 5,000 before it's all over. Also, for branch office deployments, there's a new mode that can be taken advantage of in forest functional levels called KCC Branch Office mode. This is a mode where the KCC builds a hub-and-spoke topology with redundant connections and a staggered schedule between the hub and branch domain controllers.

Slide 34 shows a screen shot of how to advance the domain or forest functional level using the Domains and Trusts snap-in. This is a snap-in where you'll manage your trust relationships in 2003 domains. In the left pane you see a domain matching to each domain in the particular forest, and as you right-click the domain node and select Properties, you'll see an option to raise the domain functional level for each domain. It's a little bit tricky, but if you click the top-most part of the namespace, where it says Active Directory Domains and Trusts in the top-left corner of the snap-in, this is where you can advance the forest functional level.

A little trick is that if you leave all your domains in 2000 native mode then you can advance the forest functional level for the forest, it will transitively increment the forest functional level and the domain functional level for all domains in the forest in one shot.

We've had an opportunity to study the types of problems that NT4 administrators had, as they upgraded to Windows 2000. And there were some paradigms that were quite a bit different from their NT4 counterparts, and there were some things that we learned to do in NT4 domains that maybe didn't apply as well in 2000 and 2003, so we want to try to share that with you in these next set of slides (slide 35).

First, over the course of the operating system, Windows 2000 has shown us that there are fixes of interest that you want to have in place the first time a particular machine boots to a domain controller (slide 36). So install those hotfixes, either service packs or hotfixes directly on top of the original media, and then when you run winnt32 upgrade, all of these fixes are put in place at the right time.

In some case these fixes resolve problems completely. We have a KB article that's listed in the slide that talks about how to overlay service packs and hotfixes on top of the base operating systems so you can get that to happen. As this point we know that there will be an updated version of FRS. It will give you equivalent functionality to what we have in Windows 2000 Service Pack 4, along with some enhancements that are specific to the Windows Server 2003 operating system.

Active Directory Installation Wizard (slide 37) is the installation wizard that allows you to add new Windows 2003 domain controllers to an existing domain, or even create new domains. So this is a little bit different from the paradigm that we had in NT4, when you ran the operating system version upgrade and you had to pick the role of the machine during the NT4 installation. In Windows 2000, you run winnt32 to get the operating system installed, and then you run dcpromo to create the domain controller, either in a new domain, as a replica DC, or in a new forest.

One of the new features you get in the Active Directory Installation Wizard is the ability to create install from media wizards (slide 38). Andreas covered this in great detail. Here's a little more in a detailed article (311078) to help you walk through that process optimally.

Slide 39: the Admin paradigm is quite a bit different from the NT4 domains than in 2000 and 2003. In 2000 and 2003 we have MMC snap-ins, and they're installed as a part of the Active Directory Installation Wizard, and they can also be installed individually on XP and 2003 and 2000 computers by installing a tool called Adminpack. Here I just want to give you a mapping of tools that you're familiar with in the NT4 world, with their Windows 2000 and 2003 counterparts.

The Event Viewer is still the same, and you'll see it under Start, Programs, Administrative Tools. We've taken to where we click the Start menu and choose Run and we type the name of the snap-in directory from the Run menu, because we think it's faster than going through the menus.

The Performance Monitor is still there, but it's now known as Perfmon. For managing the services that you had in server manager there's this new snap-in called Services.msc, or a roll-up snap-in called Compmgmt.msc that contains a lot of common snap-ins for looking at event viewer, managing services, and performing disk management operations.

The User Manager snap-in that you use to create Users and Computers and trust relationships is now called Active Directory Users and Computers, and it's known as the snap-in Dsa.msc. There's a whole new snap-in called the Sites and Services snap-in, and that's where you build your Active Directory site and kind of define the topology that's going to be used to connect different Active Directory sites, and also how frequently those sites are going to replicate with each other.

You can create your own snap-ins if you want by running the MMC snap-in and then adding the specific consoles that you want to make available to yourself.

As far as administration (slide 40), from about the time Windows NT 3.1 through Windows NT 4.0 were released, we had an excellent cross-version administration story, such that any one of those clients could administer any other server very easily. In 2000 and 2003 we have a utility called Adminpack, and the 2000 version of this ships on the 2000 client and server media, and you can install Adminpack from the i386 directory of the CD-ROM.

The 2003 version of Adminpack ships on the 2003 server CD only, and is also available as a Web download for XP clients.

We mentioned that Adminpack is auto-installed by the Active Directory Installation Wizard, and you can manually install this utility by installing Adminpack.msi on XP, 2000, and 2003 clients.

On the interoperability phase we talked about how NT4 had a good interoperability story. In 2000 and 2003, we have some situations where we don't have a full cross-version operating system, so some clients cannot perform administration on some OS versions remotely. We have a detailed KB article on this; it's 311078. Specifically, some tools don't work well on XP clients, like the RAS dial-in tab is missing. And one way to solve this problem is to use Terminal Server to go directly into a 2003 domain controller and then do your administration from that point.

I want to talk about some common tools in different spaces (slide 41). For Active Directory some common tools are Adsiedit and Ldp, and these are kind of Regedit-like utilities for Active Directory. They allow us to see objects and attributes and the relationship between them, and their values that are stored in Active Directory.

Repadmin is kind of the Swiss Army knife for Active Directory troubleshooting, and it's excellent for viewing the replication status or showing some values of objects in Active Directory. Replmon is another utility that's excellent for looking at the replication status of an Active Directory domain or forest. FRS we talked about being the replacement replication engine for LMREPL. There is a set of Perl strips that is now included in CD-ROMs. They are CONNSTAT, IOLOGSUM, and TOPCHK, and they take the output generated by NTFRSUTL. These Perl scripts park that output and give you some pretty useful information. An additional utility not listed on the slide is called SONAR, which is a new GUI-based application that proactively monitors your FRS environment for SYSVOLs and DFSs.

Moving on to slide 42, the Event Viewer looks very much like it did in the NT4 world, except that there are new log types for Active Directory domain controllers. Specifically on machines that are hooked in the DNS service, you'll see the DNS node for an event viewer, and also the Active Directory node. What you may notice is that as you want to view these save event logs from these machines that host DNS, FRS, and Active Directory, you won't be able to do that on non-domain controllers. And there's a KB article that talks about how to work around that issue (235427).

The Active Directory development team did a lot of work enhancing the events through the log in Event Viewer (slide 43). Specifically, new, more detailed events for misconfigurations are now logged, and more detailed steps to resolve a specific problem that's being recorded in the event are now displayed. Here are some specific events of interest that we would like you to add to your monitoring tools so that you can catch those.

One is the 1864 that tells that the Active Directory is not able to replicate for a specific number of hours, days, weeks. It's very important that you keep machines replicating.

Event ID 2042 is also important because it's important for domain controllers to replicate within tombstone lifetime, or 60 days. A 2042 event is logged when a machine hasn't been replicated in that amount of time. So that's a very important thing to avoid or take care of when you see it.

Event ID 1862 is logged when we have domain controllers not replicating between sites. There is a specific misconfiguration where we created Active Directory sites but the site was not in the site link, and we now have a specific event that captures that misconfiguration.

Bridgeheads are machines that replicate the contents of Active Directory between other DCs in remote sites. And it was often possible to select a preferred bridgehead that didn't hold the right information of all the DCs in that site, and we have a specific event that tells you when that's occurred.

Andreas: After you deploy an Active Directory domain, you can start using the organizational unit structure to dedicate access rights to the directory service to specific users and groups (slide 44). What you need to be aware of is that we create two default containers for new objects. One default container holds any new user object and group object that you create using earlier-version applications that are using the old NET APIs. This container is the CN=Users container. We also use that container when we upgrade an NT4 domain to copy all the existing NT4 users and groups into Active Directory. So we copy them into that container.

We have the same concept for new computer objects. We create a default container, CN=Computers. And, again, when you upgrade from NT4, this is where all the NT4 machine accounts go. The default containers that we create are of the object-type containers and not organizational units, so that means that you cannot apply any Group Policies on these containers. That's something you need to be aware of.

When you start creating your OU structure, the first place to start the design is the best practice documentation that we published on Microsoft.com for Windows 2000. There is a white paper called "Best Practice Active Directory Design for Managing Windows Networks," and that gives you a lot of help on how to create your OU structure for delegation. But there are other ways of creating an OU structure.

You always should create separate organization unit containers for the objects that you want to store in these OUs, so you should have separate OUs for your regular user objects; you should have separate OUs for server administrators; you should have one for service accounts, for computers, and so on. So by having these separate OUs you will have more flexibility in terms of securing these containers.

So on slide 45 we give you some hints on how to improve your administration and recoverability story using the OU hierarchy. As we said, policies can be applied directly on containers hosting users, and computers. So whenever you create an organizational unit, you add users, groups, or computers to the OU, you can deploy Group Policies, and for example install applications for these users or computers by using Group Policy.

If you use unique containers for users, workstations, and servers, then this will make it easier for you to restore by object class in disaster recovery scenarios. For example, if the biggest need in a disaster recovery scenario is that users need to be able to authenticate to the network very quickly so that they can get back on e-mail, then you want to restore these OUs first.

What you should do is limit the access to containers for service administrators so that it's going to be harder for them to make mistakes when they delete objects. For example, it's a good strategy to not give any administrators the right to delete OUs and the entire hierarchy under these OUs. If an OU really needs to be deleted, then the service administrator can still go in and change the access control list before he deletes the OU. But if the access control list is set in a way that the directory service does not allow you to delete the organizational units, then you cannot just delete the organizational unit by mistake, which will force you to go through kind of a complex restore process. So by doing that, you avoid these kinds of mistakes.

Another thing you can do is use organizational units to limit the access of administrators to the OU. For example, you can delegate specific access rights to OUs so that some administrators can only reset user's passwords.

Arren: On slide 46 we're going to talk about account lockout. We've made quite a number of enhancements to the account lockout story in 2003 relative to 2000 domains. Specifically, we now have some detailed logging for account lockouts in a SAM logging file, and two new utilities that we want to talk about. As far as a password policy and account lockout recommendations, virgin 2003 domains get exactly the setting that we want to have in place. For upgraded domains, we recommend you take a look at Securedc.inf, and we'll talk bout the tool enhancements here on the next couple of slides.

Slide 47 is a screen shot of the account info DLL tab that you can install when you have the 2003 resource kit. What you see in the left-hand diagram is the Additional Account Info tab — this is a new property page extension for Active Directory Users and Computers — and it shows you the last logon for an account, the last logoff, the last bad password account, and so forth, for a particular user account, when you highlight it in the Active Directory Users and Computers snap-in.

In the top-right corner, when you click Domain PW Info, it shows you the domain password policy for the particular domain that this user is in. If you click the lower-left button, Set PW On Site DC, it automatically discovers a domain controller in the user site and allows you to focus on that DC and set the password specifically on a domain controller in the user site. When this happens and you have the 15-second replication enabled in that particular site, the password becomes very well known to the domain controllers in that domain, and very quickly.

There's a second utility, called Lockout Status. And when it's installed in the System32 directory the Account Lockout Status button in the lower right-hand corner of the property page becomes available. Lockout status is shown in slide 48, and it shows the bad password count for a given user account across every domain controller in the given domain. So it makes it very easy to see where a user is logging on and causing bad lockout events.

Getting the configuration right on the domain controller is half the story. There are also some client-side and server-side bugs. The server-side fixes are all contained in the default Windows 2003 domain controller install. However, there are some client fixes that you might want to have in place. There were several fixes on Windows 9x clients, and we now have a single binary, an updated Windows 9x DS client, that contains all those account lockout fixes. This is the same DS client that makes Windows 95 machines compatible with the SMB signing requirements that we talked about earlier in the slide deck.

Similarly, there are a set of client-side fixes for Windows 2000 machines. Those were all fixed by the Service Pack 3 timeframe, so if you standardized on SP3 or later on those clients, you're taken care of. NT4 and XP clients didn't have any client lockout bugs, so no action is required there.

On the server side, for Windows 2003 domain controllers, no action is required; we think we're set there, with very good behavior. We will have some enhancements that we'll add in future service packs, on XP, 2003, and 2000 clients. However, if you have Windows 2000 domain controllers interoperating with your 2003 domain controllers, then there is a specific set of fixes that we want you to have, and that is Windows 2000 Service Pack 3 plus the QFE 812499, or Service Pack 4 or later would take care of that as well. The reason this is important is that those fixes give Windows 2000 domain controllers account lockout parity with your 2003 domain controllers.

Operations masters (slide 50): you're familiar with the primary domain controller in Windows NT 4.0 domains as a single DC where we create, delete, and modify users, computer groups, and other options. We have now five operations masters in Windows 2003 or 2000 domains. Three of those are held in the domain naming context, and an additional two in forest-wide roles. What we want to talk about here is the naming context, that is schema, configuration or domain naming context, that hold a FSMO role must synchronize before the operations master becomes functional.

Here's what might happen. For instance, the schema FSMO is responsible for introducing schema changes into a forest. For schema changes to be successfully added the schema FSMO must have synced the schema naming context since it was last booted. If it won't, then you won't be able to introduce the schema changes. That same relationship exists for other FSMO roles.

Here's where you're likely to see that problem: if you take production domain controllers that happen to be FSMO or operations master role holders and put them on a private network and boot them up, then you won't be able to perform the operation that that FSMO role takes care of. Similarly, if you take machines that happen to be FSMO role holders on a production network and you use those to build your test domains, you may run into the same problems. So if you're in that situation, take a replica of the naming context that you need for the machine, so that it can take care of that.

One thing that we would also like to see happen is as you make backups of system state for domain controllers that happen to be operations masters, it's a good idea to note some attributes, some set attributes in the backup. So you might note the fully qualified domain name, the name of the FSMO that that particular machine holds, the value for the tombstone lifetime setting in the domain, and the year, month, and date that that particular backup was made.

The FSMO role can be transferred between various domain controllers that are up and running (slide 51), but on occasion you'll have a situation where the FSMO role or the operations master on a particular DC in that machine is somehow not available on the network, or the machine is in some kind of error state — and perhaps it's a hardware problem or a software problem, and you're thinking about what to do about that FSMO role. "Should I transfer the role for when the machine comes back up, or should I seize it because I need to perform some dependent operations?"

The rule is this: certain operations masters must be online. Certainly the PDC is one of those. Other FSMO roles or operation masters are only required when you perform a dependent operation, like the introduction of schema changes on the schema FSMO. So our rule is that for required roles you need to seize the roles for the machine so that you can perform the required operations. For less common operations, like the introduction of schema changes or the addition or deletion of domains in a forest, we tend to seize those roles when we have to do the operations.

Moving on to slide 52, topology is the interconnection of different naming contexts in a particular forest. The goal of KCC is to build a spanning tree for all naming contexts in the forest. There are certain configuration changes that an administrator can make in the Sites and Services snap-in in particular that prevent this from happening.

One is that there is a setting in the Sites and Services snap-in called "Site link bridging." When you enable this setting, and it is the default, it implies that you have IP connectivity between all domain controllers to all the other sites or all other domain controllers in your particular forest. So take note of that if you're in some kind of limited replication or connectivity environment in your enterprise.

All sites need to be in site links. We talked about a new event that denotes that misconfiguration. Be very careful, you can potentially orphan a site out of a site link when you delete site links.

Preferred bridgeheads are machines that replicate Active Directory contents between DCs in remote sites, and there's a way to define a preferred bridgehead. We see numerous misconfigurations where the incorrect preferred bridgehead is selected, or even where a valid preferred bridgehead was originally selected but its configuration was changed, such that it is now not the correct preferred bridgehead to have for that particular site. So be very careful of selecting preferred bridgeheads. Monitor the event logs on the domain controllers in your forests, particularly the ISTGs in each Active Directory site. And if you can avoid setting preferred bridgeheads, then we would definitely recommend that.

As far as KCC scalability, in Windows 2000 the KCC was scalable on the order of about 300 sites. In the 2003 timeframe KCC can support topology for 3,000 or more Active Directory sites (slide 53). There are some other topology tools. One is called ADLB, which is a way of building a redundant hub and spoke with optionally staggered schedules, using KCC-generated connections, and there is a new mode that will be documented in the "Branch Office Deployment Guide" called KCC Branch Office mode.

When you're monitoring your Active Directory, look for event 1311. These are the events that indicate that KCC is unable to build a spanning tree for all naming contexts in the forest.

In the NT4 world there were three naming contexts, you could call them, that were replicated between NT4 domain controllers; they were the SAM, security, and LSA. In Active Directory we have three naming contexts, they just have different names. They are schema, configuration, and the domain-naming context, which is replicated between all DCs in a given domain.

Windows 2000 domain controllers replicated these naming contexts every five minutes between DCs in the same Active Directory site, and every three hours by default between domain controllers and remote sites with a 15-minute minimum. The 2003 domain controllers default to using the 15-second intrasite replication with the three-second offset. That's also true for NT4 domain controllers that are upgraded from NT4 to 2003. Windows 2000 domain controllers replicate every five minutes or 300 seconds until we upgrade the forest to Windows Server 2003 forest mode.

Moving on to slide 55, talking about replication health. In the NT4 world, all changes are made on the NT4 PDCs, so it was authoritative for every change that was ever made in a given domain. In the 2003 and Active Directory world we have a situation where any domain controller can originate a delete, a create, or a modify of an object, and so to allow everything to coalesce, we're relying on transit replication of all changes between all domain controllers on the forest for objects in a given naming context.

So for all the domain controllers to get the right answer, we need to keep them up and running and replicating. So in configuration several things in particular can block the successful replication of these naming contexts, specifically lack of connectivity between domain controllers, such as the blocking of a cord on a firewall, or DNS on a client or the server being misconfigured. Common misconfigurations we see are the domain controllers not pointing to a valid DNS server, or misconfiguration of forwarders for delegations; numerous authentication errors, such as removing requiring access rights for domain controllers to successfully replicate; DCs being offline for an extended period of time; disjoint topologies — any number of things can prevent end-to-end replication.

What we need is for Active Directory to replicate all naming contexts, all domain controllers in the forest for a given naming context, in 60 days or less. This 60-day value is what's called tombstone lifetime number of days, and this is the amount of time in which we need end-to-end replication to occur. This setting is configurable in the Active Directory, but we recommend that you not configure this setting, if possible.

After you encounter machines that haven't replicated in tombstone lifetime number of days, you have some choices about what you do. And the danger of making a machine that hasn't replicated in tombstone lifetime number days is reanimating objects that have been deleted on other domain controllers in the domain, but which this machine hasn't learned about — if it has been more than tombstone lifetime number of days, this particular machine will never learn of the deletions. And we would have inconsistent results between the objects in the Active Directory.

One way to solve this problem is to forcefully remove the machine that hasn't replicated in tombstone lifetime number of days (slide 56). We have a new option called dcpromo /forceremoval, which forcibly removes the Active Directory from that particular machine, and this is discussed in detail in a KB article (332199).

As far as monitoring forest-wide replication, we have some new utilities in 2003 to help you monitor your Active Directory forest. You'll also want to take advantage of monitoring tools such as MOM and its equivalents from third parties.

The new 2003 Repadmin can run on XP or 2003 member computers against 2000 or 2003 domain controllers.

The first command that we like to run is repadmin /replsum, with some optional parameters that we're showing on the example. This provides a forest-wide replication check, and it tells you the last time a particular machine replicated inbound changes. For details, an examination of replication status, do the same command, repamin with the /showrepl switch, and a *[/csv] parameter, viewed in Excel, is a great way to view the replication status in a more detailed way.

Next we want to talk about lingering objects (slide 57). Lingering objects are objects that have been deleted from a particular domain controller and that still exist on a writeable or read-only NC and another domain controller in the same or a different domain. The cause of lingering objects is lack of end-to-end replication in tombstone lifetime number of days. And again, this could be due to replication errors or a misconfigured topology.

One thing that helps avoid the spread of lingering objects is strict replication mode. Strict replication mode is a mode that says that when a domain controller receives an update for an object for which it doesn't hold locally, that replication is blocked for the naming context that held that object. Strict replication mode is the default setting for 2003 forests that are created new, and it's also the default for NT4 domains that are updated to 2003. So any NT4 domains that are updated to 2003 will receive this mode.

Here are some examples of how you might get to lingering objects (slide 58). We have three examples, three diagrams. The first, we have three DCs: DC1, DC2, and DC3, where DC3 is experiencing some replication failures from DC1. But he also has an alternate replication path of DC1's changes through DC2 in the left corner. So in this case DC3 hasn't replicated to DC1 in greater than tombstone lifetime number of days, and the question is, do we need to force demote DC3? The answer is no, because we have an alternate replication path of DC1 changes through DC2, so we can keep moving.

In the second example we have the same set of domain controllers: DC1, DC2, DC3, and here DC3 is completely orphaned of all changes from DC1, and it doesn't have the alternate path of getting DC1 changes through DC2 — so this machine is a candidate for forced demotion. Our rule is where the pain of losing the changes that have been made on DC3 are worse than cleaning up the lingering objects that we're going to reanimate on DC1 and DC2, we use that as a guide for what we should do.

If we can afford to get rid of DC3 because there are additional domain controllers in that naming context, then DC3 is a candidate for forced demotion; if it's not, and we leave it up, then we clean up the lingering objects using some tools that are included in 2003.

The last example shows two groups of machines where replication is fully functional in both groups, but we don't have end-to-end replication between the DCs in site link ABC with domain controllers in site link DEF, and so you can't use the replication status and Repadmin and other tools like it to say that you're completely healthy. In this case, event ID 1311 would be logged, telling you that KCC couldn't build a spanning tree.

Slide 59 shows the output from the repadmin /replsum when you use the 2003 version of Repadmin. Again, this runs on XP and 2003 clients, and can be used against 2000 and 2003 domain controllers. There are six columns that are built by the repadmin /replsum output.

The first is the domain controller that we're replicating changes to and from. The largest delta column shows the least current naming context on that particular machine in day, hour, minute, and second format. Next is the number of failing connections that that machine has, then the total number of connections, inbound or outbound, that the particular machine has.

The percentage column is the number of failing connections on that particular machine. And finally, we see the error code that that particular naming context is failing with. The output of Replsum can be sorted by any one of these columns. The most useful columns to sort by are the DC names, the largest delta column, or the error message, so you can troubleshoot like problems.

Here we see the output is changed a little bit, so we're using a /sort: delta to get the sort. And awe use by source (/bysrc) and by destination (/bydest) switch so that we can view all DC replication status, and we can tell which machines are having trouble replicating inbound changes, or which machines are being pulled from and experiencing replication failures. At the bottom of the list are the machines or the domain controllers that we couldn't contact, and those should also be investigated.

There are some other switches in Repadmin that are useful (slide 60). We talked about repadmin /showrepl [*/csv]. The asterisk is significant because it represents the ability to define wild card for the commands that REPADMIN should focus on. If we use the asterisk switch, then we run that particular command against all the DCs in the forest. You can also use these wild cards, like RED-DC-*, to target domain controllers in a similar domain.

I'm going to talk about some paradigm changes between NT4 and 2003 specifically (slide 61). Here we have the NETLOGON SYSVOL shares. NETLOGON you're familiar with; SYSVOL is new. NETLOGON was responsible for storing legacy profiles and policies for NT4 and Windows 9x clients. The SYSVOL share is a special kind of DFS, and it's used to store up-level policy for 2000, XP, and 2003 clients. The SYSVOL shares must be shared or enabled for domain controllers to advertise. There is a registry key that allows you to force-share the SYSVOL on a particular domain controller, and we recommend that you do not do this.

Some common problems that we had were that locked files would prevent replication of all the contents of SYSVOL, and we recommend the deployment of the updated version of SONAR and the QFE which can identify these locked files for you, so that you can break the lock and allow replications to continue.

Another problem that we had is that when SYSVOL wasn't replicating smoothly, administrators would sometimes intervene by copying duplicate data to multiple domain controllers. Do not do this, because you'll cause problems. Specifically, when replication is enabled again, we'll get these conflicted directories and files and so forth, which is not good.

Finally, the SYSVOL contents are not suitable for dynamic user data like profiles or other content that is locked for a long period of time, because it causes problems with replication. Any replication tool would have the problem where it's unable to break the lock on a file, and so it's best if you avoid that type of dynamic user data.

The Group Policy engine is quite different in Active Directory domain controllers (slide 62). In fact, there are two replication engines for the Group Policy. A portion is stored in Active Directory and replicated between domain controllers in the domain. You can see this in the System folder of Active Directory Users and Computers. Then there's also a file system portion of your policy that gets replicated by the FRS replication engine.

There are two tools to modify the policy. They are GPEDIT and GPMC, and we recommend that Group Policy be managed with GPMC. Both of these tools default to making all changes on the primary domain controller. That's a default. And it's a best practice to update all your policy on a single DC, even if you use other clients to do it. You just want to leave the default to the primary domain controller, otherwise you get a situation where User1 is making changes on one particular DC; User2 makes his changes on a second DC; and it's a "last-writer-wins" kind of reconciliation, so User2's changes, which were made later, are going to win over the changes that User1 made.

Andreas talked about redirecting users and computers, and that's also a best practice because we can apply policy directly to the containers that are hosting those objects, otherwise you have to apply policy in a parent-naming context, and you have to use complex ACLs to restrict containers those particular users apply to.

In the interest of time and getting to Q&A, I'm going to move through these slides quickly. FRS (slide 64): we had some problems in Windows 2000 caused by move-in bugs that were in the service itself; sharing violations still exist. Those have all been fixed, but I want to talk about three things to avoid with FRS.

One is that we had problems with either virus scanners or disk-scan utilities running through the FRS replicated content and modifying it in such a way that it caused a full sync of the data every time that the utility was run. We have now made changes where if FRS detects a modification to a file that was just like the previous modification to a file, then we don't replicate the outbound change, and we log an event telling you that excessive replication is taking place in the environment, but that we're not going to replicate these outbound changes. Still, you need to investigate compliant antivirus and disk scan utilities, and there's a KB article (815263) on that topic.

Second, security policy, including some security templates written by Microsoft, will ACL file system content. And if these security templates apply to replicated SYSVOLs or DFS content replicated by FRS, then it will cause a full sync of that data every time those security templates are applied. This is not a supported situation, and you can't do that.

In NT4 domains it was extremely common to delete critical objects like machine accounts, NT4 trusts, and so forth (slide 65). And both PSS and customers got to the point where if we had a problem with these objects we would simply delete them and re-create them, and we often met with immediate success.

In Windows 2000 and 2003 these should be treated as critical machine objects, and you should not delete them, because they're very difficult to get back. Specifically, domain controller accounts are extremely difficult to get back and should not be deleted. Similarly, the intra-forest trust relationships between different domains in a forest are objects that should not be deleted, and we can't think of a valid scenario where deleting them and trying to re-create them even helps you.

The NTDS Settings object is a parent container for connecting objects in the Sites and Services snap-in. Again, this should only be deleted from machines that are being removed from the forest and never coming back. And there's a better tool for doing that, so we recommend that you use that instead.

As far as some tips and tricks, initial synchronization requirements — pay attention to FSMOs and the initial sync requirement for the naming context before those FSMO role functions, particularly on DCs in a lab environment or that are booting on a private network.

Global catalogs have a new requirement where they synchronize all naming contexts in the forest, unlike Windows 2000 counterparts, if you were familiar with that. So it could add additional latency between the advertisement of the global catalog, and you need to, of course, have a DC from every domain in the forest available so that the synchronization can take place.

It's extremely important to monitor the replication status of all DCs in the forest and avoid having machines not replicate in tombstone lifetime number of days; that is 60 days, which we think is a reasonable time to either fix or demote the machines.

XP and 2003 are becoming the management platforms (slide 67). The advanced tools like REPADMIN, GPMC, resultant policy, and the 2003 admin pack all run there, so that's where you want to get your administration group standardized, if you can. There's a special process for adding NT4 domain controllers to your 2000 and 2003 domain controllers. You cannot simply use the User Manager to create the account for an NT4 BDC. You can use an updated version of User Manager, or you can use the Netdom utility to create these accounts. There's a KB article on that.

Remote administration is enabled on 2000 domain controllers by default, so you don't have to go into Control Panel, Add or Remove Programs to enable Terminal Services like you did in 2000. But you do need to right-click My Computer and enable Remote Desktop access through the Properties menu, so that behavior is a little bit different.

At this point we'd like to take questions.

Otto: Thanks for the presentation. In the interest of time I'll try to move through these questions as quickly as possible, while maintaining as thorough a flow as possible.

If any of the details on the PowerPoint® slides were difficult to view in your browser today or you would simply like to have a copy of the slides, they will be available for download within 24 hours of the show's end, as will our on-demand streaming archive. Also, we plan to have a full transcript available to you within about three weeks' time, and all that content is going to be available on the Web site, support.microsoft.com/webcasts.

The first question that we have: Domain migration with ADMT or the Windows Server 2003 equivalent, was that something you addressed during this presentation? Or in-place upgrades?

Arren: It was not our intent to cover that, but ADMT v2 does ship in the i386 directory of Windows Server 2003 media.

Otto: Does 2003 have a way to take over the PDC emulator role without doing an upgrade to the existing NT4 PDC, as if the existing PDC hardware is unable to perform the job for 2003?

Arren: It does not. The upgrade process is the same at is was in 2000, where you upgrade the NT4 PDC first, so I guess there are a couple of things that you could do. One would be to take new hardware and install NT4 as a BDC in the existing domain, transfer the PDC role to it, and then do an OS version upgrade on that particular machine.

You could also take the NT4 PDC, run an OS version upgrade on it, and now add a new 2003 replica DC of it. Then transfer the PDC over to the new machine. And if you wanted to sacrifice the original NT4 PDC, you could.

Otto: How many users per group are supported with the 2003 server functional level?

Andreas: We have started testing that. I think that the maximum number of users in the group that we created in the test environment was 2 million, and then we just stopped testing, because testing took too long. We don't really have a maximum number right now; it's just going to be huge.

Otto: Did I understand correctly that Windows 2000 Active Directory servers will not coexist with 2003 Active Directory servers?

Andreas: No, that is wrong. Windows Server 2003 domain controllers can perfectly coexist in a Windows 2000 forest or a Windows 2000 domain. So they can basically behave in the same way as Windows 2000 domain controllers. In fact, when you start the upgrade process from Windows 2000, you can do this by just adding Windows Server 2003 domain controllers to your deployment.

Only when you want to start using additional functionalities that would not be understood by Windows 2000 domain controllers anymore do you need to raise what we call the functional levels. And then, if you raise the functional levels, we would not support Windows 2000 domain controllers anymore. You can do this at your own pace. So you can start by adding Windows Server 2003 domain controllers to your existing Windows 2000 environment, and just upgrade domain controllers step by step and so on. So we will be fully compatible with the Windows 2000 domain controller.

Arren: In the functional level section of the slides, there are four modes: native, mixed, domain functional level, and forest functional level. Windows 2000 domain controllers interoperate in the mixed and native modes just fine, and they are restricted or orphaned in the 2003 domain and forest functional levels, where we introduce the new 2003 features.

Otto: I take it there's no way to create a PDC emulator within an existing NT4 domain without actually upgrading the NT4 PDC?

Arren: Correct.

Otto: Do you still recommend dedicated account domains for Windows 2003 forests?

Andreas: No. In Windows NT 4.0, there were two reasons for having dedicated account domains and resource domains. Reason one was the scalability limit of NT4 for the directory, so you basically couldn't have more than 40,000 user group and machines accounts in the same domain.

Reason two was we didn't have good delegation functionalities in Windows NT 4.0. So if you wanted to make somebody an administrator on a specific set of servers, you basically had to make him administrator of the domain. So many people created NT4 resource domains to delegate the access rights for NT4 systems in that domain.

Both reasons do not exist in Active Directory anymore. Your domains can be really, really large. Our largest deployment has 8 million users in a single domain today, and you can use the delegation functionalities in or on the organizational units to delegate rights to the OUs, to the objects in the OUs, and to find and print servers that are shared to the OU. So we don't recommend creating resource domains anymore.

Otto: Are there any issues with upgrading Windows 2000 DCs to 2003 first, before NT4 DCs to 2003?

Andreas: No, you can perform the upgrade process in any order that you want.

Arren: The same security issue that we talked about, SMB signing, anonymous access, anonymous LDAP access, those still apply, but nothing special.

Otto: Can you expand a little bit on what malicious administrators in other domains could do to harm the greater good of the forest?

Andreas: When you say a malicious administrator, I assume that you mean a malicious service administrator, who is a domain administrator in any domain in the forest. If this person is really malicious, that means that he has really bad intentions, so he would theoretically go to any length to create tools or put domain controllers into the debugger or to use a disk editor to attack the files and so on.

In those scenarios the malicious service administrator can basically do anything he wants to in the forest, and that includes the directory service. So he can restructure the directory service to anything he wants to. He can access any object in the directory service. He can delete objects and create objects at random. But he can also access any resources from any workstation or file server that are shared through the domain. Quite frankly, a malicious domain administrator or service administrator can do anything he wants in the forest and on any machine that is joined to the forest.

Otto: I want to upgrade a single-server BackOffice® Server 4.5 with SQL, SMS, ISA, and Exchange to an ISA server, Exchange server, Web server, and file/print server and then turn off the old server. What should I do to prepare for a single-server to multi-server 2003 conversion? And is there any documentation that can help in this, especially based on what types of service packs are required for the application servers, etc.?

Arren: None that I'm familiar with. It's probably worth talking to the support group that owns that. I would recommend self-hosting that upgrade in a lab environment prior to the upgrade of the production machine.

Otto: Can you create a domain on a cable network? I'm not sure exactly what they're referring to there, unless it's a non-LAN environment, more like a cable modem situation. Perhaps we can get a little bit more clarification on that question.

Arren: Is the question, perhaps, can you replicate Active Directory, or can an Active Directory domain or forest replicate over machines that are connected by cable modem?

Otto: That sounds pretty close.

Arren: If the required ports needed for Active Directory and other services on the domain controllers are enabled, then that can work.

Otto: If that user needs to clarify, send it on in. Hopefully we will be able to get to it.

Arren: Adding to that, I would say there are specific challenges to replicating over in NAT environments, and that's probably beyond the scope of today's conversation. Our networking team would be more familiar with that, but I know there are enhancements to working with NAT in 2003, also.

Otto: NT4 is currently our network structure, with Windows 98 as our main clients because of legacy MS-DOS® applications, and we're curious what happens to our Windows 98 clients profiles? And further, what about the few NT4 workstation and XP Pro workstation profiles?

Arren: No change on the profiles. Windows 98 machines will continue to get their profiles. Presumably they're on a profile share, perhaps on the legacy Netlogon share. So no problems there. We talked about how during the initial cutover from NT4 over to 2003 we needed some type of bridge between the FRS service that replicates content on the Netlogon share of Windows Server 2003 domain controllers and the export server of the NT4 domain controllers to make the contents of the Netlogon share on those machines consistent. So there's no change there.

Similarly, with XP Pro machines and their profiles, there is no change. This is an attribute of the user account that's telling the client computer to connect to the specific share for the profile, there's no change there. For NT4 machines, there's no change there either.

I think there is an issue where if the same user account transitions to machines of different operating systems, like XP and 2000, for example. Then there's a difference in the profile format, and there's an issue there. I think the recommendation is not to transition between OS versions in that scenario. But for the scenario specifically mentioned, there are no issues.

Otto: In Windows 2003 domains, will you be able to run as another domain user while logged on already as a domain user? Or will you get the error that the supplied credentials conflict with the logged-on credentials?

Arren: There's a run-as command that can be launched from a command prompt. We can be logged in as a domain user and we can do a run as, and either launch a command prompt in the context of another user in the same or a different domain in the forest, or even an external user, and every tool that is launched out of that run as context CMD window receives the context that the run as menu was started under. Or we can run as the specific snap-in in the context of a second user, perform our operation, and exit.

So one intention of that is to allow delegated and privileged accounts to use a non-privileged account for their day-to-day work, and then do a run-as in the context of their privileged account to perform some administrative functions, and then close it out, and limit the window of opportunity that they're running in the advanced context.

Otto: Can GPMC run on a Windows 2000 client?

Arren: It cannot. It can run on Windows XP SP1 with a QFE, or Windows 2003 member computers and clients against 2000 and 2003 domain controllers. A great effort was made to see if it could run on 2000 computers, and it cannot.

Otto: When migrating and not upgrading from NT4 to 2003, ADMT doesn't migrate built-in groups. How would you provide access for built-in groups from the new domain to resources in the old domain that has permission set for those groups?

Arren: You could investigate the Security Translation feature, and I believe David Rheume did a WebCast in the October time frame on that topic (http://support.microsoft.com/default.aspx?scid=/servicedesks/webcasts/wc102902/wcblurb102902.asp).

Otto: Do you still recommend having at least one domain per site? Has domain replication been improved enough to span domains across sites?

Arren: Domains could span sites in the 2000 time frame, and that was very common. There were branch office deployments with 1,000 domain controllers in a single domain and in as many sites. So 1,000 DCs and a 1,000 different Active Directory sites were certainly done, and so that worked.

As far as having a domain controller in each site, it's your call. Certainly sites with a certain number of users justify having their own domain controller, and the other question is how you feel about the reliability and the speed of the connection between a given site without a GC and perhaps a hub site where these users would connect to and authenticate against.

If you feel that that pipe is reliable enough and fast enough to satisfy the interactive traffic associated with the user performing day-to-day operations, then you're welcome to not put the domain controllers in a site. Certainly, after you exceed a certain threshold, a collection of users in a given location, it justifies having a domain controller in that site.

But I know that some customers investigated having a large hub of sites, perhaps 30 or 40 in a single site in a hub, and no domain controllers in the client site, and doing all the authentication and so forth over the network.

Otto: Will any of this change if my NT4 PDC is also Exchange 5.5 and Web server?

Arren: No. I don't focus as much on the Web piece of it, or not at all, and I know that, at least on fresh installs, IIS is not installed or running as part of the default installation. So that part should be investigated. But I haven't studied that part. But for the rest of it, there is no issue.

Otto: When upgrading an account's domain in a master domain structure to Windows 2000, can you change the domain name?

Arren: One of the features that's available in the Windows Server 2003 forest functional level is the ability to rename a domain. So in that mode you can rename the NetBIOS domain name or the DNS domain name. So the answer is yes, after you get to that mode.

Otto: Will the DCs cache upon logins, as well as universal groups?

Arren: Yes. There is a feature called Universal Group Caching, and there is some detailed information about it in the online documentation. Universal groups and global groups are cached when that feature is enabled on a per-site basis. So you can avoid having a global catalog server in every Active Directory site.

Otto: I have a bunch of Windows 2000 servers on a Windows NT 4.0 domain, and we're curious as to what the best way to upgrade is. Will all my NT4 domain groups and users be converted to a new Active Directory?

Arren: Yes. As you upgrade the NT4 primary domain controller to a 2003 domain controller, all the users, computers, groups, and group memberships will be maintained in the new Active Directory domain. And it will also replicate changes between the 2003 domain controllers and the NT4 BDCs until all the NT4 BDCs are upgraded.

Otto: I've heard that if you have a Windows 2000 domain and you upgrade a single DC to Windows Server 2003, all XP and 2000 machines will use the 2003 DC for authentication. Is that correct?

Arren: Yes, after a fashion. Windows 2000, XP, and 2003 clients will only use a 2000 or 2003 domain controller for authentication after they've been discovered, and it's for that reason that we're using the NT4Emulator key in the registry of new 2003 domain controllers that we add into the environment. And that same setting works on 2000 domain controllers.

With that setting in place, 2000 and 2003 domain controllers appear as NT4 domain controllers to XP, 2000, and 2003 clients. They don't upgrade the secure channel, and they can be authenticated by any NT4, 2000, or 2003 domain controller in the domain. But the problem is that if that registry is not set, then after these clients discover an up-level domain controller, they will never revert back to being authenticated by an NT4 domain controller in the domain.

Where you're vulnerable is where you've upgraded the first NT4 PDC to a 2003 PDC. In that window of time, or the time when we have only a handful of 2003 or 2000 domain controllers in the environment, these clients are being authenticated by a small handful of machines and they're potentially overloaded. But with the NT4Emulator key in place, you have no issue.

Otto: We're running down to the last few minutes. I'll see if I can get through as many of these remaining questions as possible: If I have native 2000 domain groups with more than 5,000 members, should I do something with them before upgrading to 2003?

Arren: That's a good question. The answer is, it depends. If you upgrade those 2000 native modes to 2003, you'll be in native mode. The group membership story doesn't change until you get to 2003 forest functional levels.

After you do that, then we get the official replication for all additional users added to the group, so you're in good shape. You may still be vulnerable to out-of-version-store problems when you bulk delete such a group, because we now have the enhanced replication story for the groups added after the 2003 forest mode transition, but we still have the legacy group members prior.

So one thing you could do, if you wanted to, is remove all the members of the group after the 2003 forest functional level transition, and then add them back in. But if you're not going to bulk delete these things, then there's no requirement to do this.

Otto: Is there any good reason to have a root domain if we go directly from NT4 to 2003?

Arren: It's your choice whether you want to have that in your structure. A number of 2000 deployments use an empty root domain, and political considerations about the handling of the schema ownership may dictate that to be a good design structure for you.

I know that Microsoft used an empty root domain and they now would have rather not had it, because it took maybe three, four, or five machines to provide enough fault tolerance for the forest root, and they would have rather had user accounts in that domain. I think there's even a plan to investigate collapsing existing account domains and move those objects into the root. So if you don't mind burning about five machines in a large deployment, then there's nothing wrong with it.

Otto: Will Windows 95 clients, with no DS client, have problems logging on to a 2003 domain?

Arren: Windows 95 clients, without the DS client, will not be able to authenticate against a 2003 domain controller until either of the two DS clients is installed — the one that ships on the 2000 CD or the new updated one that's referenced in the slides — or until you relax the SMB setting in Group Policy, in the default domain controllers of each domain in the forest. So it's an either/or kind of thing, and we the relaxing of the setting as temporary, until you can get the DS client fully deployed on all your clients. So relaxing the setting effectively makes the 2003 domain controllers behave as 2000 domain controllers.

Otto: Is it still necessary to create a separate MSDC zone in a forest and create a secondary zone in the sub-domain's DNS?

Arren: Good question. The MSDC folder is automatically created in the forest root, and in 2003 it's actually its own delegated zone. And when you have DNS running in forest-wide DNS application partitions, you can now host the _DCs zone on all DNS servers in the forest. So you do not need to create the secondary anymore. The best practice to use is to use forest-wide application partitions for MSDC zones on all DNS servers in the forest.

Otto: What registry key area are you referring to regarding Win 9x, NT, 2000, and XP authenticating against 2003?

Arren: It's not a registry key, but rather a policy setting. There's a long article on this (325379). I don't know if it's mentioned in this particular deck, but it's about 28 pages, and it talks all about the security settings. It's written for upgrading 2000 domains to 2003. In the screen shot (slide 29) you can see the path for that particular security setting. So if you start the Users and Computers snap-in, right-click the Domain Controller's OU, you can edit the default domain controllers' policy and follow the example in that particular slide. You'll see the exact setting. It's Enable SMB Signing. And that setting needs to be cleared.

Otto: If I have to roll back a Windows 2003 DC upgrade from an NT4 PDC, is there an easier way to reset existing Windows 2000 or XP clients to the previous domain authentication models, because they changed their authentication to Kerberos?

Arren: If you used the NT4Emulator key, then those clients did not upgrade their secure channel. So if you followed the guideline to use the NT4Emulator key prior to the introduction of each 2003 DC on the network — one way to do that is to run the Active Directory Installation Wizard and then reboot before the dcpromo — set that key in the registry, reboot, and you're in good shape. Then no action is required.

If the key was not set and XP, 2000, and 2003 clients upgraded their secure channel, then you need to delete the machine account and rejoin the domain. And that could be done remotely using Netdom or a similar utility.

Otto: This is the final question that we'll be able to address today, simply based on the amount of time that we're allowed: If I have all Windows 2003 DCs, will network boot disks that require NTLM work? And if not, do you know how we can get them to work?

Arren: There's no change for those clients. Yes, they will still work.

Otto: We've run out of time and have gone a little bit over, but we've answered all the questions that we were able to get to in the amount of time that we had for Q&A.

I'm going to wrap up the session. I hope that this information was useful to you. I wanted to thank our presenters for coming out today and giving us a great presentation and a lot of really good information.

As always, you can e-mail us at supweb@microsoft.com if you have any suggestions for future topics or comments about the shows or the WebCast program as a whole.

Thanks again. Good-bye.