Provide Feedback on this Broadcast

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

Heidi Moeller: Hello, and welcome to the Microsoft Support WebCast Program. We’d like to thank all of you for joining us today. Our topic will be Directory Services. This is Part Two. The first part of this session was on January 13, if you’re interested in the archives on that.

Our presenter today will be Paige Verwolf, and I’m Heidi Moeller. I’ll be your host for today’s session.

We’ll start this session with Paige’s presentation and follow that up with a Q&A period. This is going to be a fairly long session. We’ve got 60 slides to get through because there is just so much information.

You should see a Message Center to the right of the PowerPoint® slide from which you can submit your questions. We are going to hold off on answering those questions until the presentation is finished. However, I would encourage you to send your questions any time during the live event. We only take questions during the live event, so it’s a great time to ask these questions.

I’d like to introduce Paige. Paige Verwolf is a Systems Support Professional. She is currently working on the Windows NT® Domain Team. She’s been working in the computer industry for the past four and a half years, the last two of which have been with Microsoft.

Thank you for joining us today, Paige.

Paige Verwolf: Thank you all for joining us. As Heidi said, this is a long presentation, and we will be discussing some of the most important topics that Ben talked about in Part One in more depth. We’ll start today with "Domains."

Domains consist of one or more domain controllers. This is very similar to 4.0, where we had different domain controllers in our domain. There are some differences. We’ll talk about that in a moment. Each domain controller in a domain is going to host our Active Directory™, and our Active Directory file is going to be called Ntds.dit. Those of you who have installed it and played with it may have seen this file. And the file is going to consist of three naming contexts, and these are going to be our replication boundaries. Our domain naming context is one of them; we also have a configuration, and a schema, as depicted in the slide. Again, it’s really important to understand that each domain controller hosts this directory.

The schema and the config are enterprise-wide, so every domain controller in your forest is going to hold these two naming contexts. Domain is a little different, because it’s specific to each domain in the forest. You may have five domains, and each domain controller, depending on which domain they reside in, will hold their own database. And in this database you might find things like users, shared folders, groups, computers — all these things will reside in that domain naming context.

Now, the configuration naming context, again, this is forest wide, is going to hold information about the relationship of this domain to all other domains in the forest. Things like sites—and we’ll talk about that later today—will be held in the configuration container.

Finally, we have the schema, and in Directory Services Part One there was some discussion about the schema. We have learned that the schema defines what can be held within our directory. We use classes and attributes, and we can define what can be created in our directory.

Because of this, and the fact that we are able to make changes on every domain controller in our forest, we use something called multi-master replication. Multi-master means that all domain controllers hold a fully writeable copy of the directory, and they can update it. This was different than in 4.0. As you are all familiar with, in 4.0 we had a PDC/BDC model where the PDC was the master, and unless that PDC was up, we were unable to make changes. In this particular model it works much better because we can make changes to any domain controller. The only thing we have to take into consideration now is how our replication is working to make sure we’re up to date. And so today we’ll be discussing a little bit more about replication, and some about sites, as well as some other topics.

Going to the next slide, we’re going to talk about our domain trees and forests. We talked about our domain, and that’s the first entity. We bring up a domain controller and we create this domain, which in essence creates our first forest and our first domain tree. As you DCPromo another domain controller, we can create trees and other domain trees in the forest.

Let’s talk about a forest. A forest is a collection of domains that can be configured to interoperate together. Each domain will contain its own domain databases—this is really important to understand that concept, that each domain has its own domain database. Every domain controller that resides in that domain holds that database, and only database.

What we want to do, basically, is replicate information across the entire forest, though. Because we actually need that configuration in the schema partition of those directories to go across the whole forest, and then we need to keep all the domain directory information in with all of the domain controllers in that domain. As you can see from the picture, you can see where each domain has the common schema and common configuration, and that they each hold their own unique domains database.

New to Windows 2000, we also have what we call transitive trust links. If you all remember in 4.0, we used to have to create these explicit trusts, and for every trust we wanted to create we had to create them on both sides, and get the trust created in order to be able to communicate between domains. This has changed. When you bring up a new domain in your forest, it automatically has a transitive trust to its parent domain, and that allows for communication. This doesn’t mean they automatically get access. We still have access control lists, just as in 4.0, but these trusts are necessary in order to get that communication channel.

We’ve reduced the administration. Now, when you bring up your entire forest, for all Windows 2000 domain controllers in our Windows 2000 domain, we have fully transitive trusts throughout the entire forest, which means that we’ve basically set up a complete trust model with none of the administrative work.

In 4.0 we used to have to set up the trust model by creating trusts to every domain in the forest, because when you went A trust B — domain A trust domain B, and domain B trust domain C, but A and C didn’t trust each other until we actually established the trust link. Well, this has changed. We have transitive trusts now so that A does trust C without having to set up that trust. And this has really reduced the amount of trusts we need to set up. In fact, we don’t have to set up any, because it’s done automatically for us. The only time we’d have to set up a trust is if we have down-level domains.

We still have explicit trusts available for down-level domains and domains outside of our forest, but if you’re using a peer Windows 2000 forest — one forest with all Windows 2000 domain controllers, we can let the transitive trusts work for us.

Let’s go to the next slide and talk about domain trust administration. This is pretty important to understand, how this gets created and what we can do with this trust administration.

We talked about installing Windows 2000 domains, and we create this parent-child trust. Once we add a domain into an existing domain tree or into an existing forest, this trust is established for us. Every domain will have at most one parent, and they have multiple child domains. We also have things called cross-links for frequent resource access. What we can do is if we have a large tree, we can create cross-link trusts to give us easy access to that domain controller without having to walk the entire tree. I think Ben discussed that in Part One, and I just wanted to follow that up and make sure everybody understands what the cross-links are for.

When defining explicit trusts for other domains outside the tree, we can actually use that 4.0 style that I talked about. They’re called explicit, and we have to set them up. It’s not done automatically for us. And we can do this: let’s say our company acquires another company, and we bring in this domain that’s not part of our forest, and we don’t have time to migrate it; we can actually create this explicit trust. We can also do so with down-level domains. If we have a 4.0 domain, then we can go ahead and create the explicit trust. If we go to the second slide, which is a continuation, I wanted to add that these are non-transitive. And if you set up explicit trusts, they’re not going to be transitive, so you will need to set them up for each domain that you need to talk to.

Let’s go to the "Domain Trust Relationships" slide where we can see how this all works in a real-world type scenario. Here we’ve got a domain tree, and it’s a tree that in one forest has two layers on each side. We’ve got six domains in our forest. And since we installed these we have got our transitive trust links, and you can see those depicted as the dotted line that goes between the domains. And it’s bidirectional. We don’t have to set them up. And they’re transitive. Every domain controller now has the ability to talk to every other domain in the forest.

We also have what we were talking about, the cross-link trust. At the very bottom you can see where the two bottom domains needed to talk to each other. We set up a cross-link trust, and so this will speed up frequent resource access that we might have in one of the domains.

I also show where we’ve got explicit or 4.0 style trusts that we’ve set up, and I show where there’s a down-level domain. We set up an explicit trust that way, so we can talk to that down-level domain. And then we’ve got a domain that’s outside of our forest, and maybe we acquired it through an acquisition, and we can set up a trust that way to a specific domain.

Now, remember, it’s not transitive, so when we talk to that one domain, we can only talk to that domain. If the domain outside of the forest needs to talk to all domains, we’d have to set up a trust for every single domain. It’s much easier to have all your domains contained in one forest and have these domains be Windows 2000 domains. Then our administration is much reduced.

Let’s go on to the next slide, "Domain Boundaries." Domain boundaries are important to understand because we have to decide, sometimes, when do we want to have a single domain as opposed to multiple domains. In many cases, companies are able to use a single domain model, and it’s going to work fine for them. In other situations it’s not going to work fine, and they’re going to need to create multiple domains. When we think about boundaries for domains, we need to think about replication, administration, security, policies, and group policies.

Just as in 4.0, we had quite a number of different domains because one administrator wasn’t allowed to look after users in another domain. In Windows 2000, we have this delegation model that I’m going to show in a little while, where we can use organizational units to separate departments and allow for administration of one department to be overseen by one IT group, and another department overseen by another IT group.

The only thing about this is that sometimes there are such political issues that we’re not able to do this, because we still have one central domain administrator who can ultimately control these organizational units. But, in a situation where we have a central IT department, and we need to have departments controlling their own departments, with a subordinate IT department, we can actually use organizational units. That’s a big plus for Windows 2000, the ease of administration and the granularity. And we’ll be able to see that momentarily.

I’m not going to talk about group policies or security policies today. That will be covered later. I just wanted to make a note that both security policies and group policies can be applied at the domain level, so there really isn’t necessarily a need, unless you really wanted to separate them out for those reasons. But, that’s one boundary we have to think about—how are we going to apply these policies for a particular domain.

Again, organizational units are going to benefit us, since we can apply group policies and security policies at the organizational level as well.

Let’s go on to our Flexible Single Master of Operations role. These are called FSMOs, and we may have all heard of these, but with this multi-master model that we have with Windows 2000, we have certain roles that need to be administrated or looked over by one master role holder. We took these particular situations where it would make sense to have a master role holder and designed five roles that they’ll look after.

The schema master and the domain naming master are forest-wide FSMO roles, so we only need one FSMO role master per forest. And the schema master is going to look after the schema and make sure the updates are only going to happen on this one, and then get propagated around. And our domain naming master is going to look after things like how our domain tree management is happening, or can we install this domain in the forest because is it unique—those types of things.

We also have role masters on a per domain basis. Each domain has to have three role holders: a PDC emulator, and the PDC emulator is going to work similarly to the way the PDC did in 4.0. It’s going to be in charge of down-level replication to 4.0 BDCs. It’s going to handle password conflicts. We can have an urgent replication to this PDC, and then if there are any questions when the person logs on, because maybe their password isn’t right, it will go check with the PDC and say "Is this right?" And the PDC will have the most up-to-date information.

It can also maintain our browse list, because it will hold the role of domain master browser. We are still going to have browsing available, although we also have — this is different than our directory queries — but we can actually look at our directory and publish things in our directory, and then we can find resources via browsing like we did in 4.0.

Our infrastructure FSMO role is used to update and make changes for cross-domain object references. Because we can put objects from one domain into containers held in another domain, we need to have reference to them to look for things like their SIDs, their GUID, and their distinguished name. Once we have that information, it’s easier to find things. We hold this information on the domain controllers where the objects are held, and then we need somebody to clean it up if there are deletions, moves, or something, where things change about that object.

We also have something called a RID master. We had RIDs also in 4.0, but when you create a SID, the first part of your SID is pretty much the same, because it’s based on some numbers about domain and things like that. The last part makes it unique, and that’s the RID portion of it.

That RID needs to be handed out by one single domain controller so we don’t duplicate RIDs — then we’d have duplicate SIDs. It’s important to make sure we have these five master roles available to our domains, and of course the two that reside in the forest.

The first DC that we are actually going to promote in our forest — this creates the forest in our first domain and our first tree — is going to contain all five FSMO roles, because it’s the only domain controller available at the time. What we can do is move the roles around as necessary once other domain controllers are brought up, and other domains are created. We can do this through some of the tools that we have, our MMC tools. We can also use a tool called Ntdsutil, which can be used to transfer or seize roles. And the only difference there is if your machine that holds the role goes down, then sometimes we aren’t able to transfer it because the transfer has to have those machines up, so we can seize the role by going and taking it from that machine. And then if the machine has to be rebuilt, it can be rebuilt.

Now, that we’ve gotten through our FSMO roles, let’s talk about administration goals in Windows 2000. There are two main administration goals in Windows 2000: setting access control lists to control visibility, and access to objects in the directory; and also delegating administration.

We use these organizational units to provide this flexibility in accomplishing these goals. The organizational units are really, as you’re going to be able to see, going to control the way we can administer our domain in Windows 2000. It’s going to be much simpler.

The next slide, "Organizational Units": let’s look at a structure of an organization unit to get an idea how this actually works. Here we have a picture, and we have a Microsoft organizational unit, a PSS organizational unit, and a Development organizational unit. This is just an example. Companies can decide how they want to use it, but they have to look at their organizational structure as well as their administrative model.

What kind of administration do they have? Is it centralized or decentralized? Who can administer what? Can they administer users, computers, printers? There are so many things to take into consideration.

Our administrative control can be placed on the OUs. And our OUs act as containers where we can place objects inside of the OUs. Here we’ve placed some users inside of the different organizational units. And this will help us administer these particular users.

Let’s talk more about organizational units and what they can contain. It’s important to understand, like I mentioned before, that they are containers and they can contain things like users, groups, printers, computers, share folders — all these things that are contained within our directory they can hold. They can also hold subordinate OUS, so we can have a nested tree of different OUs. They can contain policies — group policies can be applied at the OU level. And administrators can maintain certain tasks in relation to the OUs.

What is so nice about these OUs is they’re so flexible, easy to create, easy to delete, easy to change. Domains are not that flexible. You really had to tear them down and restructure them, rebuild them, and do all this maintenance in order to change the structure of your domains. With organizational units, it allows us much more flexibility on how to manage things, and, if we need to reorg, we can easily make the changes without completely tearing down a machine and rebuilding it.

The next slide, "OU Structure Possibilities"; I say this is easier to administer, but it’s very granular. It’s very difficult to decide how you’re going to set these up and to sometimes apply the access control lists, but what I mean by "easier" is it’s easier to work your models around your organization. We have much more flexibility in Windows 2000.

Some of the ways you might want to structure your OUs are department based, project based, business function based, administration based, object based, and geographic based. These are all examples. If you were doing it object based, you might decide that you want an organizational unit for the different objects in your directory, so maybe we’ll have one that’s specific for users. And, again, this can be nested so we could have a department OU, and then underneath that we could have different OUs based on the objects they contain. We’ll see a couple of examples here shortly and hope this will make more sense.

Going to the next slide, let’s look at how we can assign access control lists to these organizational units. Here are some examples of access control lists. As we all know from working with 4.0, access control lists hold access control entries. Here are some examples of some entries these access control lists might hold. We have two types of access control lists now in Windows 2000. We’ve got our explicit, or set specifically on the object and they don’t inherit, and then we’ve got inheritable ACLs that can propagate down to everything within that organizational unit. And in this example, we can use this access control list to contain what people can do with the objects contained within the OU.

For instance, I’ve got a Sales Managers group, and they can have read access. They could look at everything in the organizational unit. And then I might have a U.K. User Admin group that can create users. Their sole administrative goal might be to just create users in an organizational unit. And then, we can use things like being able to propagate down with inheritable ACLS, things like resetting passwords. In this particular situation, we’ve given the Location1 Admins the ability to reset passwords, and so for any object contained within that OU, such as a user, they’d be able to reset passwords on that user.

Let’s go to the next slide. This is really what we’re getting at here with access control lists, being able to delegate an administration. We can have these different tiers of administration now, we’re able to have one administrator who’s a junior administrator who isn’t able to have all the control over a particular organizational unit, but maybe has one specific role that they play in that administrative model. And so this organizational unit allows us that flexibility of being able to say "Okay, you are pretty new, and you really only have these certain skills, so we’re going to give you certain administrative abilities based on those skills," and not giving them the administration over the entire domain. And this is what our customers really have been asking for for a long time, so it’s good to see this in the product.

This example is similar to the one before. I can set certain administrators to be able to create users, or create printers, and allow them to only do that. And then set inheritable ACLs to propagate down to all the user objects within that organizational unit, and maybe only allow them to reset passwords on user objects.

Let’s go to the next slide and look at our Delegation of Control Wizard, because we’ve made it a little easier to not have to go find all the access control lists for certain tasks that we think people might need in Windows 2000. We have this Delegation of Control Wizard, and in 2000 this helps us delegate certain tasks. We set up predefined tasks that are included in the wizard, and then we set up custom tasks, which is a list of all ACLs available. If something that we haven’t thought of isn’t in our predefined list, an administrator can create a custom task with this tool as well.

And in the next slide, we’ll look at the wizard and see what it looks like in Windows 2000. This Delegation of Control Wizard, you can see where you can delegate the following common tasks. One example here that I’ve checked is Reset password on user accounts. If I delegate this to a group—and before getting to this screen I’d actually have to specify which group or user I’d like to give this administrative control to — I can give somebody just the ability to reset these passwords. And this might be very beneficial for me, because I get tired of resetting passwords every day for these users. I can get somebody else to take that load away from me, but not allow them to create users.

Now, as you can see, the bottom radio button is where we’d be able to create custom tasks for delegation.

Let’s move on to the next slide about delegated administration. I want to make a point here that without controlling individual access on objects, we’re not going to be able to apply delegation of administration without these OUs. These OUs are really important for delegation. And so when you’re thinking about your forests and your domains and your domain trees, you need to think about how you’re going to plan your organizational units as well, so you can get the best administrative functionality that you need for your administrative group.

When you think about how to even create the organizational units, you have to know your administrative model. You have to know who is going to do what tasks and be able to plan your organizational list accordingly. And then it’s good to know, too, is it really de-centralized, or is it centralized administration within your organization. You can decide how deep you need to nest your organizational units. Do I need to create more than one domain? Because maybe I can make it really easy to administer and create one single domain and use organizational units to set up our delegation of administration and organize the way that these objects are contained within our directory.

On the next slide I’ve got some examples of how the administration can work within an organization. Our first example shows where we have multiple domains, and so we’ve got a parent domain, and then we’ve got our U.K. and U.S. domains. And we have an All Users organizational unit, and then we have our department base for Sales and Legal. Within both the U.S. and the U.K. domain, we set up our organizational units first based on the object, and then based on our departments. The reason we’ve done this is because we have a U.K. IT department and we have a U.S. IT department, and we want them to be able to manage all users within each domain.

We are sort of decentralized. We have a legal department that’s spread between these two locations and so we’d like to allow Legal HR to manage both Legal organizational units — to manage both of those organizational units across that geographic boundary — and also do the same for Sales. With these access control lists — and remember, they’re inheritable, so they can propagate down that organizational unit tree — we can accomplish pretty much all of the goals we need for the different types of administration we have within our organization.

Let’s look at another example. This example is a little different perspective. We wanted to delegate administration based on a location basis. We actually have a single domain. We don’t need a multi-domain model in this scenario. We decided all users ought to be able to change their personal details. Instead of having us go change them every time their personal details change, we’ll leave that up to the user. We can set access control lists to allow these users to change their personal details. And now users can look after their own addresses, etc.

We then want to be able to delegate administrative roles to them as well. When you look at how we’ve done this, we have a Location1 manager who is going to be able to reset passwords for all users within Location1, and we’ve done the same for Location2. And then we’ve used kind of the same model as we did before, where we’ve set up the departments, Sales and Legal, and I can have my Human Resources look after those two organizational units across the two locations. Even though the users reside in different locations, we can still have a central Sales HR group that can manage those users.

Now we understand the basics, and again you’ll probably need to look at your administrative model, and look at how your organization is functioning now, and decide how you’re going to set up your organizational units, and domains, and what your forest is going to look like. We can now focus on getting that information replicated across to all the different domains within the forest.

I’d like to move on to Active Directory replication. We talked a little bit about this multi-master replication model earlier, and it’s really important to understand replication because if we’re not replicating correctly, then we’re not going to have all of our domain controllers up-to-date. Because, remember, these are peers now, and we don’t have a central domain controller that’s getting the changes and propagating them down. This is a multi-master model.

We make changes to one DC and the replicate to all of our DCs. We’ve partitioned out RID space, so we’ve got our RID manager that’s in charge of handing out these pools of RIDs at each domain controller as they create new objects. Particularly, users or groups — they’re going to have a SID related to that, and so they need to have a RID. And we can make changes on two different domain controllers at the same time, and so then we’ve got to manage conflicts, and we’ll talk about that a little bit later.

And then we’re actually able to have sites to allow for scheduled replication as well. We’ve got a section on sites too, that we can talk about today, on how to set up your sites and what to think about when you’re doing that.

Let’s go on to directory replication. On this slide, we’re going to talk about our naming contexts again. Just as a reminder, we’ve got our schema, which again is enterprise wide, our config, which is enterprise wide, and our domains, which are domain wide. Each domain in the enterprise has all its domain-wide context. And we have something called the global catalog that was talked about in Active Directory Part One, as a domain controller that holds the schema, the config, and a full copy of its own domain, and then it holds a partial copy of every other domain in the forest. And this partial copy contains all the objects in the forest and only a partial set of attributes. When we think about replication, we’re thinking about domain replication, schema replication, and our config replication, but also about our global catalog replication.

And so let’s go on and talk about our update sequence numbers, because the update sequence numbers are what allow us to be multi-master. It’s our way of deciding what is the most up-to-date domain controller, and to be able to get those changes based on the up-to-date sequence numbers. And you will be able to see this as we go on. I’m going to show you how some low-level replication works.

It’s a 64-bit DWORD number, and it’s local to the domain controller. Each DC has its own up-to-date USN numbers. The USN numbers are not necessarily going to be the same, so you just can’t compare them and say "These are up-to-date." That is not exactly how it works. It will be a little more clear here soon.

When a new object gets updated through the transaction, the up-to-date sequence number gets assigned after that transaction is complete so we don’t have misrepresented numbers. We also have objects that carry two USNs. We’ve got a created USN and a changed USN. And we carry these to understand where the change happened and whether objects were created. And by created, it could mean an attribute was just changed. And we’ll see that here shortly.

Each property is going to carry these two USNs as well. Our object holds a USN, and our property or attribute underneath the object is going to hold two USNs as well. Remember, when we do multi-master replication, we’re not replicating the entire object, per se, unless it just has been created. If it’s brand new, we have to replicate the whole object. But once it’s been created and we make modifications to an attribute on that object, the only thing we replicate is the attribute. It’s a per-attribute replication. And this is good in many ways because it reduces the amount of replication that needs to take place once an attribute has changed.

We can index these properties. I’ll show you how they get indexed in a moment. And the USNs are independent of system time. Our USN numbers are not created based on time. They’re based on change.

Let’s go to the next slide about conflict resolution, because it’s important when you have multi-master replication, and the potential that we could create the same object on two different domain controllers. How do we manage a conflict?

The way we manage a conflict is we look first at the version number. For each property we hold a version number, and then we look at the timestamp, because we do stamp when the change was made. And then last (this is really rare this would ever go this far), if the version number and the timestamps are the same, then we would go to the higher GUID of the originating DSA, which is your domain controller. Each domain controller has a GUID, and we would look at the higher GUID to actually see if the information was changed.

One thing I want to mention, and I hope this doesn’t confuse people, but for people who might be confused about what I just said — with the GUID, we have a database GUID and we have a server GUID. The server GUIDs are used for DNS. We see GUIDs within our domain naming system servers. That’s used to find the domain controller when you’re doing a name query. The database GUID is tied to the database, and so if you restore a database, the GUID changes. I wanted to make sure you understood the difference there because I didn’t really cover that today. But when I’m saying the higher GUID of the originating write DSA, I’m actually looking at the database GUID.

Let’s go on to the next slide and look at how an object gets created. This is really low level, so if you don’t understand this right away, you may need to look over it a few times or play with it a little bit and try to understand this. I think it’s important to be able to see how these changes take place so when you have to troubleshoot this, you can think to yourself, "This change was made, and this is probably how it was working. Now, why doesn’t it work anymore?" And so, let’s look at how an object gets created on a domain controller.

Here we’ve got a domain controller, and each domain controller has a USN number, and we’ll see in a moment what we use these USNs for, but basically it’s just to see if they’re up-to-date or not. Our USN, once this new user get created, goes from 4710 up to 4711. And so we have, basically, an index here, and this would be held in our database, which stamps it as the same as the domain controller’s USN when it was created. The object, or the new user we add, has a created USN of 4711, and a changed USN of 4711, because this was just created. We haven’t made any changes to it.

Then we index all of the properties or attributes of that object. In a user’s case, it might be a telephone number, address, any of those things, and that value column holds the value. The USN number is held as well. And that, again, is the same as the object, initially. Our version number stays at one, and our timestamp is going to stamped at the time the object was created. And then we have our DC1 database GUID, and its USN number. We hold that information just in case we have a conflict.

We then go to the next slide, which is "Object Replicated." What happens when DC1 needs to replicate to DC2 in our domain? The user object gets replicated, and the USNs are specific only to that domain controller. We have 1745 on DC2, and that moves up to 1746, because it just got a change. It’s a brand new object to that database, so we stamp it as USN created at 1746 and USN changes at 1746. Our properties get indexed and we create them same as we did before: our values, our USN, our version number, our timestamps, our originating database GUID, and our originating USN. Remember, these are separate to each domain controller, initially.

Now, what happens if later on, maybe a day or so later, the user’s password ends up being changed? And each change is going to increment the USN number of the DC. At the time it may have been 2001, and we increment that to 2002. Then we go ahead and for this object, the object created with 1746, that was a day ago, we update the USN change now to 2002. And the password that was changed, that might be property number 2. We change the value, we update the USN number to reflect the current value of the DC. We give it a version number 2, so we know that it’s been changed. We timestamp it for when it’s been changed, and then we update our database GUID for DC2, and our originating USN gets updated as well.

Going to the next slide, we can see where a change has been replicated. We replicate this user back from DC2, and in fact, I made a mistake in this. I should have kept it as password. But, let’s say this password gets replicated from DC2 back to DC1. DC1 has gone through several changes at this time, so its USN number is now 5039, and it gets incremented to 5040. Back when it was 4711 — we keep that as our created date, because that’s when it was first created — we update our USN changed, and then P2 is our property number so we update that value. The USN, we give it a version number of 2. We timestamp it for when the change happened, and now we have our originating database GUID, because that new value that has been written is going to be our DC2 now, and our USN is going to correspond to that DC2.

Going to the next slide, let’s talk about our high watermark vector. I mentioned that this USN number for the DC is important, and it is. Because we hold a table on our domain controller that holds our replication partners and their highest known USNs. This is a way we can detect changes that occur with our replication partners.

Going to the next slide, I show you what the table probably would look like in this scenario where we’ve got a DC4, and it’s got two replication partners right now. It’s got DC1 and DC3, and we’re holding their highest known USNs.

In our next slide I’m going to talk about our up-to-dateness vectors, because this is the other table we actually hold. We have it specific for each naming context, but, what do we know about every domain in our ring, or every domain controller that we communicate with? We hold information about how up-to-date we are on a per naming context basis. In this table we’re going to hold the originating the database GUID for each domain controller (potentially) and the highest originating USN. We can then know, when we send this information over to our partners, how up-to-date are we for all the domain controllers in the domain, or in the forest, if it’s a config and schema change.

Let’s go on to the next slide and we can see what an up-to-dateness vector looks like. You can see here that every domain gets added when an update has performed an originating write. In this case, DC3 hasn’t performed an originating write yet, but we’re going to hold DC1 and DC2’s GUID and their highest known USN. And this is going to tell us exactly what changes need to occur between the domain controllers. I’ll show you more about this. It doesn’t make quite as much sense now, but it will in a moment.

Let’s talk about for a minute this information sent in preparation for replication. We send the naming context for which changes are requested. We’re going to send the maximum number of object update entries requested and the maximum values. This is "How many can I accept?’ And then we, of course, use the lowest common denominator. Then we look for the highest USN of a naming context of each replication partner. We’d actually send that to say "This is the USN that I have, all the information I have about you," and it can decide then if it has changes. And then you also send your complete up-to-dateness vector. This helps for propagation dampening, or only having to send the changes that actually had occurred.

Let’s look at how replication happens, and on the next few slides, we’ll show you how replication occurs and how we use the up-to-dateness vector and the high watermark vector tables.

In the first slide, we’re showing where a user gets created on DC2. We increment his USN number from 2052 to 2053. DC4 was just the one that we’re really looking at right now, it has no idea about DC2. It hasn’t had any replication occur. And you can notice about the database GUID and the USN numbers, and this is where they are originally. It still thinks it’s at 2050. It doesn’t know that it’s been incremented to 2053 yet.

Let’s go to the next slide, step 2, and look at what happens when replication takes place between domain controller 2 and domain controller 1. It sends that user over to domain controller 1, and its USN gets incremented from 4711 to 4712. Once this change happens, DC4 hasn’t had replication with 1 yet, so even though it’s the partner, it doesn’t know about the changes on DC2 yet, but we do know replication has occurred. Let’s got to step 3 on the next slide where we can see—basically what happens is DC1 will have a timer that goes off after the changes occur, and in five minutes it will notify DC4 "I’ve got changes."

DC4 will say "OK, let me go get your changes," and it will send things to them. We talked about what it sent in preparation for replication: the naming context; the highest known USN for that DC (which was 4711); how many objects can I have and how many values can I have, what’s my max; and then it sends its vector table. So, "Here’s what I know about, and here’s where I think you were last time we talked."

We get to step 4, which is on the next slide, and we can see where DC1 says "You don’t know about this user." It sends it the data of all the users that were created, initially, on DC2; and it sends it his highest known USN back to say, "I’m at 4712. Update your high watermark vector table." And you can see in the slide how it was updated. And then it sends the vector table. It will update both DC2’s and DC1’s highest known USN. In this case, I hadn’t yet updated it, but it would be 4712 and 2053. It gets updated on the up-to-dateness vector. Now it’s got the latest up-to-dateness vector table.

Going on to step 5, now DC2 sends notification to DC3 and replicates its information to it, and so this DC gets incremented from 1217 up to 1218 by this new user change. Once this occurs — we talked about this timer that goes off—in five minutes, it notifies DC4. But at this time DC4 doesn’t know about this change that has occurred. Let’s go to the next slide for step 6 and look what happens when it notifies it, and DC4 sends the information, which is its naming context, the highest known USN for DC3, number of objects, number of values, and the up-to-dateness vector table. It sends that all to DC3. Step number 7, on the next slide, shows where DC3 says "Wait, you’re up-to-date." And so it actually sends back its highest known USN number, which is 1218, and it sends back its vector table and says "This is what I have. Looks like you don’t need the change. You’ve already received it from DC1."

This is actually how replication would occur in a domain or in a forest. And the example was in a single site. We’re not doing intersite replication yet. The same concepts really apply, but the way we were showing it, it was for an intrasite example.

This brings us to being able to talk about sites and what we can be able to do to control replication within an organization. We know we’re not always going to have these T1 or T2 or T3 links that are going to provide really fast replication. At times we may have to have replication occur over a really slow link.

As you can see with this site slide, we have two types of replication: intrasite replication, which is going to occur in each site; and we have intersite replication, which is going to occur between sites. We’ll learn a little bit more how that happens. Basically, sites are going to control our Active Directory replication. They’re also going to help with knowledge about when somebody logs on. They’re going to be able to find a domain controller in their site if there’s one available, and locating printers, and some Dfs information as well. There are many benefits to these sites, but today we’re going to focus on just replication.

The next slide talks about intrasite replication, in particular. Intrasite replication is going to form a ring. I talked a little bit about this before. A ring is going to be formed by connecting to two partner DCs, potentially more if we have a large ring. But we don’t want to have more than three hops to reduce latency. If we have to go three domain controllers to get our information from one other domain controller in our ring, then we’ll have to create a shortcut or another connection object to that domain controller to pull that information. Every time you run DCPromo to install a replica domain controller in a domain, or if you bring up a new domain controller in a tree that will do the config and schema — but basically our naming contexts are going to be schema and config, which have one topology, and we have a separate topology for domains. Once the DC comes up, it adds and removes itself from the topology or this ring, and then we form our intrasite replication.

On the next slide, we’ll talk about intersite replication because this works a little differently. Intersite replication, we can use RPC over IP. We use RPC for communication. We cannot use SMTP for intrasite. With intersite replication, for domain naming context — and this is again it’s own topology, we can use RPC over IP — for GC config and schema, we can use RPC and SMTP—both of them are supported.

SMTP is going to use the intersite messaging service, and its asynchronous replication, so it just sends information. It doesn’t need to have that confirmation that it necessarily received it right away. It’s a little bit faster about sending things. It’s not quite as concerned that it got there. And we don’t use notification. We don’t say "I’ve got changes," like I was talking about — after five minutes it says "I’ve got changes." The other domain controller comes back and initiates replication with me. What we actually do is we set it up on an interval and we can use scheduling. I will show you that here in a moment.

The other thing we use with intersite replication to reduce the amount of bandwidth needed is compression. We can compress from 10 to 15 percent of the data volume. And we have a role called the Inter-site Topology Generator role, and this role holder uses its KCC service, which is our Knowledge Consistency Checker, to set up our intersite replication topology. It connects all your sites together.

Going to the next slide, let’s look at our Sites and Services snap-in. Here you can see where you have your site, and then within each site — so here we have Default-First-Site-Name, which we left, and then we have a site called East, and East has a folder called Servers; and we have all of our servers in that site — within each server there are NTDS Settings. And this setting holds all of our connection objects that it has to every other domain controller in its domain and in its forest.

We can see the Knowledge Consistency Checker generated this connection object to this domain controller, and we see which server it is, and we see what site it’s in, and so at that point we can tell if we have a good ring established.

Let’s go to the next slide and talk about when to create new sites. We always want to create new sites if we have a slow link involved. We’re considering a slow link less than 10 Mbps. We can place DCs into sites like I just showed you with the Active Directory Sites and Service Manager, and we can move them too. You just right-click on the server, and you can select Move, and we can move into another site.

There are a couple rules of thumb when we create new sites. We want to create a GC at the site level, so each site should have a global catalog server. And we should deploy DNS at a site level, too, if we want to reduce having to cross the network to look up names. And in most cases, with a small or slow link, we’re not going to want to have to go across the link to resolve those names. We connect sites with site links, according to our network characteristics. I’ll talk a little bit more about costs and things in a moment.

Administrators create the sites, and they create site links. And it’s their responsibility to decide, based on their network characteristics, how they should assign and configure those. I’ll show you where you can do that here in a moment.

The next slide, this is looking at the topology. I’ve been talking about topologies, and it’s kind of repetitive here, but our sites are areas of high bandwidth, and we knew that one or more subnets can be in each site. And our intrasite replication is going to be over RPCs, so it’s notification based. And our intersite replication is RPC-based for all naming context and we can use SMTP for configuration, schema, and global catalog.

Sites are configured by the administrator, so it’s up to the administrator to understand their network topology and to create sites accordingly.

Going to the next slide, I talked about these transports earlier. We have TCP or RPC over TCP, and we have SMTP for intersite. And this may be assigned by administrator, but it’s limited to naming context. I keep repeating that because it’s really important to understand that SMTP can only be used for config, schema, and global catalog. It cannot be used for domain naming context.

If we go to the next slide, we can look at site links. Our site links represent two or more sites, and these are going to be connected physically by a WAN link. Our administrator can assign cost and our transport, and can schedule frequency of replication, so the cost is going to tell us how fast and how reliable that link is. And we can set that. And our transports are actually going to tell us about which transport it can use. We can set it up to go over — again, it’s limited naming context — but we can set it up to do a site link over IP or SMTP. And we have a default IP site link, but we do not have a default SMTP site link.

We should be on the slide, "IP Site Links." And we can see how to create these IP site links. Because we can see our DEFAULTIPSITELINK, and then I’ve created a couple more. There are East and North. And then we have East and West. And we actually have North and West. We have four site links in this scenario and they’re all IP site links. I’ve created these, and what we can do at this point is connect our sites via these site links.

There’s no default SMTP site link. We are going to create only a default IP site link.

Let’s change and go to site link properties and take a look at how we can configure these site links. In this site link properties picture, we can see this is how we can configure our site East to North. And we’ve decided the sites in the site link, and that’s on your right-hand side, are going to tell which sites are contained within the site link. We’ve got East and North, and we can set our costs to whatever we feel is going to work for the speed and reliability of our network. The default is 100, but we can change that.

The Replicate every, what this tells us is that we’re going to do this on intervals, but we’re not notification based, so we set up for an interval of 180 minutes, and that’s three hours. By default we’ll replicate every three hours. We can change this, lower the replication frequency, or increase it with this dialog box.

Let’s go to the next slide and see how we can set up a site link schedule. Our site link schedule, by default, is going to be on 24 x 7, and we can white out certain periods of time where we don’t want replication to occur. Even if the frequency goes off, if the schedule says that replication doesn’t happen, then replication is not going to happen. Between scheduling the frequency of replication and setting a site link schedule, we can pretty much control replication when it occurs. If there’s a period of where we have a lot of network traffic, we may want to disallow replication during those periods.

Our bridgehead servers are going to be configured based on IP or SMTP, and we can set preferred bridgehead servers. Here we haven’t set any preferred bridgehead servers, but our bridgehead servers can be set so we designate certain domain controllers to be bridgehead servers. If we do this, though, we’ve got to be careful because bridgehead servers, once you designate them as preferred, will only be used for bridgehead servers. When the KCC, the Knowledge Consistency Checker, is responsible for going out and deciding who should be the bridgehead server, and if a machine goes down it picks another one, if you don’t have more than one bridgehead server designated as your preferred, you might be without a bridgehead server for a while until you figured out that it was down.

One thing about bridgehead servers is they are gateways. We have to have a bridgehead server at a site in order to get replication to occur. Bridgehead servers do not store and forward naming contexts that they do not host. You can have multiple domains in a site. If you do this, you must have multiple bridgehead servers in the site as well.

Let’s go to the next slide, which shows us our bridgehead server configurations. This is a configuration we created. It could be any configuration. We have four sites here with New York, Chicago, Atlanta, and L.A. You can see where we have multiple domains, and so we have multiple bridgehead servers at each site. Our numbers represent our costs, and again you can define them any way you want. We could go with really low numbers. The only advantage to going with a higher number is when you go across multiple sites you have to add the numbers together. It’s a little easier with larger numbers to configure the correct cost based on your network speeds.

Just some things to think about: again, we have to have multiple bridgehead servers when we have two different domains. And bridgehead servers are domain controllers too, so the KCC will pick them for you if you don’t set up preferred. And they’re going to share links and costs, these bridgehead servers. When you set up the site link, they’re going to run on the same site link; they just have to have a unique bridgehead server for each naming context that’s unique. In most cases, that’s just going to be a domain because the schema and config are the same for the forest.

Let’s go on to the next slide and look at our site link bridges. Our site link bridges are used where our site links are going to contain one or more sites. Our site link bridges are going to contain one or more site links. And a bridge is going to connect these site links. It’s going to be sort of like a bridge/router relationship where it’s going to allow them to talk to multiple sites. And these site links should share one common site, and a site link bridge has to share one common site link.

Your cost for transport is going to be used for making routing decisions. If you have multiple paths, it’s going to take the least cost path. And, if you have quite a lot of sites, you may end up having multiple paths they could take to send replication.

The KCC, the Knowledge Consistency Checker, is going to create these minimum cost routes that can span multiple sites. You should configure separate site links just for non-routed segments, such as like a VPN, because you really want to minimize how often you use these VPN connections. By default, when you create a site link bridge, all site links are going to be available.

Let’s go to the next slide that shows a site link bridge creation. You can see I’ve removed our default IP site link and just left my three other sites. But by default, when you created it, it would have all site links that are available in the site link bridge.

You could just name your site link bridge and then add whatever site links you would like to contain within that site link bridge.

On the next slide, we’ll look at how these site links and site link bridges are going to work. In the first slide, we see site links versus site link bridges, and this is just our network. As an administrator, we’d have to take a look at our network, see what kind of bandwidth we have, and decide how to create our site link bridges. As you notice, we have a Fashion domain and we have four domain controllers, Campus, New York, Paris, and Milan, and they need to communicate via replication. Going to the next slide, we’ll see how we can set up our site links. And so we go ahead and configure our site links and our costs based on our network topology again.

At this point, though, because we don’t have a domain controller or a bridgehead server in London, our replication is broken. Fashion1 and Fashion2 can communicate with each other because they have a site link between their sites, and Fashion3 and Fashion4 can communicate with each other, but Fashion3 and Fashion4 cannot communicate with 1 and 2.

Let’s go to our next slide, and look at the possibilities for fixing this problem. And that is to create a site link that connects Campus and Paris. This would allow us to communicate. Fashion4 would talk to Fashion3, and Fashion1 could talk to Fashion2. We can get all of our replication routed around through this new site link that we created.

Now, look at the site link, and you’ll notice that I’ve assigned it the cost of CL, which 200, and LP, which is 300. CP, which is Campus and Paris, has a cost of 500.

Let’s go on to the next slide, which shows us our site links again, and we’ve done a network upgrade. I just wanted to show you that once we did the network upgrade from London to Paris, we have to lower our cost, to reflect this upgrade, from 300 to 200, and then what happens is we have to lower our cost from Campus to Paris from 400 to 500, to reflect this change.

The last slide shows how we could use a site link bridge instead of using an additional site link. And it’s really up to you how you want to administer this. The only benefit is that it would be easier to administrate the site link because you wouldn’t have to worry about making changes when you’re doing network upgrade. You could just create the site link bridge, and it would bridge together your site links.

In this last slide you can see where all of our sites are going to be contained. CN, CL, LM, LP, and PM are all going to be part of the site link bridge when we create it. And so now Fashion is resolved. That replication is not broken anymore because the site link bridge bridges those two sites, even though we don’t have a bridgehead server in London; we can still talk now from Fashion1to Fashion3 via this site link bridge.

And, I’m sorry I went over a little bit today again. But, we have finished the presentation today and we’ll be ready for any questions.

Heidi: Thank you so much, Paige. It is time to move on to Q&A portion of this session.

A couple of notes before we so, however: if you joined the session late and would like to review the contents at a later time, within about eight hours of the live session, we do have on-demand streaming media available. Also, I know sometimes the slide images are little bit small on your browsers. You can always download those slides at any time. Those are with the Past Support WebCast information. And, finally, within about three weeks of the live session, we also have a full transcript posted to the same Past Support WebCast information.

As a reminder, if you have a question, you should be submitting it to us during the live session, and you can do so with the Message Center to the right of your PowerPoint slides. If you don’t see the Message Center, you should see some icons at the top-right of your screen, one of which will expand the view and let you send your questions.

We have had a few questions submitted already, so we’ll get started.

The first question is: "If a DC with a role is physically destroyed, how can the role be assumed by another DC? You said both must be up to change roles?"

Paige: Yes, I think I mentioned this before, and maybe I wasn’t clear enough, and I probably wasn’t.

The FSMO goals that we were talking about earlier in the presentation, there are five of them. If a machine goes down that holds any of those roles, we do need to get those roles to another domain controller. If the machine is down, we can’t transfer the role. What we have to do is seize it. We can seize this by using our Ntdsutil utility and we can go and seize the role. If you seize the role, however, if that machine ever comes back up, both of them will hold the same role, so you need to either have just rebuilt the machine or remove the role using the Ntdsutil.

Heidi: The next question is: "Do all physical (IP-based) devices within an OU automatically appear as a DDNS entry? And then to follow-up, how does the LDAP entry relate to the DDNS entry?"

Paige: That is a little different. I’m not sure what we’re talking about, physical devices, but —

Heidi: Well, then we’ll ask the individual who submitted the question to give some clarification, before you try to answer, so we make sure we’re not going down the right path.

Paige: I wanted to say one thing, Heidi. Dynamic DNS is very important in Directory Services, and so every domain controller registers SRV records, which when people make queries via LDAP, it’s going to query the DNS server to be able to locate that domain controller, wherever it needs defining. Only domain controllers are going to register SRV records — so domain controllers, and then any other host on the network is going to register a host record or an A record. That might clear up his answer. I’m not sure what he’s saying with physical devices. He might be talking about routers or something.

Heidi: Actually, I just got an addition, and they were thinking about printers.

Paige: {That’s going to depend on how that’s set up. If the printer is attached to a print server, then the print server will be registered in DNS. If the printer is configured to connect directly to the network, then it will only use an IP address, not a host name, so it will not need to register with DNS.}

Heidi: The next question is about hub and spoke technology. "It is generally accepted practice to try to hub and spoke through larger sites, or should you try to avoid that?"

Paige: {No, you can use a hub and spoke configuration. It’s really going to depend on how your network is configured. Hub and spoke is a good idea because once that replication goes to that one central site, it can get out to the rest of the sites quite easily. This is especially true if you have good connectivity to one central site from all other sites. Also, it can be more efficient in regards to topology. The ISTG role holders’ KCC at each site, except the hub, will have fewer connections to configure. In fact, one of your largest test labs used this configuration for testing replication. The following article explains more:

Q244368 How to Optimize Active Directory Replication in a Large Network.}

Heidi: Okay, excellent. The next question is: "How do you determine which machines should hold the FSMO roles?"

Paige: This is a question that can be answered — I’m going to give you a KB article to read, because I think it’s a good KB article. It’s article Q223346, and I know that because I’ve looked at this article quite a bit. It talks about FSMO role placement and optimization within Windows 2000 domains. And so when you think about how to set up your FSMO roles, when you have one domain, and maybe only one domain controller, obviously, it’s not as important. As you get more domains and multiple domain controllers in each domain, this becomes a little bit more important.

There are a couple of rules. We do recommend that your infrastructure master should not be located on a global catalog server. It should be just a normal DC, not a global catalog server. And then for the forest level, the schema master and the domain naming master, those should all be placed on the same domain controller, because they’re really not used very often. You can read that article and it will explain more about how to place your FSMO roles.

Heidi: The next question is: "Do OUs have an attribute for DNS domains? Is it mandatory? Is it inherited by lower-level OUs?"

Paige: {An Organizational Unit does not have an attribute for DNS Domain. It does however, have an attribute for distinguishedName, which would contain information about what Domain it resided in. However, you can view all of the classes and attributes available in the schema using the schema tool. To use the Schema tool:

1. First register the DLL and then use the snap-in.
2. Choose Start, Run, and type: Regsvr32 C:\winnt\system32\schmmgmt.dll
3. Then Start, Run MMC, and add the Active Directory Schema snap-in.}

Heidi: The next question is a little unclear, but I’ll do my best with it. "Is there a way to move the other FSMO 2 role from a GUI? Currently, I’ve been able to move the PDC, RID, and infrastructure."

Paige: {We have the schema and domain naming master—we could move the schema master through our schema management tool. And the schema tool is not installed by default. You have to register a Schmmgmt.dll in order to get that tool installed. Then you can open the tool from the MMC, right-click Active Directory Schema, and choose operation master. As far as the domain naming master, you can move it via the Domains and Trust snap-in. You right-click on the Domains and trusts icon in the MMC snap-in tool and choose Operations Master.}

Heidi: The next question is leaning into SMS, so I’m not sure if you’re going to be able to field this one, Paige, or if it’s an inappropriate question for this forum. It is: "Are there any SMS 2.0 considerations that need to be addressed?"

Paige: Yes, this one would really need to go to our SMS group.

Heidi: Yes, that’s what I thought. But we thought we’d ask that anyway.

The next question is: "Can a bridgehead server from DomainA, Site1, connect to a bridgehead server in DomainB, Site2, to relay information between DomainC at each site? Does that make sense?"

Paige: I think so. They want to know if you could have a bridgehead server — this is where it gets complicated. Basically, if you have Site1 and it holds Domain, and you have Site2 that hold DomainB domain controllers. A bridgehead server is just a domain controller. It can only pass information about the naming context that it holds. If you have a schema and a config, which have the topology, the schema and the config directories hold the topology. That information could be transferred to a Domain Controller A in Site1 to Domain Controller B in Site2, and then get transferred to DomainC in another site. But the domain information is going to be specific to that domain, so that information would not be able to be passed, and it would have no need, since they’re separate domains.

Heidi: Okay. The next question is actually about the location of the on-demand content. If you go to the Support Online site, you will see an option for Support WebCasts. Click through that and one of the options is All Past Support WebCasts, and that’s where we will have all of the archived information, as well as all of the archived information for the rest of sessions that we have done.

The next question is: "What are the two types of replication in Windows 2000?"

Paige: The two types of replication we talk about are intrasite and intersite replication. You really need to understand how both mechanisms work, because they are remarkably different and for good reason. Because we’re assuming that if it’s intersite, it’s going to be over a slow network and bandwidth will be lower.

Heidi: The next question is: "DCs insert themselves into the replication ring. How do they do this? Is it based on server records in the DNS?"

Paige: Every DC has a service called the Knowledge Consistency Checker service, and that KCC is what builds the topology. The topology, once it gets built, actually gets created in their Config directory on that local DC, so the configuration partition of the directory database is where that information gets stored. A DC comes up, it says "I’m new. I need to know about all the domain controllers." And it gets that information initially in the config, once it gets its first replication as a new DC. If it’s a replicate DC it comes up. It pulls that information in from a partner DC that it contacts during DCPromo. Then it says "Okay, I know about all these domain controllers in," let’s say this is the domain topology, "so I know about these partners. I’m going to create this topology," and so it inserts itself into its schema, and then through replication it replicates that information out to all other domain controllers.

And so it only uses SRV records for replication. It doesn’t actually use it to insert itself into the ring.

Heidi: We only have a couple more questions right now. Looks like the next one is a response saying, "FSMO role can be changed through the MMC."

That was just a comment from a customer online.

Paige: Yes, it could. That’s what I said it was, but I guess what we were wondering specifically was those two specific roles, which MMC.

Heidi: The next question is: "Regarding child domains in Active Directory, how far can you nest child domains within child domains?"

Paige: There are no published limits for child domains. There are some practical limits, though. Mainly for resource access and trust relationships and fully qualified domain names. Remember to access resource in a domain tree, it will need to walk to domain tree to get access to resources in another domain. Also, the following article talks about the FQDN limitations:

Q245809: Windows 2000 Supports 64 UTF-8 Byte Fully Qualified Domain Names

I would also recommend that you really think about designing your enterprise as simply as possible while still meeting your organizational needs. This concept is always recommend for increasing performance and troubleshooting issue.

Heidi: Are policies held in the Active Directory, and if so are policies domain specific?

Paige: Policies are held in two places, the Config directory, where we hold information about the policy. And the policy also gets held physically at the Sysvol directory. Well, let me go back, because I didn’t cover the group policies today. Group policies can be held locally, at a site level, at a domain level, and at the OU level. We can assign these at any of those levels. Now, the precedence also goes in that order. If you assign at every level a policy, the last one is going to take effect, and that’s going to be at the OU level. It is stored in the Active Directory. The policy is also stored on a domain controller is the Sysvol directory.

Did I answer the last part of the question?

Heidi: The last part was "Are policies domain specific?" Did you answer that part?

Paige: Well, it depends on where you apply them if they’re domain specific, because they are, in a sense, but you could also apply them at the site level, which isn’t really specific to a domain.

Heidi: With that question answered, we have addressed all the questions that were submitted for today’s session. I want to thank all of you for your participation. I hope this session was useful for you.

I encourage all of you to submit your feedback to us. Let us know what you think about the program, this session, and the other sessions that you’ve seen. At the moment, you can do so through the Message Center. And any time after the live session you can do so using feedback@microsoft.com. We are very interested in your feedback.

Once again, we do hope that you found this content useful. Thank you for joining us today and have a wonderful day.