1. Understanding and Planning DAGs and Settings
We’re now going to get into the concepts of understanding and planning database availability groups, also known as DAGs. We’re going to also be looking at some of the configurations and settings that go right along with that. Now the first thing I want to do is kind of just discuss some of the different facts about database availability groups. Okay? So first off, a DAG is a collection of servers that is going to provide a way of replicating and activating copies of different databases, all right? So a DAG is essentially a group of servers in which your mailbox databases will be replicated between those servers. Okay? Now the interesting thing about this is that it will utilise the failover clustering feature that your server offers, but you actually don’t have to go into the failover clustering tool to manage it.
It’s all going to be handled through Microsoft Exchange, okay? This is going to essentially do what is known as “continuous replication.” Continuous replication simply means that when you create a database, the database will be replicated to the other servers. And as things get changed in the database, as we add things, as we add new mailboxes, and as users receive email into their mailbox databases, it’s going to continuously replicate automatically. We don’t have to trigger this. It’s going to be a dynamic process. Okay? One thing to point out is that only one server at a time can actually have an active copy of the database. All the other servers are passive, okay? So you have one active server, and the rest of the servers are going to be passive. And then you can have up to 16 different copies of a single database. So essentially, you can have one active copy and then 15 other copies, making a grand total of 16 copies of that database. Okay, so I want to look now at the concepts of setting up a database availability group, all right? So we’re going to have three exchange servers here, all right?
Nyce one, Nyce two, and Nycex three So three exchange servers in our small example are fine? And on our Exchange servers, we are going to each have a database ability group that is going to be active. Okay? So we’re going to set up our little databases, all right? So this little cylinder-looking thing is going to be my database, and we’re going to have three different databases that are going to take part in this, all right? We’re going to tie our databases to different departments of our company, okay? So we’re going to say we have sales, we have marketing, and we have finance, all right? sales, marketing, and finance. So three different databases just going to copy these real quick, all right? And then I’m just going to kind of cheat and copy and paste these over to the other servers as well. All right? Okay, so this guy here is going to be the sales database, all right? Sales. Just kind of lower that font a little bit, all right? And then this guy here is going to be marketing, and this guy is going to be finance. All right? Finance, finance, marketing And then the last one will be Sale. All right? So essentially what we’ve got here is our three databases, and that was actually supposed to be sales.
So let’s fix that, all right? The final one will be sales over here. Okay? So what’s going to happen here? We’re going to be setting up a DAG, the Database Availability Group, all right? And we will have one active, and then we’ll have each with a failover, okay? So we’ll say that for sales, this guy is going to be the active one, all right? For marketing, this guy is going to be the active one, and for finance, this guy is going to be the active one. So now what you’ve got is essentially an active version of that database on each individual server, okay? So your DAG is essentially going to provide a system in which one server is active and the others are passive. You can even have a prioritisation system that you fail over. So, for example, I could have this database here because the secondary database is going to take over if this primary database was to fail.Okay, so Sales fails; he takes over next. If he fails, then NYC’s former employee would take over. He is the active third for marketing. We could have Ex-One be the secondary, and then this guy would take over if the secondary failed. Then, in terms of finance, this guy is the active. Okay? And then we could have Ex-Two as the main secondary that’s going to take over. And then with this guy, you can specify the prioritisation any way you want. You can control all that yourself if you prefer,
okay? But again, only one server is going to be active at a time. You can have up to 16 different databases spread throughout that if you want. Okay? You’ve also got the database replication service that’s got to be running on each individual server in order to make this happen. All right? So again, our ultimate goal here with the Dagis If a server fails, let’s say this guy right here dies; he just goes offline. Then almost immediately, this guy right here is going to take over as the active server. So mail flowing in that goes through your client access services is going to get immediately redirected to NYC Ex 2, okay? And if the other server comes back online, then the transmission can shift back over to Ex One. This is known as a failed back. So when a server dies, we’ve got failover. When a server comes back online, we’ve got a failback scenario, okay? All right, these servers are communicating with each other. If you’re familiar with clustered services and all that, You may be aware that there are heartbeat messages and things like that that these servers are using to stay in contact with each other.
And this is how they know that everything is still good and everything is still up and running. So you’re not having to put any kind of load balancing equipment in or anything like that for this. This is purely handled by this failover service and this database availability group replication service that’s going on that’s going to handle this replication. All right. Another piece of this that’s happening in the background is something called the ESC, the extensible storage engine, that is actually handling the continuous replication as well. And it’s doing block-level-based replication. And once the database is replicated, when a change occurs to one of these databases—let’s say a change comes into this database here, the sales database—then what ends up happening is that these other copies also get a copy almost immediately. All right, so that’s what’s keeping everything in sync. Okay. All right. So that’s the concept of database availability groups that’s coming up here. We’re actually going to take a look and go through the process of setting up a couple of these.
2. Creating a Database Availability Group (DAG)
in the EAC. If we look at the server’s object here, we can see that we clearly have our two servers showing up there, and they’re both ready to go. Okay? There are some prerequisite things that we need to do first in order to configure all this. We’re going to jump over to our domain controller first off, which is the NYC DC One server. Okay? So here we are at our domain controller. We’re going to open up our Active Directory users and computers, all right, which I’ve already got available here at the bottom of the screen. We’re going to zoom in on that for you. Now what we’re going to do is create a computer account that the DAG can use to represent itself in Active Directory because this is going to be using the failover clustering service. If you’re familiar with the failover clustering service, it actually creates what’s known as a virtual machine.
It is not a traditional VM based on Hyper, but it represents an Active Directory machine to which devices can fail over if one server fails. Okay, so we’re going to go to this computer’s object here. We’re going to right-click that, and we’re going to click New Computer, and we’re going to create a folder. And I’m just going to call it Dag, all right? Just call it “Dag One.” All right? So we’re going to go ahead now. We’re going to click OK. And I’m going to set some permissions on it so that the exchange system has some rights over this object. Okay? So I’m just going to right-click this actually. You need to make sure you turn on advanced features for Active Directory users and computers as well before you do that, or else you won’t have the security tab to do this. So I’m going to right-click it now. Go to “properties.”
All right? We’re going to go to the security tab, all right? And we’re going to be adding; we’re going to click “Add here,” all right? We’re going to add the exchange trusted subsystem, all right? There, we’re going to give it full control, all right? So change the trusted subsystem, give that full control, and we’re going to click Add and we’re going to go to objects, allow computers to be added, and we’re going to add the NYCEx One server and the NYCEx Two server. All right? So we’re going to give both of them full control as well, so they’ve got authority. And then we’re going to do something else. We’re going to make sure that there’s no way some hackers or somebody out there could try to use this object. We’re just going to disable the account, okay? So I’m just going to right-click it and disable the account, okay? Click yes on that. The account is now officially disabled. So what we’re going to do now is switch back over to our first exchange there, jump over to NYC Ex One, and pull up the Exchange Administrative Center. All right? So exchange the administrative centre right here. We’re over here on the servers object on the left side of the screen now.
We’re going to click on that, all right? And then we’re going to go to the Database Availability Group, all right? So let me zoom in on that for you. Click on Database Availability Groups; all right, it’s going to load that up, and then we’ll be able to officially add our servers here. So we’re going to click the little plus sign. All right? Now, one thing I want to emphasise here is that we must name the database availability group. The name is going to be associated with that same computer name. So I’m just going to call it Dag One. And then I’ve got to specify the witness server. Now again, I’m not really sure how familiar you are with failover clustering, but this is using the failover clustering service. And that service, when dealing with two servers like this, will necessitate what is known as a witness server. And remember, there are going to be heartbeats and messages and things going back and forth.
A witness server is basically a file server that’s going to store just a little bit of information involving something called the Quorum, which keeps track of if the two servers were to get separated. because imagine what would happen if both servers were still up. Let’s say the NYC Ex One server was up and the NYC Ex Two server was up, but somehow they couldn’t see each other. So this way, if they can see the witness server, the witness server can say, “Okay, well, that first server is still up and running, so I don’t have to actually cause a failover there.” But if, for some reason, NYC Ex One can’t see the witness server but NYC Ex Two can, then NYC Ex Two would become the active server and the other one would become passive at that point until things got fixed, whatever was wrong with that server.
So we do have to specify a witness server. In this case, I’m actually going to use my DC one. My domain controller is going to play the role of our witness server. So we’re going to say Nycdc One, and then the directory is just going to be Cum. I’m just going to call it Fswag One. That’s going to stand for file server? Witnessdag One. I’m just going to create a little folder there. It’s where it’s going to store its witness information. The data that’s going to be used for this is going to be assigned an IP address. Now you actually don’t have to assign an IP address. If you have DHCP, it’ll handle the IP address for the DA. Or if you want, you can give it one manually. I’m just going to do it manually. We’re going to say that our Dag is going to be represented by 101, 921680, and 100. So we’re going to go ahead now. We’re going to click save on that. Okay, so we’ve got our Dag now created, but we’re not completely configured yet because we haven’t actually associated both the NYC Ex One and the NYC Ex Two as being tied to this Dag One.
Okay? So to do that, we’re going to hover over this icon here, and this is going to be where it says Manage DG Membership. All right, we’re going to click that little cog symbol over there. And this is where we’re going to add our two servers. Okay. So we’re going to hit the little plus sign and we’re going to add NYC Ex One and NYC Ex Two. All right? And we’ll get along fine. Keep in mind that, depending on whether your server has recently received updates, it will install the failover cluster service, which may necessitate a reboot. So if you do get an error and it says something about the failover cluster service needing to reboot, then all you have to do is click, “Okay,” and reboot your servers, both of your servers.And then, once they get booted back up, come back in here, and then you should be able to finish it out. So I just wanted to kind of warn you that sometimes that does happen when you set up a DAGS. I’m going to go ahead and click Okay now, all right? And then we’re going to click “Save.” It’s going to run its course now. And this is where it could cause a reboot. We’re just going to let it run through, and I’ll pause the video until it’s done. Okay, so the dag was successfully created. We’ve got our DAGS created, our members added, and the installation has gone through. So we’re going to go ahead and hit close now. All right.
And as you can see, we’ve got Dag One, which shows the witness server, which is the NYC DC One, and our two members. Then anytime you wanted to alter that or maybe even add a third member, all you had to do was click the Manage Dag membership symbol here, the little cog symbol, and you could add an additional server. So if I did have an NYC Exchange Three, or heck, even if I had another Exchange server in a different office—that’s another common practise where people use an Exchange server in a different office to have a backup of a database stored somewhere on a different location—then we could totally do that as well. In my case, I’ve just got these two Exchange servers, so I’m using those. However, this only confirms that they are both set up. And of course, now the next step would be to start moving databases over to my dad. All right? Currently, my databases are just stored right here on my NCE. Ah. You’ll notice I only have one database on NYC, ext. 2. So, in this next lesson, we’ll do just that.
3. Managing your Database Availability Group (DAG) members and its health
and looking at servers. We’re working on databases over here. Let’s start by creating a new database, and we’ll have it replicated into our DA. Okay? So we’re going to click to create a new one. All right, we’re going to call this database “Research.” All right, we’re going to point it to our server. So we’ll have this stored on ExOne. All right, we’ll go ahead and have the database mounted. So we’ve got our research mailbox database created. We’re going to go ahead and restart the information store service. All right, so after pulling up services, we’re going to right-click the service and tell it to restart. And then, once that’s done, we should be ready to move that into our database.
Okay, so our service has been restarted; we’re going to minimise that now and we’re going to zoom in on this. We’re going to refresh the databases real quick. Once that’s completed, we should be able to enter this into our database. Okay, so it’s now ready. We should be able to click on this little ellipse symbol here that says more. And there’s an option that says “add database copy.” So we’ll just go ahead and click that. So we now have a small popup that says Add Mailbox Database Copy. All right, so currently the name of the database is Research. NYC Ex One is the only server that has a copy of it. Okay, I’m going to click “Browse.” Okay, so we’re going to select NYC Ex 2. All right? So notice that NYC X Two is going to show up over here, and this is going to be my next server. Now notice there is an activation preference number. Now, you may recall that I mentioned priority, the priority of failover, in my earlier drawing. So in this case, NYC Ex One is going to be our Active. He’s going to be our primary copy of the database.
So client access to our Mailbox database is going to be flowing to him at NYC Ex One. And if he fails, it’s going to fail over to Nyce Two. So this is essentially how you set your preferences here. There are only two. Now if I had a third server that was part of the Dag, like NYC Ex Three, then we could select the order there. If we wanted to, we could make three the secondary instead of two. All right, the other thing I want to show you is right here, where it says “more options.” I want to talk about this thing called the replay lag time. Now, we haven’t really gotten into doing what’s called a “Lag” database yet, but the Lag database is a really cool idea. If you had a bunch of copies of your database, you could have one that was a lag database, okay? A lag database can be behind on time. As an example, I could have a sluggish database that was two days behind the others. And the reason that’s cool is because if some kind of huge catastrophe happened or a bunch of data was overwritten and we needed to recover data from two days ago or a day ago or whatever, we have this lag database copy.
So that’s what that’s going to do for you. It’s going to be able to set it up so that you can actually go back in and look at that. And we haven’t really gotten into backing up databases and all that yet. I’m going to be talking more about all of the backups and restorations later. I just wanted to point out what that feature was right now. Okay, so I’m going to go ahead and click Save, and it’s going to go ahead and take a moment to save all those settings. I’ll pause the video while it takes a moment to do that, and then we’ll pick a backup. Okay, so the replication of the database went through successfully. So now Nyce Two officially has a copy of that database. All right, so now if Nycex One were to fail for any reason, then Nycex Two would also have a copy. All right, so we could do this with our other databases as well. All I’d have to do is just hit something like “sales,” “click this,” and I could add database copy marketing, add database copy, and that would be a way to move that over.
All right, you can also, of course, do this all with PowerShell as well. All right, so if you wanted to go through and configure it with PowerShell, you could look here, in Microsoft’s Knowledge Base article on creating DAGs. I just wanted to show you some of the PowerShell commands we’ve got available to us. To do this, it takes time to create these. So I want to just kind of run through these. You have a new database availability group; you create the DAG; and there’s your witness directory. Another approach is to create the dag and specify the IP address. Notice that we didn’t specify that up here at the top, but we are specifying the address down here. Okay, so another option is to create a Dag threewitness, and then specify multiple IP addresses in this case. All right. And then, if you wanted, you could just have it take all the defaults.
You could just flat out say, “Create a new database, failed group,” and it will just take defaults. It’ll use DHCP and configure all the defaults for it. So as far as the witness server goes and all that, the witness server will just be picked by the system, and the system will pick something like a domain controller to be your witness server automatically. So essentially, you’re just kind of letting the exchange system itself control who the witness server is going to be. All right, but as you can see, you can use the new Dash Database Availability command. Lint in PowerShell is used to accomplish this. If you wanted to get further information on that, you’ll notice the hyperlink down here at the bottom. We can actually look at the specific parameters. You have all these different parameters that you can utilise for the database availability group if you want to. All right, so in fact, they’ve got examples on how to use the commands here in this article. As always, and I know you guys have heard me say this before, I’m a huge advocate for using the Microsoft Knowledge Base articles. All you’ve got to do is just throw the command into something like Google, and it’ll be the first article that shows up.
Okay? And so from there, you can really get a good feel for how you would do all that using the command lines that they’ve made available to you. Obviously, in regards to Exchange, there really isn’t anything you can do graphically that you can’t do with PowerShell. All right? There’s a lot you can do with PowerShell EMS Exchange Management Shell that you can’t do graphically, but for the most part, everything you can do graphically, you could script using PowerShell. And there are lots of scripts out there that people have actually written. If you were in a cookie-cutter scenario where you needed to set up a bunch of databases for different branch offices or something, there are a lot of scripts out there that have already been created. All you have to do is find them and tweak them slightly to use them in your own environment. There’s a nice little command you can run. It’s known as get mailbox.
Database. Copy status. We’re going to hit Enter on that now. We’re on Ex One right now. As you can see, these are our databases that are on Ex One. So we can see which databases we have on Ex One.We have research and archived marketing sales in this mailbox database, which was our default one. Let’s go to NYC Ex Two now and execute the same command. Okay, so we’re in. EMS in New York, for example. Git mailbox database. Copy status. Hit enter. And there you can see the research. So we have research that says it’s healthy, and we’re not replicating this database, but we are replicating our research database. Okay? Now I want to execute another command. It’s called Test Replication Health. All right? Now it’s going to run a little report, and any database that is not replicating with redundancy is going to fail this health test. So it may take a moment to pull that up. But yeah, you’ll notice database redundancy; not all of my databases are redundant. It’s telling me that I have some databases that are not redundant.
Okay, but for the stuff that is redundant for the database, the research database, it is redundant. And I can do the same thing over on OneTest Replication Health, and you’ll end up with a similar concept. There is the research database, which is redundant, but these other databases, since I’m not putting them in the DAG, are not redundant. Okay, so this is a good way for you to just kind of get a quick look and find out. Well, maybe, oh no, you know what? We didn’t move this database into the DAGS, so we’ve got a database that’s not redundant. And of course, I can always go back and add the rest of those databases at some point. We’ve only recently added that research database. Okay, so hopefully that now gives you guys a good understanding, too, of just putting your databases in the Dag and then just looking at the processes of how you can actually use PowerShell to create a Dag and manage the Dag, and then also just getting a quick glimpse of the health of the database.
