Slide: Domain functional levels require that domain controllers run a particular version of the Windows operating system. Each version of the operating system has a functional level associated with it. You are not able to raise your function level while domain controllers are running previous versions of the Windows operating system. When Microsoft introduces new features into Active Directory, at times those features are associated with a specific functional level. For example, there may be a setting that I want to deploy with an active directory, but it requires all domain controllers run 2012 or newer. If that is true, I may be required to raise my domain function level to 2012. That means you could never add a domain controller older than Windows Server 2012 to your domain. When you raise a domain functional level, it is a one-way process. It is not possible to lower that functional level. We also have force functional levels. Each version of the Windows operating system has a forest function level associated with it. This requires that every domain controller in the entire forest run a particular version of the Windows operating system. Windows Server 2003 forest function level gives me the ability to perform domain renames. It also has support for readonly domain controllers. The Windows Server 2008 forest function level gives me no new features. Everything from the server 2003 function level carries forward, but no new features introduced. The Windows Server 2008R2 function level introduces the Windows Active Directory recycle bin. Windows Server 2012 and Windows Server 2012R2, they carry forward the features from the earlier versions, but they introduce no new features. Windows Server 2016 also introduces no new features.to manage my domain and force function levels. We have a few tools we can use to modify those levels. I'm going to go to administrative tools and I'm going to select the active directory administrative center. This active directory administrative center is a graphical tool that executes PowerShell on the back end. The bottom of this tool has the Windows PowerShell history. If I expand that Uh you'll notice it's blank. This only records commands for the session that you are actually in. When you close the active directory administrative center, it automatically clears the PowerShell history. In the administrative center, I'm going to select my domain RTS local. The right side of the screen under this task pane has the option to raise the domain functional level and the option to raise the force functional level. I can select either one of those and it would let me raise the functional level. So right now it says my current functional level is set to server 2012R2. I could raise it to server 2016. So that would be my domain functional level. If we cancel that right above is the forest functional level and I could raise the forest functional level. So both of those could be done in the active directory administrative center. Well, I'm going to raise the forest function level to server 2016. Note that my domain function level was 2012R2. When I raise the forest functional level, it says this change affects the entire forest. Once you raise it, it's not possible to reverse it. We will accept that and I'm going to select okay. Says the force function level was raised successfully. New function level will replicate to each active directory domain controller. Well, in my ad administrative center. I'm going to just refresh that view just to make sure the console is up to date. Now, when I click on raise force function level, it says function level is 2016. Notice at the bottom of this console, it has my set 80 force mode commandlet in PowerShell forest mode force mode 2016 forest- identity rts.local server it's raised on-server RTS-dc1.rts.local. So that is the PowerShell syntax to raise my function level.In active directory, sites have two purposes. I have those listed at the bottom. Service localization and the ability to manage replication. So those will be the two reasons we create sites and they will dictate the site structure we actually come up with. In this graphic, I have a single domain, rts.local. I have four locations, Washington, Dallas, Phoenix, Seattle. Each of these locations has two domain control. controllers. So what that means to us, any of these domain controllers can authenticate any user in the domain. Does not matter which of the domain controllers you connect to. A concern I have if I have a user that works in the Phoenix office, when this person logs on, it would be inefficient, slow if they were to authenticate against a domain controller in Seattle, Dallas, or Washington. Every time this person logs on he needs to use a domain controller in Phoenix because that's local to the network he is actually on. The way that works in sites as we'll see in the next section when I create a site in active directory I will give the site a name and I will specify the network ID. In this example every device in Washington is on subnet 17216, Dallas 17217 Phoenix 17218. So for Phoenix every user in Phoenix, the computer they use will have an IP address that's 172.18 something. I'm going to say 9.54, but it's on the 172.18 network. Being on that network, every time my user authenticates, when they send a service location request to DNS, DNS looks at the IP address on the user's computer. It then goes through and finds all the domain controllers. Now, for this user, all All of these domain controllers will be returned, but it will always have these two domain controllers at the top of the list. Now, they will alternate. Sometimes it'll be this one, other times it'll be this one, but those two will always be at the top of the list, which guarantees every time my user in Phoenix logs in, he's always going to use a local domain controller. If you were in Seattle, the IP on your computer would be 172.19 something. Every time you log in, you would always be referred to one of those two domain controllers that is service localization the manage replication as we'll see in the interface I will create site links so between Phoenix and Washington we will create a site link on that site link I will actually define when replication should occur the default is 180 minutes so 3 hours the minimum you can set is 15 minutes depending on our needs how many changes occur, how fast the WAN link is. Several things factor into that decision. We can adjust that as we see fit. So when I do that, if I were to go to a domain controller in Phoenix and create a new user within 180 minutes, the next replication cycle, that user would have their account replicated to Washington, but not until that replication cycle actually arrived. So the managed replication all flowed saturation on the WAN link. by giving me the ability to dictate when domain controllers should actually replicate. We do that for each of these sites. Now, let's take a look at the interface and figure out how these are actually defined.to look at the site setup on my server. I'm going to pull up server manager and I'm going to go to tools, which this just gives you the list of administrative tools. In that list is Active Directory sites and services. You do have to be an enterprise administrator to manage sites and services, but I'm going to pull that up. It'll take just a moment for that to open. When I expand my sites, well, notice right now there is one site named default first site name. When Active Directory is installed, that one site is automatically created. Every domain controller I join to the domain is going to get added to this site. At the moment, I actually only have one domain controller. But when I expand the site, you'll see under servers, there is RTS-dc1. So, that's the site I'm in. If I leave this here for a moment, I'm going to go back to my administrative tools and I'm going to open DNS. in DNS. When I expand my forwardlookup zone, there's a zone named underscoremsc Microsoft domain controller services dot whatever your domain name is. When I expand that, I get a few folders. I'm going to just enlarge this here. One of those is this DC folder. Stands for domain controller. When I open that folder, there's a sites folder. Well, notice right now there's only one site under it. default first site name that was created when Active Directory was installed. We'll come back here in a moment to see what's changed once we create these sites. So, in Active Directory sites and services, the first thing I'm going to do is rightclick sites and I'm going to create a new site. And basically, we're just going to build that picture out that we just looked at. So, I'm going to create a site named Washington. I'll click okay for that. Now, I do get this message that says basically this does not work until you add a subnet for the Washington site in the subnets container. We're going to go back and do that in a moment. So now I have a Washington site. I will create another new site and we'll make this one Dallas. I'm going to create another site for Seattle. and we had a site in Phoenix. So, I have the four sites, but as that method said, the sites have to be associated with subnets. So, what I'm going to do, I'm going to go to this subnets folder, and I'm going to effectively build that picture we just looked at. I'm going to create a new subnet And for the prefix, I'm going to just type in the network ID, which was 172.16.0.0/16 in lie of the subnet mask, we're using the sitter notation. So that's the network ID with the sitter notation behind it. Just like the example they have at the top here for IPv4. In our graphic we worked through in that scenario, we said everything on subnet 17216 was in Washington. So I'm just going to click the Washington site and Okay, now Active Directory is aware anything with an IP 17216 is associated with a Washington site. Well, we rinse and repeat. Create another new subnet 172.17.0.0/16 that is in the Dallas site. Now, we could rinse and repeat this and we could do this again. New subnet 1721 18 and 19 for the respective sites. But that just gets repetitive. So two is enough. You would do this for every location though. Well, now I could actually take my server here and I can rightclick and move this server from the default first site name to Washington. This will give me a list of all my sites. You pick the one you want. Or you could actually just click on the server itself and drag it to that servers container under Washington. What's interesting for If we go back to DNS, when I look in DNS under that DC sites default first site name, that was the only thing that was present. If I refresh this, let's click on my server here and refresh. Now, when I expand my forward lookup zone, my_mscs DC sites, all those additional sites show up. Now, if I click on the Washington site, I see all the records that point to that RTSDC1 that we just dragged to the Washington site. So what happens now if I open this record, you'll see at the bottom it says host offering this service is RTS-dc1. Well, if I say okay for that and DNS, I'm going to click on my actual zone RTS.local and you see RTSDC1 is in the list and you see the IP address on it. It is at 17216. So if my user were to log in when they send their request to DNS to locate a domain controller which is a service location request it simply looks at the IP address on their computer then it says oh I have a site that is associated with that subnet and these are the domain controllers in the site that's who I would be referred to that would completely explain our service localization you always use local resources first because DNS completely figures all of that out for us. If you delete a site, add a domain controller, and move it to a site, it's immediately in real time reflected in DNS. Well, that's all we want out of DNS itself. In the sites, the other thing we said we could do was manage replication. To do that, I'm going just collapse some of these. This inner sight transport folder that shows up at the top has an IP folder under it. Now you can create two types of site links, IP or SMTP. You would not create an SMTP link today. SMTP is mostly associated with email. That's a holdover from long ago. If you were in it many, many years ago, like decades ago, a concept used to be demand dial routing or DDR, where you didn't have a router with like a broadband or persistent connection. Your router was actually a dialup router. When traffic made it to your router that needed to be routed, say through the internet or to another network, the router when it receives the traffic would actually dial a connection, bring it up, and then route it across. That is not common anymore. But SMTP was a protocol used for that because SMTP has the ability to buffer. So, it can hold this stuff in a queue, then it could send it after connection was established. We're not using those now. IP site links is what we want. Now, there is one site link that exists by default. It's named default IP site link. Now, you could use that or you could create your own. Well, we're going to create our own. So, I'm going to click this new site link and I'm going to add Washington and Phoenix to this site link. So, I'm going to just click both of those and add them over. And I'm going to name this Washington to Phoenix. We'll say okay for that. So I have my link. When I go to the properties of this site link, I see the sites in it. So what that means for me, the domain controllers in Washington and the domain controllers in Phoenix can replicate to each other and they replicate based on this schedule. As we said earlier, the default is 180 minutes. I could set that as low as 15. Depends on what your needs are, how much bandwidth you have, things like that. You could also change the schedule here and I could say on the busiest time uh on my network, I don't want replication to occur. So maybe at this time, Monday through Friday, I want replication not available. Well, if you look at this chart, that would be between 7 and 8:00 a.m. replication would not be available those times. So that's a possibility as The last thing in this list is the cost. The only purpose of the cost. If we switch back to my diagram for one moment, back on the diagram, let's say we created site links for all these locations. So, just like I created the Washington to Phoenix, you have a Washington to Seattle, Washington to Dallas. Every site link has a cost. The default cost is 100. The only purpose of the cost is to determine a path if more than one route exist. An example of that would be the way I'm laid out right now. If you create a new user, we'll say Bob Ross, that's supposed to be a user, but I create a new user in Seattle. My domain controllers in Seattle will replicate that user to Washington. Why? Washington will then replicate that to Phoenix. So depending on the replication schedule between Seattle and Washington, Washington and Phoenix really dictates when everything is updated. Now this is commonly referred to as a hub and spoke. Everything from these branch offices replicate to Washington, then it replicates back out from Washington to other locations. Pretty common that's the way you want it to actually work. A possibility though, if something goes wrong in Washington, maybe they have a black out. Uh, Blizzard knocks out power. For whatever reason, your domain controllers in these locations, Seattle, Phoenix, and Dallas, they cannot communicate with Washington. If that were to happen, replication fails because they all replicate to and from Washington only. So, a possibility, I could create a site link directly between Seattle and Phoenix, just like the Washington Phoenix one, but we now have one for Seattle to Phoenix. If I want this to be more of a backup link, then what I could do is set the cost on this link to be 300. What you effectively have is a routing loop. If I'm in Seattle, I could actually replicate from Seattle to Phoenix, then to Washington, or you could replicate from Seattle to Washington to Phoenix. So, you have a a loop or circle if we want to call it that. If I have a preferred path, I d the path I want to take using cost. So from the point of view in Seattle, it cost 200 to get a change from Seattle to Phoenix. If I go this direction, it's 100 between Seattle and Washington plus another 100 between Washington and Phoenix. So the domain controllers in the Seattle site, that's the way they view this. It cost me 200 to go that direction to get to Phoenix. If I set the cost on this direct site link to be 300. It views that and says, "Well, it's 300 if I go this direction." It always takes the lowest cost. There is no other metric it looks at. So, I'm guaranteed that I go through Washington. The only time I would directly replicate from Seattle to Phoenix is if the Washington site has failed or we have a connectivity issue and I can't talk to it, then it would use the higher cost link. So, the cost is only important if you actually have a loop. If you don't have a loop, You can leave it as the default value. I it just doesn't do anything until a loop exists. It determines your route. We also have a term called bridge head that ties in the sites. Now, this term shows up a few places in Microsoft and it also shows up across many different vendors. A bridge head is a server that simply does all inbound and outbound replication processing. I'm sure we would agree if I'm in Phoenix and I have these domain controllers in the same site. Well, if I created a new user here, now I say new user, this could also have been a new group, a new computer you join to the domain. Well, I create that within the site. Domain controllers in a site replicate constantly. So, if you create a new user on your domain controller in Phoenix, it's going to replicate to your other domain controller in Phoenix because they're on the same subnet, they're in the same site. So, it's not concerned with scheduling or anything like that. It just automatically replicates. Minutes later, you'll see it on that domain controller. Well, if I replicate between Phoenix and Washington every 180 minutes, there would be no point for both domain controllers in Phoenix to replicate across the WAN link because they have the same information. So, what every site will have automatically set up is a bridge head server. So we'll say this is my bridge head here. This is my bridge head. So we'll say BH. Every site will have one. So this is my bridge head here and we'll say this is my bridge head here. Any changes that happen in the site when it's time for replication to actually occur based on that schedule, Bridgehead sends it across and receives it. when it comes back from the other side. With the bridge head server, Active Directory automatically selects a bridge head. So, you don't have to do this, but if you have a preference, you can handpick which server will be the bridge head. Let's take a look at that in the interface. Back in Active Directory sites and services, I'm going to go down to my Washington site. I'm going to expand that servers and I have this RTSDC1. That's my server. I'm going to rightclick that server and I'm going to go to properties. The bottom of this property sheet has these protocols IP and SMTP that are available. Well, I'm going to click IP. And the right side of this says this server is a preferred bridge head server for the following transports. And I can simply click add. Well, when I add, I'm telling Active Directory that in this Washington site assuming we had more than one domain controller, but I'm telling Active Directory this is the server that should do all replication in and out of this site. Other domain controllers should not. If you don't click that, Active Directory automatically selects one. So whether you do this or not, it's still going to work that way. This just give me the ability to handpick the machine that actually does all replication. Now, many environments don't define it. They just let Active Directory actually select. So it's just an option. To recap this, the primary benefits of these sites were to allow for service localization, so you always use resources in your same site, and to allow us to schedule replication. All the changes we make here with sites, subnetss, which domain controllers are in which site, all is automatically reflected in DNS. And that's really what makes all of this work. If you were troubleshooting replication issues, uh, lo on issues, DNS would be one of the first things you would actually check because it is woven into really every component in the infrastructure.