 Hi there. My name is Ken Mayer and I'm going to be your instructor for this course on the Windows Server Enterprise Administration. Now I've been working in this field since the very early 80s and over that time I've seen a lot of different operating systems, a lot of different networking technology and when it comes to the world of Windows I started really when NT4 came out which was in 1996 or somewhere around in that area. From that point on I continued to work with that entire suite of the Windows network operating systems as we moved into Windows 2000 through 2003 server and of course into 2008 server. Now over that time I've also worked a lot in the network infrastructure realm and the routing and switching realm as well and which is going to be useful as we talk about some of the transitions that we'll see into different IP address options from 4 and 6 and some of the different encryption. I've also worked a lot in the world of security and so you'll hear me talk a bit about some of the security aspects of what we should be looking at especially in protecting our communications and our data which are also going to be part of what we talk about. So let's go ahead and get started with the Windows Server Enterprise Administration. In this chapter we're going to talk about planning for active directory which means we're not actually installing it we're not configuring it we're at that part before any of that happens which is looking at our organizational needs and understanding the best way for us to be able to work with our domains and the forest structure that we want to put out there. We're also going to look at the physical layout of our network so we understand what that topology looks like so we can better determine of course things like where to put domain controllers how to create different sites and if we have multiple sites to deal with the replication issues that go on between them. So that's our goal here in this chapter is to talk about these plans that we have for working with active directory prior to doing the implementation. We're going to start off by talking about the logical design aspects when it comes to the actual active directory. In fact there's a logical and a physical and in the logical design that's where we're going to be having a discussion about the forest domains the types of trusts that we have between domains between forest the functional levels that we have options of with using Windows 2008 server and also about the active directory schema. So we'll start off with the forest and in fact the forest it would be the beginning or the foundation of the logical structure of active directory because you can think of it as kind of that logical container that's going to contain all of the domains if we have more than one that we're going to use and kind of precedes from that point on. So the forest design is the first thing that we have to look at. Now when we talk about a forest of course it can be made up of multiple trees and each of those trees can be made up of multiple domains and if that doesn't make too much sense when you think well why do I want all those things well I'm trying to explain some of that as we go through with this entire discussion but remember that as a part of what we're doing here is we're looking at the design what is it we're trying to accomplish by this creation you know as far as do I need more than one forest and a lot of you might have said well you know a forest to me meant that everything in my company was in my forest and if there was another forest that was a different company where you're going to see that really in your design you may have multiple forests that you're going to present as your overall company or organizational structure and that's to help make sure you meet certain design needs and that's kind of what we're looking at the planning structure here. Now when we talk about this entire process of active directory is been kind of renamed to active directory directory services. In fact a lot of things in the realm of identity services have been put into this category of active directory with 2008 server. So you're going to see things like AD certificate services, AD federation services, AD rights management, AD LDS, the lightweight directory service. All of these things now are under this identity type of setup with Microsoft and so when I do refer to active directory almost always I'm going to be talking about the directory services or domain services the ADDS. Now that's what we're going to be considered as our network operating system. Now if this is the only requirement that you have you know if this was part of the planning and somebody said well all I need is just to have these directory services so that I can have that centralized management of users and computer accounts and be able to have that single sign on. If that's all you needed then probably the answer is say this is an easy setup you need one forest which by the way you have to have at least one forest and you might even be able to get away with having a single domain in that forest meaning that in the breakdown by the way within a forest you have at least one tree. Each domain controller the first domain control you make is going to be the root of that first tree and of course if you had any child domains it'd be a part of that same tree and so you could have multiple trees. Anyway in this situation if I have just one domain controller it is the root of the only tree and since it's the only thing in the forest it's also the root of the forest and often that very first domain controller you'll hear us talk about it as that forest root and having said all of that to simply say this if your only requirement is to have active directory then that single forest will suffice and probably even just that single root of that forest. Now when we look at using active directory as an enterprise solution you might have some requirements that mean that you have to have separate directories whether it's for security or for regulatory laws in that case you might have multiple forests being involved. Now with multiple forests you have a true separation of entities where there's not a you know a single administrator that can be in charge of all of the forest at least not without you really going out of the way to try to make that happen and so that might be a part of another part of your enterprise solution. You might also see that you have some maybe some application that needs to have a directory service but you don't want it to necessarily use the same directory services that is housing all of the user accounts and so a part of your solution might be to use that lightweight directory service called the ADLDS and what that does is it allows you to have an internet directory in a way kind of like a customer database that is utilizing the same type of hierarchical database as active directory directory services but it's really just kind of a shell of that same database in other words is not pre-populated with all of your objects that you create an active directory it's an empty database that's just waiting for you to create its own hierarchy and can be utilized it could be utilized by directory services could be utilized by applications lots of different uses for it so again those are options we have for active directory directory services and those are things that we have to start to consider about you know how do we want to utilize this within our organization. Now having said all of that there's another part of the planning that we'll look at but right now we're kind of looking focused at the objects themselves and when I get into the discussion of trees that's going to be where we start talking about some of the DNS options that we have as far as the naming convention so I want to make sure you understand that I'm focusing you know when I look at the domains and these force I'm really focusing on the directory services the objects inside of active directory and not worrying about naming conventions that's a kind of a separate argument that we would look at in our planning so I just want to make sure that we're clear here as to the real discussion why you haven't heard me talk about trees so much. Now you know some people say again I don't get this multiple force well let me give you kind of a quick rundown one little example of a project I worked on many years ago but it was still utilizing active directory as it was back in the year 2000. In that setup and I was a part of a team it wasn't just me taking it as a big large entity I mean we were all part of a team but we had two organizations I'm not going to name where this is but well I'll tell you it was one of these towns slash counties where there wasn't really a city per se it was like all incorporated I think that's what they look at it like a big metropolitan area and but they still had a quote-unquote city police department and a county sheriff's office and for whatever reason those two entities up at the very top management I guess basically the chief and the sheriff weren't necessarily happy with the other person they didn't like each other that much a lot of it was because of you know pay disputes and other things but anyway that's outside the story the part of the story is is that when we were trying to work with bringing them into this active directory design one of the aspects was basically saying that you know if I was talking to the chief or the sheriff it didn't matter it was the same story they didn't want anybody in that department to have any type of administrative capability in their department well okay if I had a single forest solution that might have been tough to do because there's going to be you know an enterprise administrator who can work with anything in that forest and and so you know how do you separate that I mean there are many solutions but what I'm suggesting here and this was not the solution ultimately but I'm just talking about why you might have multiple forests that what they wanted was a separation of the forests so that the entities in one department were separate from the entities in a different department but they could still have data communications through the way in which we can create these forest level trust connections and so that's why you know this is what we're trying to say is we're saying we need to plan and understand what are the requirements so that we can best utilize the logical structure of active directory to come up with that solution based on those needs now as we talk about the requirements before you start the design and that's a lot of what I've just been saying is that we should understand what are the requirements for our organization in using active directory now we could bring it up into an organizational structure and in the organizational structure that's where we're going to start worrying about of course things like how we want to manage it what kind of management options do we have I might even look at saying you know do I want to create people who are delegated to have control of a certain location or certain area maybe I start looking at organizational units how do I nest organizational units together to look at that overall administration do I need to have some sort of separation of objects through different domains depending again on the way in which we want to set that up and again the idea if you think about it is with separate domains we have separate collections of objects that are independently managed have their own domain administrators and that might be a part of the management that I have I very well might have a domain for the European part of my country no domain for the North American part of my country and organizationally inside that domain I might choose to you know maybe take on that North American domain and have an organizational unit for Canada one for the United States you know however you want to break that out it's kind of what you have to plan a lot of that around administrative requirements you also have the operational requirements the operational requirements are going to be talking about you know looking at all of the locations that I have to service and what kind of communications in other words in this operation am I going to require secure communications if I'm talking from one branch office to another should they be communicating with IP security do I have web applications that I need to have available do those web applications have to be available to people in a different forest where I might have to look at Federation services to be able to make that happen legal requirements legally if I were to talk about some of the reasons for multiple forests working with a company again I want to say which one it is but they they they worked in the stock trading arena so they did they had customers and they represented those customers they worked with their accounts and bought stocks sold stocks you know kept that portfolio for them but at the same time that they were doing that they had another group of people that would work with a large company and try to manage their working in the stock exchange as well well so now we got a problem because we have in the same company we have people who are working with other corporations and have insider knowledge about that corporation which could influence the other group whose job was to invest the money and of course it would be illegal for them to use that inside information on their customers or even for themselves and trying to make a profit of something you know maybe they know something's coming up and so they're hedging their bets and so we have to create what's often called this Chinese wall which is to make sure that the group of the company that was working with corporations had no ability to be working with the other part that was doing investments and so again that might be a legal requirement it is a legal requirement by the way and so we need that separation that might be again a requirement of multiple force so we have that separation and of course we also have to look at what kind of connectivity do we have especially amongst a dispersed company where I have branch offices maybe all over the world all over the state what kind of connectivity do we have do we have high speed links are we working great with ethernet services are we still back in the old days of our fractional T1 hopefully not doing dial up but you know we have to look at those types of bandwidth capabilities as well in our design because we're going to want to think about placements of servers and of course that starts kind of moving us into the physical aspect there as well but again that's all a part of kind of the requirements of what we look at to understand functionally what we want to have happen and how those questions are going to be answered in our design now as a part of the requirements as I said one of the things we looked at was autonomy versus isolation now autonomy simply means the ability to be able to work on my own and we have services and data as far as the different types of autonomy now services would be dealing with things like adding new directory services new domain controllers you know working with the that logical structure of the actual active directory our domains and domain controllers as I just said and different trees and that sort of stuff and whether or not I want to have people that can work independently and you work with those services as opposed to the data part of that which is the objects we're managing the stuff that's being stored in the directory services that's your computer and user accounts maybe shared paths distributed file systems printers that are being published in active directory those are the objects inside of active directory and again I might want to have groups of people that can manage those objects inside but I don't want them creating new domain controllers or creating new sites and so that's where we have these services and data and the autonomy is you know the ability to be able to let a person function with that data and maybe with just even a subgroup of that data so that I'm not saying all user accounts but maybe the ones in your state or your city at your branch office but but you still have that ability to work with those objects you're not dependent upon another administrator to give you what you need done in your location now isolation when we talk about isolation of services and data that that's separation the isolation of services could be in looking at where we have site placements and thinking about you know how do I separate those and and how do I make them communicate especially when there might be not the best communications process in the world isolation of data or the isolation of objects which maybe it's different domains that will work where I can have a group managing a domain of their user accounts and groups separate from another domain but then again you know you don't have true isolation in that situation in fact one of the things I have to tell you you're not going to have true isolation within the same forest when it comes to data because no matter how many domains or trees you create within that forest there's still going to be that one administrator or group of administrators that can do anything they want and so true isolation and Active Directory does result in having multiple forests so that I don't have you know that one user that can do everything through all of the objects anyway so when you're making the discussion you're doing the planning of Active Directory and I hope I've made some sense here we want to talk about how much do I need to isolate the services and the data which is a part of my design and inside of those isolated areas perhaps if you want to think of it that way how much autonomy do I want to give different management groups to be able to deal with services or with the objects in the data that we're working with and that's another again of all part of our planning and setup that we're going to get into better and bigger discussions with as we move through this course but right now it's just kind of that checklist we're going through to make sure we understand how we're going to do the design so I guess we can ask the question how many forests are needed now of course that's going to be based on the requirements that you've come up with and those requirements would talk about the type of isolation you need the type of autonomy and would be able to help you determine how many forests you actually need now remember to have true isolation especially data isolation we were we're going to say you need more than one forest but again you might want to maybe think that isolation is sufficiently done within the different domains that you have with each domain having it's in charge of its own objects and merely only has to do replications through a global global catalog all of which if you're not sure what I mean we're going to talk about in more detail later on but this part of the planning stages so you know understanding what I want to build and and it's all going to come from again those requirements that you have for the organization the type of isolation that you need service and data isolation and the type of autonomy the service and data autonomy now the organizational forest model is actually pretty straightforward you know if I were to look at this design where I might be able to get away with one domain controller within my entire forest so or I should say one domain within my entire forest so if we think of the entire forest and usually the domains are just you know a single domain or the triangle that you see the organizational forest model again based on management and within management might determine the type of OUs that I need to have for the purpose of my management and maybe any child OUs that we have based on again the type of management that I want to put into place as far as what objects do I manage and how do I manage them but in that case all of my objects are contained within this one domain and often we think to ourselves or within this one forest and in this one domain that we think of saying okay well that works for us that's based on my management model now in my management model you might choose to make other domains and and you know so we're actually going to talk more about the actual multi-domain options a little bit later on so we're going to focus just on the forest model and so in my example here I made it easy by having one domain in my forest and having the breakdown of management based on the containers that can be found inside of the domains inside of that forest now the next one is the resource forest model now in the resource forest model I'm basically going to draw two domains and tell you that they're each in their own forest so that's why I have them side by side and not in this kind of a child parent relationship and the goal is is that you would put all of the resources within one of the forests and all of the user accounts and other objects in another forest and of course that would mean inside of a domain in that forest now there may be of course some user accounts in the resource domain but that's because you need to have those accounts that are going to be managing these resources and over here all of the computer accounts that you create all of the users and the groups and the rest of them would be over here and what we've done is now we have actually a true separation or isolation of the of the resources from the accounts and that doesn't mean though you know that this poor user or trying to get over here to get to a resource can't do it what needs to happen is that you would have to create a cross forest trust or we'll call this here a forest trust so that the resources would trust those accounts in the other forest to be able to again see them make them visible and to be able to assign permissions or privileges but truly that would be you know for the use of a resource but not the management the management would be up to the folks that were in that particular forest for the resources now on the restricted access forest model what we're seeing here is that we actually have these two forests which I'm going to represent by you know just these domains and that in each forest we have our user accounts we have our computer accounts maybe our printers and everything else all in each of these different forests so that they are truly isolated from each other you could also say autonomous from each other that they don't have any administrative control over the other ones so it can be you know data or user restrictions that we separate but in the restricted access forest model what we're kind of doing is creating our own self-contained trees or forests I should say on both sides and if we want to allow communications we can still allow communications through a series of trust relationships or even just for use of web applications maybe even federation services to allow that kind of communication again that's depending on your requirements the level of isolation and the level of autonomy certainly in this case all of these objects here in one forest are isolated from the objects in the other forest and how I then break down the autonomy of the management would just depend on what I do within each of the forests that you see represented but those are some of the models that you would see as a solution for most of your organizational needs for most of your needs of isolation and autonomy both for data and for services now within the forest we break it down into containers called domains in fact we used to think of the domain as a security boundary and we still can in the aspect that within my domain I control all of those objects that are in that domain by my domain administrators and objects in a different domain don't unless I give them permission aren't going to be having any type of administrative control also we used to talk about domains being the breakdown of applying group policies which is true I can't make a single group policy for one domain automatically work for other domains unless I purposely link it to that domain so in that aspect it's a security boundary from our policies I can't make a policy that I can apply to the whole forest I guess is a better way of saying it so in many ways it's a container or a partition of the total active directory as well as a security boundary now the the goal here is to determine how many domains do you need and in which forest should those domains be created now of course there is a minimum to have even a forest to even think of it you have to have one domain and that domain of course would be the root of a tree but we'll talk about trees later when we get to naming conventions but you need at least that one domain to be able to have a forest and of course the first one you create in the forest is called the forest root from there it's up to you to determine how many more you need now let's talk about why might I need more domains it's not because of the old days if I go back to the days of Windows NT 4.0 the use of the of the term domain was really different than it was today in the active directory in those days we chose to make different domains you know some on security based on these trust relationships and how we can have users from one domain access things in a different domain but you know they were truly isolated each of those domains literally could have been interpreted by today's term as their own forest because you know in one domain it was all self-contained and there was nothing in a different domain that you could do to work with the first one they just were these different objects and the reasons we made them often were because of limitations to how many objects could be stored in that domain literally you could have a large corporation with multiple multiple domains only because they had so many objects to keep track of you know you get to this large you know nationwide worldwide store with a hundred thousand employees it was like yeah we can't put them in one domain it just we would break now that's not true in active directory it's not about the number of objects that you create that determine how many domains to be made now yes I did say a domain is a partition of active directory in other words if you have a million objects you're keeping track of I'm just using big numbers to make this easy math and and I want to have a partition of about two hundred thousand objects in one domain that's great you can have that partition put two hundred thousand objects in there and then you say well now it's going to be easier because now I can have another domain in that forest with another of those two hundred thousand and so now things are working well guess what at some point they are fully aware of all of the objects through global catalog which a global catalog by the way has got that entity inside of the forest that knows about everything in the forest so you know the separation isn't now because of the size because we still have to have that one object that's containing all information the goal now is for you to determine how to partition things maybe because of when connectivity you know if I have a company that really does have you know a presence in say in North America a presence in Europe a presence in Asia but I don't have high speed connectivity I certainly don't want to have to worry about replication traffic going across those slow links so I might partition my network now into different domains for each continent because of when connectivity and so that makes sense because now we can control replication but now remember even inside of your domain you may have different locations that have different offices in the domain that have connectivity issues we'll deal with that when we get to the physical aspects and talking about sites but I'm just talking about some of the things you might have to use as a goal to determine how many domains you need and why you need them and potentially which forest especially if you're using a multiple forest solution should each of those domains be created in all right so as I said the requirements of a domain they're often thought of as a partition to the forest to make them smaller perhaps more manageable units now remember again consider the replication capability because that might be a reason to have more than one domain now every domain controller within a domain must replicate with the other that we know for sure but the domain controller in my domain will not replicate with a domain controller in another person's domain at least not on the domain controller side of a global catalogs different story but still so that's where it's a boundary to be able to say okay hey I got it I've got a boundary here of a replication and of course like I said does a boundary of policies I could apply a password policy to my domain and maybe your domain has a different requirements for password policies so I make a different password policy over there and so those two policies will not conflict with each other even if one domains a parent over the other one it still doesn't inherit down so it's also that security boundary as well all right so those are some of the things we have to look at now again why do the partitioning it might be again to make the smaller units as I already talked about replication and security boundaries but it could also be an issue of management again of you knowing that I domains a collection of objects a partition of the larger piece of the forest and maybe that makes sense also in my administrative decisions of how to manage objects and how to assign people or groups of people to be in charge of that part of the of the overall active directory now there are a couple of examples that you might use for the domains again a single domain model is very easy it's a forest with one domain and all the directory data is in that one partition so that's it that's all under one one big roof there now what that means of course when we talk about autonomy you have to remember that we have you know domain administrators that could potentially do anything they want in the domain we have an enterprise administrator which in this case would be pretty much the same creature as the as the domain administrator because that's just one domain for all of my active directory don't worry the enterprise admin does have some other things they can do you know like working in the scheme and things like that but but again they're pretty much you know when it comes to actual directory data they're both the same as far as what they have available to them but that's that single domain model there's not really a lot of isolation in this model because the objects are within one container another example of the domain model is the regional domain model now regional again could be you're dealing with the way the wan connectivity you know the white area speeds so we could again have a regional domain model built on the geographical placement of domains of the different parts of our company knowing that regional locations can talk to each other with maybe better high speed connectivity than they can their counterparts over across the ocean or across even the country you might decide to have different domains not just for the entire continent but maybe east coast west coast and that type of situation at all kind of depends on what your needs are and as I said it could be based on physical connectivity it's certainly an option that you can look at but it's also going to be dependent on how you want to partition and manage those objects as well so the question then is how many domains do we need and really the choice of domains as I've said can be based on physical connectivity which of course will affect the replication scheme but the decisions can also be based on the numbers of managed objects again there's not an actual limit of objects but really maybe about how much replication traffic or security issues might be involved so think of it this way if I have a slow connectivity between two sites two locations in my company I hate to use the word site because you're thinking active directory I might be you know saying that you know I have a site in Boston I have a site in Los Angeles you know we're talking about geographical locations when I say that word site but let's say I do let's say I have a that east coast west coast and you know and there's a slow connectivity there between the two maybe it's a t1 all right so it's a t1 if your goal and this is just a mathematical process you know to think about number of objects that I would replicate and how much of that t1 bandwidth might I take I think the mathematics I saw as an example was saying look if your goal was to use five percent of that t1 for replication traffic then that means that you would have to have a limit theoretical limit of a hundred thousand objects to have replicated because that hundred thousand objects would be about five percent of that bandwidth of a t1 now t1 is not very fast to begin with and five percent of that amount could really add up to be a lot so that might be another issue that is a part of the decision process again it kind of sounds like that when connectivity is just my decision process but I want you to know it doesn't have to be because I could have one domain for my entire country and I could have uh Boston being in a active directory site and I could have the Los Angeles being an active directory site I can still control the uh the uh replication between them but when they do replicate they're gonna have a lot of things let's say I have half a million objects that's a lot of traffic that will have to be replicated so if I just decide you know what let's just not do a replication uh between those things uh other than the uh you know minutia that we have in comparison to real replication with global catalogs and that might be a choice of two different domains as opposed to two active directory sites again it's because of the number of people or objects I'm managing more than you know having the multiple sites I hope I'm making sense as I explain these things to you it's just uh you know why might I make that decision and what I'm doing is I'm kind of battling both sides of the argument for you at the same time hoping that you understand what we're looking at we that you have some flexibility you have some choices um but uh when it comes to the question how many domains usually it's um again based on the number of managed objects because of the amount of replication that would be involved and because of the physical connectivity which of course also is an issue with replication now when we ask the question about you know assuming that you're already working with active directory and uh and we're going to be moving to the uh 2008 um domain controllers or the 2008 network from my server 2003 uh we have to ask some questions would it be easiest for us to do an upgrade of our of our existing network or to be able to create new domains and maybe have to migrate things over so you ask the question first of all this is only up to up to debate if there is an existing Windows network in that case we have to ask some questions all right if we're going to do an upgrade versus a create if I'm doing the upgrade will the domain functional level that I have presently work and with the new potential options I have of a new domain functional level work for any legacy servers that are out there also as I'm doing an upgrade of domain controllers within this domain uh those domain controllers are going to be down while they're going through the upgrade can you afford that downtime uh and of course also ask questions are there new features that are needed one of the reasons I'm doing this upgrade or doing making the move to the new features in 2008 server is because there's things there I want to use within my existing network and so you also have to ask those questions too because that's going to determine you know what domain functional level do I want to be able to get those new features well the first domain you create is the thing that starts this entire process it's going to be the first one in the forest and it'll have that special designation called the forest root domain in fact it's usually the only domain that is immune to changes because if you were to change it especially destroy it you would destroy the entire forest so it's like that one domain that you've got to have perfect because that's going to be that centerpiece of the rest of your forest now we often call it then the dedicated forest root domain not only that but that one domain controller within that very first forest or tree in that forest when that happens it's also going to have all of the fizmos that we talk about all the specific types of operations masters that go with the active directory things like the rid master and the infrastructure master and all these other little roles we haven't got to the point to talk about just yet are also going to be installed and running on this thing so I mean it's a very important domain and I should say that very first domain controller because that's where you make the domain is on that first domain controller it's going to be very important to you so it's a dedicated forest root and and of course you know you could if you're creating multiple forests you may also have what may I call a regional forest root domain where you know we have that separation that isolation different forests each with their own root domain now within a forest forest is made up of trees and so we'll have a little brief discussion about the trees again you can have many trees within a single forest the idea of a train of a tree is that it's a root of the tree of course but it's the root of the naming convention for the domain name in other words when you create a domain it basically has a name and so let's say you're going to call it xyz.com so that's that root now if that first domain has a child domain let's call it training its full name is going to be training dot and then the basic dns suffix of its parent which was xyz.com so the full name would be you know showing kind of the path that we take to get back to the root of that tree and every subsequent domain that you create underneath that first tree root is going to have the same suffix xyz.com now if all of a sudden you decide you know I need another completely separate dns name but I still want it in the same forest that's when you would create the next tree because the next tree can have whatever starting domain name you wanted to have maybe abc.com and then everything underneath it would have as part of that root of that tree abc.com so again that's where you might choose to have multiple trees or domain trees within the forest is based on your dns or domain names that you want to use for you know this whole setup often we call those the fully qualified domain names we want them to be unique as far as the suffix of each domain but they're still administratively together so that's many trees in the forest now as we're working with domains we have different functional levels and it's important you know what these functional levels do for you and of course what domain controllers are supported within each of these functional levels and it's actually pretty easy to memorize this first part the first part is okay look we have windows 2000 native now believe it or not if people are going to say well isn't that just the level well there was a mixed mode to where we were being backward compatible in the days of windows 2000 with our nt4 networks that were out there and so when we moved to windows 2000 what we got was that all the same benefits of active directory and some other features anyway in the windows 2000 native then the domain controllers that are supported would have been of course all of the windows 2000 servers but anything in the future that means 2003 in 2008 now if you were to upgrade to the windows server 2003 domain functional level you lose the backward compatibility with windows 2000 server in other words the only supported domain controllers would be 2003 in 2008 and so obviously if we move to windows server 2008 then the only domain controller supported would be a windows server 2008 now you make these moves based on the features that you want to be able to bring into your domain and remember that I am talking about a particular domain within the entire forest I'm not talking about the forest level or the forest functional levels but that one piece that one partition within the forest now your domain functional levels as I said have these different features and so let's look at what you got when you went to the windows 2000 native again that's where you lost that backward compatibility with windows nt and that was obviously by the first feature you got which are universal groups because in windows nt domains there was not any type of a creature that would contain objects from all those different domains as we would call a universal group and we had universal groups in native mode both security and distribution groups we also were allowed to do group nesting that would be our ability to place global groups into a universal group you know and you know how we could kind of nest that out throughout the entire organization putting different groups inside of other ones as long as we didn't break the rules as far as group membership we were able to convert groups they could be converted from a security group to a distribution group and we could even change the scope we could change under certain conditions we could change a group from let's say universal to a global or from global to universal or domain local and again there are there were a couple of rules we had to deal with because of the membership of who can be in each of those groups and it also kept track of the SID history the security identifier history which was a great tool especially when we were doing migrations from one domain to a different domain and the reason that was really important to us is that if we kind of migrated objects from one domain to another one we still had to have our old security IDs to match up those old access lists that were on all of these different resources so we can still have access to those old resources plus be able to get new ones so i mean that was kind of cool as well with the windows 2003 domain functional level we still had all that same stuff with the native mode but we got a command line tool called netdom.exe that helped us prepare for the ability to rename a domain controller we also got an update of the login time stamp we were able to use the or use a this user password attribute to actually change it to change the effective password of the inet or person object we were able to redirect users and computer containers we were able to use constraint delegation and even support for selective authentication and then as you move to the 2008 domain functional level you still got all of those other features but then we got the distributed file system replication for sysfall a better improvement to the type of replication between domain controllers we improved the security from kerberos i mean if you think about kerberos in those old days it was using dez encryption and i hate to tell you this but dez encryption is like 25 minutes to crack on my little laptop and so it wasn't very secure communications back i mean in that day it was very good but by today's standards it's not so we got aes 128 and 256 bit support for kerberos authentication last interactive logon information and the ability to get rid of that one password policy for one domain by using fine grained password policies in fact we'll talk about some of these things as we continue on within this course but those are some of the things that you have to decide about you know to take that nice list of features and put it back into our discussion when you're making the plan for the number of domains that you want you also have to make the plan for what features do you want to enable and and doing so at the domain functional level if we move back to the discussion of the planning of our forest we can have the same discussion about forest functional levels as i just did with the domain functional levels our goal is to know what kind of features do i need or do i want to add into my existing network so again the forest functional level now remember forest is everything involved means that we have to have basically a certain domain functional level to support so when i was working with a windows 2000 native functional level for the forest that meant that all of the domains had to at least be a domain functional level of windows server 2000 if it didn't meet that then you know if there were those nt boxes we couldn't do it or we'd effectively cut them off but of course back where compatibility means that my forest functional levels at windows 2008 if i still can work with 2003 and 2008 servers if you move the forest functional level up to windows server 2003 you're going to hear the same story we did with the domain functional levels we would support 2003 2008 if you moved to the windows server 2008 forest functional level it only supports windows server 2008 so what are the features then what do we get for all of this well the windows 2000 functional level we're going to call that our default features and then we're going to say what did i get when i moved to 2003 because that was the big one because really when you moved to 2008 you're really not getting additional features other than making sure you're all working with 2008 servers i guess but in windows 2003 a big jump there we got the forest trust which we'll talk a little bit about the ability to rename our domains to have linked value replication to read only domain controllers a better working uh knowledge consistency checker or kcc to be able to create an instance of the dynamic auxiliary class to convert the inate org person to a user object the application basic groups the ldap query groups and to be able to deactivate and redefine attributes within our schema big changes there between the 2000 2003 uh and of course like i said with 2008 we didn't see any additional features but remember it was actually in server 2008 that we actually got a server that could operate as a read only domain controller now the schema is something that exists forest wide and the schema is a dictionary of the objects i can create in the forest i mean if you want to create a domain you want to create a user you want to create a group what are those objects how do you define them and what attributes can i configure on them and that is defined by the schema now when you are working with the schema if you decide to make a change like adding some new attributes to an object remember it's something that you really can't reverse it means you got to be careful about your design changes now of course we can deactivate some of those attributes which is good and we can redefine what they are but you know this is kind of a one-way trip so be careful now the only reason you have to really be careful is that if you make a change to a schema in a forest and you intend to merge it into a new forest or consolidate two forests together some sort of migration if the schemas aren't the same it just doesn't work so that's the only time you really got to be careful about that and the only way to get back to the old schema would be to destroy your whole forest and start over that might be a little bit of downtime anyway so be careful about what you do but it is like I said it's a dictionary of objects now you know we we saw in many different technologies the ability to to make some changes that can help support applications as an example if you wanted to utilize the configuration manager 2007 to be able to manage all these different machines that are inside of your network that actual configuration is best used if it can modify the schema we call it extending the schema when we make those changes and what it does is it puts information attributes into schema that can be read by the objects that are you know being managed by Active Directory to gather information about you know where's my distribution point where's my reporting point and all these bits of information that make it work very well with something like configuration manager so there's many applications that make changes to schema to make the applications work better even exchange server will make changes so that I can add something like a mailbox to my user account all right so one of the things you should do is if a part of your plan and design is to have changes to schema because of these applications or other needs is maybe first practice those changes in a lab environment you know where if it goes bad it's okay I can recreate the lab and start over but kind of call it your practice or test run before you move it into production now working with trust we're going to get a chance to look more at trust as we move on through this course but you might have to make some changes to the trust relationships to be able to improve your performance now one of the things I have to tell you is there are some trust relationships you can't do anything about in fact you don't want to be able to do anything about them in other words there is a trust between the tree roots within the same forest each parent domain automatically trusts the child domains and vice versa the child domains trust the parent domains and these trusts are transitive and they are two way now what transitive means is that basically saying if domain a trust domain b and domain b trust domain c then domains a and c will trust each other because they have that path that transitive path of trust in fact that was a big deal in the days of windows 2000 because that's not how it worked in the days of nt now being a two-way trust in the old days a one-way trust meant if I trusted you then that means that um that uh you know my user accounts can um or your user accounts I'm sorry can access objects in my domain because I'm trusting you I'm trusting that your user accounts are authenticated and so I can give them access into my domain that's a one-way didn't mean that the opposite was true that the you know if I wanted my user accounts to access resources in your domain I couldn't use that one-way trust coming at me I had to have one going the other direction so we had to oftentimes make two one-way trusts in the different directions to be able to handle that kind of connectivity whereas in the forest all those pre-built trust relationships between the tree roots and between the child and parent they're all automatically two-way trusts where again the relationship works in both directions now there are some other types of trust that you can make because the trust path may take a while and this comes to the speed um and you know when we talk about them in more detail it'll make more sense but we have some shortcut trust which is your ability to uh be able to change the path of trust so you don't have to follow perhaps a long path up to the root and all the way back down you can make a little shortcut or you can also have different forest trust each other especially if it's your organization but you've done some isolation have different force but need to have some connectivity between them for uh uh users in one forest to access objects in another you would consider making a forest trust as well