Plan, Deploy, and Manage High Availability Solutions for Mailbox Databases

0:00Email may well seem like an old fashioned technology

0:03at this point, but it continues to be

0:05a mission-critical piece of enterprise software

0:07for every organization.

0:09All of us rely heavily on email.

0:11And if you're going to be deploying and running

0:13your own email server with Microsoft Exchange,

0:15you want to ensure that the normal hiccups

0:17and routine maintenance that occur within a computer network

0:20don't disable or bring down access to your entire email

0:23infrastructure.

0:24So in these videos, we'll talk a little bit

0:26about how you can set up some high availability solutions

0:29to ensure that your email or your exchange deployment

0:32can weather those problems.

0:34We will talk about isolating fault domains.

0:36We'll talk about setting up DAGs in the file share witness,

0:39and even briefly a little bit about how

0:40you can deploy on the Microsoft Azure cloud platform

0:43for even more redundancy.

0:45So stick around.

0:46I'm glad you're here.

0:46This is a pretty interesting topic,

0:48and we have a lot to learn.

0:00I'm not going to lie.

0:01I find the concept of identifying failure domains

0:04to be kind of interesting and cool.

0:06And it's all about recognizing in your systems

0:08where failures may occur that would actually

0:11have systemic or system-wide impacts.

0:14A failure domain is a way of thinking about encompassing

0:18or enclosing a portion of your system,

0:19of your deployment, both physical and logical, software

0:22and hardware, that is self-contained and is either

0:26going to work or fail together as a unit.

0:29So it's a little bit of a difficult concept

0:30to get your head around at first.

0:31But I think once we think about it some

0:32and provide some examples, you'll

0:34start to get the hang of it.

0:36So first of all, you need to understand,

0:37or you need to recognize that your systems are going to fail.

0:39I'm sorry.

0:40I don't care how good at this job

0:41you are, eventually, something is going to go wrong.

0:44There is going to be a problem.

0:45And DR is all about having a plan

0:48to deal with those problems when they occur.

0:50But you cannot deal with those problems until you recognize

0:53how those problems are going to impact your wider system.

0:56And one of the first steps in doing that

0:58is identifying these things that we call failure domains.

1:01In a failure domain, we want to encompass

1:03a physical or logical section of our processing and computing

1:07environment.

1:07So what does that mean?

1:08Well, think about if you were running Microsoft Exchange

1:11on a single server.

1:13You might consider this server to be a failure domain.

1:16After all, if there is any problem

1:17on this server, if it loses power, if the hard drive fails,

1:20if the operating system gets corrupt--

1:22any issue with this server, and you

1:24have a failure in your system.

1:26Your Exchange databases are no longer accessible.

1:28Users can no longer get to their email.

1:30Exchange is down.

1:31That's bad.

1:32So a single server running a single piece of your software

1:36would be considered a failure domain.

1:37And one of the ways that you might

1:39extend or expand or create some higher availability

1:42is to simply run two servers, right?

1:45Now, you'd have one run server and a second backup server.

1:48And now, you have two separate failure domains.

1:51One server may crash, may go down,

1:52but it's unlikely that both servers will go down

1:54at the same time.

1:56Of course, this can introduce its own challenges as well.

1:58After all, first of all, you need

2:00some way to copy or replicate your data between those

2:03two servers.

2:04And you need some way to know if one server has gone down

2:07that everyone should be switching over and accessing

2:09the second server.

2:10You also have a new failure domain in that, say,

2:12for instance, if this network communication between these two

2:14servers goes down, well, you have

2:16a different problem altogether.

2:18You also have a total encompassed failure domain.

2:20If these are all in the same data center, for instance,

2:22and what happens if that data center loses power?

2:24So that data center is a failure domain as well,

2:27which you might solve by creating

2:29a couple of data centers.

2:30This is called geo-replication or geo-redundancy.

2:33They are physically separated geographically, your two

2:35servers, so that if one data center goes down

2:38for whatever reason, your second data center

2:40is still up and running.

2:42And you can introduce a lot of these.

2:43You may have two or three or four or five

2:45different geo-replicated centers.

2:48Now, one of the things you start to notice here, of course,

2:50is that, well, not only do we also

2:51have network communication between these data

2:53centers, which is a potential failure point,

2:55but this is starting to get very complex and costly.

2:58Not every organization is going to have the ability

3:01to replicate their systems over a wide geographic area

3:04and many different data centers.

3:05Cloud deployments are certainly making this more possible

3:08and more widely accessible.

3:09But the simple fact of the matter is, at a certain point,

3:12you're going to look at ways that you reduce your risk

3:14or reduce your chances of failure

3:16as being too costly and not worth the effort.

3:20So identifying failure domains is not just

3:22about identifying how your system can fail,

3:24but it's also about recognizing which failure points you

3:27are actually in a position to address

3:29and which failure points are going

3:30to be too complex to reasonably address,

3:32and instead, you want to have a recovery plan in place

3:35for when those failures occur.

3:37There is no hard, fast rules.

3:39There's no technical document that explains

3:41exactly how to do this.

3:42It's going to be different for every organization

3:44and every budget and every deployment scenario.

3:46The first step, like we're saying,

3:48is to identify these domains so you

3:50can understand how to address the potential issues

3:52of failure.

3:53Now, one of the things that Microsoft recommends

3:55in their preferred architecture is

3:57for you to reduce the complexity as much as possible.

4:00What they suggest you do is rely on a feature in Exchange

4:03called database availability groups.

4:05So rather than relying on a bunch of things

4:07like redundant network connections

4:09and RAID disk installments, all of which

4:11have their own complexity and costs in implementing,

4:13as well as their own potential failure points,

4:16you can use database availability groups to simply

4:18replicate your Exchange server in

4:20multiple different locations.

4:21Remember, I talked about the administrative overhead

4:24of ensuring that your data is copied from one server

4:26to another?

4:27Well, that's exactly what a database availability group is.

4:30With a database availability group,

4:31you have one or more copies of your Microsoft Exchange server

4:35running.

4:36And all of the data is copied between those two copies.

4:39All of the members, in fact, of the database availability group

4:42have a replica of the databases that

4:44are stored in that database availability group.

4:46And that means that if one of those servers

4:49goes down-- if you lose storage, if you lose network

4:51connectivity, if any host of software or hardware problems

4:55occur, well, you know that the second member or more members

4:58of the DAG are still available to serve up

5:01those users' mailboxes.

5:02In fact, you can recover the failed disk

5:04from those other servers as well.

5:06That's a part of database availability groups

5:08is recoverability.

5:09So these really cover a lot for you.

5:11And they don't have to be in the same data center.

5:12They can be scattered across multiple data centers

5:14if you want.

5:15Some of the features of database availability groups-- well,

5:18one, you can have up to 16 servers in a DAG.

5:20That means up to 16 different replicas or copies

5:22of each database.

5:23And that means that your database can

5:25be widely scattered geographically,

5:26and they can be highly redundant.

5:28This protects from both software and hardware failures,

5:31because it is a holistic solution, a collective solution

5:35to the server going down.

5:37And because the DAG itself will recognize

5:39when a server is no longer available and redirect user

5:42access to a different copy of the database,

5:44it's going to protect both from software and hardware failures.

5:48Database availability groups allow you to switch over

5:51either administratively, so you can tell the database

5:54availability group to stop using one

5:55copy, one member in the DAG, and start using another one.

5:58But there's also automatic failover.

5:59Like I just talked about, the DAG

6:01itself can recognize when a system has failed and trip

6:04and send users over to a different system.

6:07And you can add servers incrementally.

6:08So when you create your database availability group,

6:10you can add a second server, and then maybe a few weeks later

6:13add a third server.

6:14If you decide you want a fourth one,

6:15you can add that a few months later.

6:17That does not cause any downtime in your DAG.

6:19They simply add incrementally and grow up

6:21too-- well, like we said, a maximum of 16 servers.

6:24So plan to take some time and sit down

6:26and look at your deployment or your planned deployment

6:28and understand where your failure domains are

6:30and how those lines are going to be drawn in your system.

6:33Understand that you should likely

6:34be implementing database availability groups if you want

6:37any sort of high-availability access for your Exchange

6:39database.

6:40And make sure that you document your potential failure points

6:43and how you are going to address those, either

6:45with automated software solutions,

6:47or with DR and business continuity practices documented

6:51and tested by your staff.

6:52I hope this has been informative for you,

6:54and I'd like to thank you for viewing.

0:00The most important part of downtime

0:01that you need to plan for or account for

0:03is the planned downtime, the maintenance

0:05that you intend to do on your servers and services.

0:07After all, it's not just going to be unexpected outages.

0:11Sometimes you purposefully need to pull these things down

0:13in order to apply updates.

0:15So meeting your service level agreement, your SLA,

0:19is critical for your end users.

0:20After all, I don't think you need

0:22me to tell you how important having access to email

0:24is in a modern business.

0:26This is a mission-critical piece of software.

0:28And you need to provide--

0:29well, you really need to provide the most uptime that you can.

0:31But you definitely need to meet the SLA,

0:33the agreement that you make to your users that you'll provide.

0:36And meeting that SLA means planning for downtime.

0:39You are expected to have downtime in your servers,

0:42not just because of unexpected events,

0:44not just because of outages, but because you are planning

0:47to do things and maintain and upgrade and keep

0:48your servers up to date.

0:50And that's going to include operating system

0:51updates to the underlying operating system, exchange

0:54server updates to the exchange software,

0:56network or communication management and updates, things

0:58that might change your routers or your hardware,

1:01even your cables between your computers,

1:03security updates that are going to apply

1:05to all of these different things,

1:06as well as disaster recovery and business continuity testing.

1:09Sometimes you are going to purposefully bring things down

1:12to test and ensure that your plans for recoverability

1:15and keeping your business continuing work

1:17as they are documented.

1:19Now, how to help improve all of this is,

1:21well, an answer that you're going

1:23to be less and less surprised with as this video series

1:26continues.

1:26And that is, of course, the database availability group,

1:29the DAG.

1:30A DAG is going to help reduce your amount of downtime

1:32and improve your maintenance reliability.

1:35It's a bit of a panacea.

1:37It's going to help out in a lot of different ways.

1:39The most notable way that your DAG

1:40is going to help with this is it allows

1:42you to apply updates or maintenance to your servers

1:44in a round robin style.

1:46And what I mean by that is, if you

1:48have a collection of servers running in a database

1:50availability group, you can apply your updates one

1:53at a time.

1:53You bring down one server to apply updates

1:55to run your maintenance to update the security,

1:58and the other two servers pick up the load in the meantime.

2:01Once that one's complete and you verified

2:03that it's updated and running appropriately,

2:05you can move on to the next one and bring it down, and then

2:07move on to the third one once you've completed that one,

2:10and so on and so forth, all the way up

2:11to even if you have a full 16 servers running in your DAG.

2:14So you can continually apply or incrementally

2:17apply these updates without having any downtime at all.

2:19Your servers are simply going to pick up

2:21the slack inside of your DAG so that your users are redirected

2:25to those servers as opposed to the one you're specifically

2:27applying your updates to.

2:30Now, this can also improve the reliability of our updates,

2:32because it allows you to use, well, some really modern DevOps

2:36kind of practices for rolling out these things,

2:38in particular, blue, green, and canary deployments.

2:41These are deployments where you roll out

2:43your updates or your changes to part of your infrastructure,

2:46part of your organization, and then test

2:48and slowly bring that online, and verify

2:50that it's working as intended.

2:52This is all to help develop DevOps, good DevOps

2:55practices, good CI/CD practices, and ensure

2:58that your updates are tested and applied in a production

3:01scenario as best as possible.

3:04Now, applying this downtime and applying this maintenance

3:07really involves a few different steps.

3:09And at a high level, that means bringing the server down

3:11for maintenance, applying the updates,

3:13and then bringing the server back up for maintenance.

3:15In another video, I'm going to walk you

3:16through the specific steps that you're

3:18going to do in PowerShell in order to bring the servers down

3:20appropriately and then bring them back up appropriately

3:23and verify that everything has worked while you've done that.

3:25But for now, just understand the high-level steps.

3:27You need to bring the server into maintenance mode,

3:30then apply your updates, and then bring the server out

3:32of maintenance mode.

3:33So this is planning for downtime in meeting your SLA

3:35with your exchange server and using in particular a database

3:38availability group.

3:39I hope this has been informative for you.

3:41And I'd like to thank you for viewing.

0:00All right, are you ready to create a database availability

0:03group?

0:03Well, let's do exactly that.

0:04But first, I want to establish a few things

0:06that we should be aware of ahead of time before we actually

0:08run the commands-- the PowerShell commands--

0:10to create the DAG for us.

0:11And I am going to call it DAG going forward

0:13because Database Availability Group is a real tongue twister.

0:17So first of all, you may recall that your DAG

0:19can have between 1 and 16 member servers.

0:22Now, you are unlikely to have or run with only

0:25a single-member server.

0:26Obviously if you only have one server,

0:29you don't have any high availability.

0:30And high availability is the entire purpose

0:33of running a DAG.

0:34If you have a DAG with only one member in it

0:35and that member goes down for whatever reason,

0:37well, you're out of luck, just like if you were only

0:40running a single server not inside of a DAG.

0:41So at the very least, you're probably

0:43going to have two member servers in your database availability

0:46group.

0:46We are going to set that up and configure that in this video,

0:49although Microsoft would recommend a minimum of three

0:52to truly be a highly-available solution.

0:54With three member servers, you can

0:55lose one either due to planned maintenance

0:58or an unplanned outage, and you still

1:00have two redundant servers backing you up

1:02for the entirety of that outage on the third server.

1:05So the minimum recommendation is three.

1:07You can run as few as two.

1:09And you should never run just a single one.

1:11However, it's important to note that you can add servers

1:13incrementally to your DAG, so you're never

1:15stuck with the number that you've added.

1:17You can always simply add a new server as needed

1:19once it's up and running and ready to host

1:21copies of your mailboxes.

1:23While we're on that topic, you may

1:25recall that our databases, when I created my mailbox databases

1:28in my video on doing that, were created in a very

1:31specific folder location.

1:33And that folder location is actually really important.

1:35It's critical for a successful DAG implementation

1:38because every member server has to have that same folder

1:41location available to it.

1:43So I created something that looked like this.

1:45I had a folder called ExchangeDatabases

1:47in the C-colon, a subfolder in that called DB01,

1:50and then I had two subfolders, DB01.db and DB01.log.

1:55This exact folder structure has to exist

1:57on all of the member servers inside of my DAG

2:00that are going to host copies of the mailbox databases

2:03that are in there, right up down to the drive letter.

2:06So I'm running it on a C-colon.

2:07I know that there's always going to be a C-colon drive on all

2:09my computers, but if you stored your databases

2:11on a mapped drive, like an E, or F, or S,

2:13or whatever letter you chose, that same letter

2:16drive has to be available on all of your servers.

2:19When DAG copies, and seeds, and synchronizes the databases,

2:22they're going to be located in that same location.

2:25So let's jump into our server and see how we do this.

2:28I currently have three servers running in my environment--

2:31two servers with Microsoft Exchange installed

2:33on them set up and running and a third one

2:35and with just a Windows Server installation.

2:37They are all members of the domain mydomain.com by the way.

2:40I'm here on Exchange Server 01, where I have already created

2:43a couple of databases following my create mailbox databases

2:46video.

2:47And they are in the ExchangeDatabases folder

2:49under DB01 and DB02.

2:51You can see the full folder structure

2:52for each of these databases exists here on the server.

2:56I will launch the Exchange Management Shell,

2:58which is a PowerShell window that

3:00allows me to connect to and run Exchange cmdlets

3:03against my Exchange server.

3:05And the cmdlet in question is going

3:07to be New-DatabaseAvailabilityGroup,

3:09which will create the DAG for me.

3:10I need to give it a name with the name parameter.

3:13I'll call it DAG01.

3:14And I need to specify something called a WitnessServer.

3:17That's where that third Windows Server is coming into play.

3:20We'll cover the file WitnessServer

3:21more in-depth in another video.

3:23The short version of the story is it operates as a tiebreaker

3:26when the members of the DAG cannot come to a majority

3:29agreement on some topic.

3:30So the witness server, in my case,

3:32will be WINSVR-01.mydomain.com and the WitnessDirectory

3:39on that server is going to be C colon backslash DAG01.

3:45Execute this command, and my DAG is going to be created.

3:48So now, the DAG has been created, but that's all it is.

3:50It's a very simple logical structure

3:53that is going to contain my member servers,

3:55but it doesn't have any member servers yet.

3:57You can see right here on screen,

3:58member servers is totally blank right now because nothing

4:01has been added to it yet.

4:02In order to add servers to the DAG,

4:04I'm going to run the Add DatabaseAvailabilityGroupServer

4:07cmdlet.

4:08Very precise, very verbose, like PowerShell often is.

4:11Pass in the identity parameter, which is going to be DAG01,

4:14the database availability group name that I

4:16chose in the earlier cmdlet.

4:17And I need to specify which specific server I want to add.

4:20In this case, it's going to be EXSVR-01.

4:24When I want to do the same thing for EXSVR-02,

4:27I'm going to call exactly this cmdlet, but pass in EXSVR-02.

4:31Before I do that though, what I would like to do is create

4:34the folder structure in Exchange 02,

4:35and so I'm going to bring up that server.

4:38Here it is.

4:38And because this does not have any of those folders on it yet,

4:41when we come to the C drive, it doesn't have anything installed

4:44on it or it doesn't have that folder structure on it,

4:46so I'm going to create it.

4:55OK, and with those folders created,

4:57Exchange Server 02 is now ready to be added to the DAG.

5:01I will run that once the Exchange Sever 01 is finished

5:04adding to the DAG.

5:08There we go.

5:09Looks like it's complete.

5:10I'm simply going to run this cmdlet again, change 01 to 02,

5:13and now once this finishes, both members will be a member

5:15of the DAG.

5:17You can validate that with the Get-DatabaseAvailabilityGroup

5:20cmdlet, pass in DAG01 for the identity, the Status switch,

5:24and then I'm going to pipe this out into a Format-List.

5:27We'll get that out, and we can see

5:28all of the members of our DAG in DAG01

5:30and what their status is, whether or not they are members

5:33and whether or not they're up.

5:35So that is how you create your database availability group

5:38and add your member servers to it.

5:40Importantly, the databases are still not

5:43being made highly available.

5:44They're not being replicated or seeded.

5:46Across the servers, those databases

5:47only exist on the server on which they're created.

5:50In the next video, we're going to talk

5:51about managing these databases and how we can actually

5:54copy them to our various member servers.

5:56I hope this has been informative for you

5:58and I'd like to thank you for viewing.

0:00If you've been following along with this video series,

0:02you know that we now have a database availability

0:04group that doesn't actually yet provide

0:06any high availability for us.

0:08And that's because while we do have multiple servers inside

0:11of our availability group, Exchange Server 01 and 02,

0:14we don't have any of our mailbox databases themselves being

0:17replicated to other servers inside of that group.

0:21Replicating servers in your DAG is, well, a manual process.

0:25You have to indicate which specific databases

0:28you want to be replicated to which servers

0:31in the availability group.

0:32And what that means is that, well, A, of course,

0:34you don't have high availability until you actually

0:36go through this process, but it also

0:38means that, for example, you can pick and choose

0:40how and where you want your databases to be scattered.

0:43Imagine if you had, let's say, you've

0:45got six DAG members scattered across the globe.

0:48You've got them geolocated for georedundancy.

0:51And here, you may have databases A and B.

0:54And you can have them replicated out here.

0:57Maybe you have A here and B here.

0:59And over here, you might have databases C and D,

1:01and you might have C over here and D over here.

1:04And you get the idea, right?

1:06Even though you have six database members,

1:08you may not have six copies of every individual database.

1:11You get to pick and choose which databases have copies

1:13and where those copies are stored.

1:15So there's a lot of flexibility in how

1:17you can design your high-availability solution.

1:20And that includes prioritization,

1:22so that your users can be focused

1:24on a single copy of the database and only

1:27fail over to another copy when that one is not

1:30actually available.

1:31We'll talk about all that right now.

1:33To begin with, let's bring up our Exchange Server.

1:36And I am going to launch my Exchange Management shell

1:39so that we can hit PowerShell.

1:41And I'm going to run the Add-MailboxDatabaseCopy cmdlet.

1:45That makes sense, right?

1:46We're going to add a copy of a mailbox database.

1:48We need an identity to indicate which mailbox we want to copy.

1:53And you could look up the GUID for this mailbox

1:54or you could use the name that you gave it.

1:56In my case, I gave it the name DB01.

1:58Actually, we can see that real quick if we launch our Admin

2:02Center here.

2:03Come down to the Servers, and hit Databases,

2:05and you can see I've got DB01 and 02.

2:08I've also got the default databases that were created

2:10on Exchange Server 01 and 02.

2:11I'm not going to worry about those.

2:13I just want to deal with the ones I created, DB01 and DB02.

2:16I am going to add this to -MailboxServer EXSVR-02.

2:24Now, recall from my video when I set up that server,

2:26I already created the folder structure

2:28that these files need to be stored in.

2:30So you have to have your folder structure replicated

2:33on every server, so that they can store the database

2:36files in the same place that they

2:38are stored on in the primary server where the database was

2:40created.

2:42Execute this cmdlet, and that is going

2:43to begin something called seeding.

2:46Seeding is where the database is copied and moved

2:48from the current active database onto the remote server--

2:52in this case, EXSVR-02.

2:54It doesn't take very long to do.

2:56And if we bounce over to Exchange Server 02,

2:58I should be able to see those files actually coming

3:01into the folder here.

3:03So if I go to my C drive, I already have my exchange

3:05databases DB01 folder, DB01.db.

3:08And look, there it is.

3:09So it is building this folder structure for me,

3:13including the logs here on the Exchange Server 02 server.

3:16If we come back to 01, yup, it's already done.

3:19So I do need to restart the information

3:20store on that service, just like when

3:22I create new mailbox databases.

3:24I have created a new mailbox database on that server.

3:26So before it's actually working, I'll

3:28need to restart that service.

3:30I can take a look at the status of what's

3:31going on here with the Get-MailboxDatabaseCopyStatus.

3:35If I run that cmdlet, and I'm going

3:37to select just a few parameters from the output of that--

3:40Name, Status, ActivationPreference,

3:42and CopyQueueLength-- and take a look at my status here,

3:45I can see that on EXSVR-01, it is mounted

3:48and on EXSVR-02, it is healthy.

3:51The mounted one is preference one.

3:53What that means is like I was talking about before,

3:55that's the server that is going to host the mailbox

3:57database, all else being equal.

3:59Users are going to store and retrieve

4:01their email from the database on that server.

4:03And that server will in turn replicate

4:05that to all of the other copies inside of the DAG.

4:08Whether there's 1, or 2, or 10 different copies,

4:10you're all going through that one server.

4:12You're not being load balanced across multiple databases.

4:15So Exchange Server 01 is activation preference one.

4:19Exchange Server 02 is activation preference two.

4:21If I added a third, it would be three.

4:23And as these servers failed or if they potentially failed,

4:26I would be automatically reduced down to the next preference.

4:30You can use the Set-MailboxDatabase cmdlet

4:32to change the activation preference for a given

4:35copy of your database, so you can pick and choose

4:37which servers are going to be your primary, your secondary,

4:40your tertiary, et cetera.

4:42Otherwise, this looks like a good highly-available database.

4:45I now have DB01 replicated across both my servers.

4:48Importantly, I don't have DB02.

4:50Why not?

4:51I didn't create a copy of it on the other server.

4:53So you can individually create these copies

4:55for these databases using this cmdlet,

4:57and you got to ensure that you have your databases copied

5:00onto multiple servers in order to have high availability

5:03for your mailbox databases.

5:04I hope this has been informative for you,

5:06and I'd like to thank you for viewing.

0:00Once you are using a database availability group,

0:02you introduce some new network traffic

0:04that you need to contend with, specifically

0:06the MAPI traffic, which handles mailbox messaging

0:09to and from your servers, as well as database replication

0:12traffic, which allows your databases to be replicated

0:15or copied from one member of the Dag to another.

0:18Now previously, in older versions of Microsoft Exchange,

0:21Microsoft recommended a somewhat complex configuration

0:25to ensure that these two types of traffic

0:26had their own network connections

0:28and ran on their own network backbones.

0:30But that's no longer the case.

0:32Because data centers and network connectivity

0:34has gotten so robust and so fast,

0:37Microsoft actually now recommends

0:38a much simpler, much more straightforward

0:40single connection use.

0:41Let's talk a little more in-depth

0:43about this network connection that we use for our DAG.

0:46So like I said, you do need to establish or identify

0:49some network connectivity, network paths for these two

0:53types of traffic, your database replication and your MAPI

0:56traffic.

0:57Now, these should be on a single network connection.

1:00And this is actually established automatically for you

1:04when you install and set up your Exchange server

1:07if your network connections meet some specific and pretty

1:11general requirements.

1:13Your DAG network, in order to be a successful DAG network,

1:15needs to have a static IP address, a defined DNS

1:18server, and a default gateway.

1:20If this all sounds like things that you would normally

1:23have on your network interface connection on your server,

1:25well, you're not wrong.

1:26It's pretty straightforward and pretty standard.

1:28And even on my servers that I set up,

1:30I didn't do a single thing to establish network connectivity.

1:34I simply installed Exchange server.

1:36It recognized the network connection.

1:38And you see here if I'm in Exchange Admin Center, when

1:41I select Servers, and go to my Database Availability Groups,

1:44down on the right hand side, DAG network,

1:46I have one called the MAPI DAG network.

1:48It identified the only network connection that I have.

1:50It identified that it met those requirements.

1:53And it set up my network for me.

1:55You can see this in PowerShell as well with the commandlet

1:59get database availability group network.

2:02I run that, and there is my identity

2:04for my group network, the DAG01 backslash MAPI DAG network.

2:08Replication enabled is true.

2:10And it's running on the subnet 223.0 at 24.

2:13And it's up and running.

2:14So that exists there.

2:16And it exists on both my servers.

2:17If I look at Exchange server 02, and I were to launch

2:20the Exchange Management Shell here, same thing.

2:23It also created itself a MAPI DAG network.

2:26Now, this will automatically at least attempt

2:29to create additional networks based

2:30on the number of network interface

2:32connections on my servers.

2:33So my servers right now only have a single connection.

2:36But if I were to bring up my management shell

2:43and give each of my servers a new network connection,

2:46well, let's look at first here, we'll

2:48see that get database availability network now has

2:51two networks up and running.

2:52It found the new network connection.

2:54And it automatically configured it to run on the server for me.

2:58This is an Exchange server 02.

3:00If I jump back to Exchange server 01,

3:02run that command again, there it is on Exchange server 01

3:05as well.

3:06So it created both networks for me

3:08automatically based on the network connections

3:10that are available.

3:11Other than that, there isn't really

3:13much to do to configure your networks for your database

3:16availability groups.

3:17You don't really want to spend a lot of time configuring these.

3:20Microsoft Exchange server is going to identify and recognize

3:23the networks that it can use to communicate DAG traffic.

3:26It is going to recognize whether or not

3:27they are configured properly.

3:29As long as you have at least one good network

3:31that can handle both MAPI and replication traffic,

3:34you are good to go.

3:35And your network is going to work fine.

3:37This is really the kind of thing that Microsoft handles for you,

3:39and you don't need to worry too much about anymore.

3:41So that covers your database availability group networks.

3:44I hope this has been informative for you,

3:45and I'd like to thank you for viewing.

0:00You might recall that when we created our database

0:02availability group, we created something called a file share

0:05witness.

0:06It was just identified as the witness server

0:08along with a directory in our PowerShell commandlet.

0:10And I didn't really extrapolate on what that was.

0:12Well, let's talk about the file share witness.

0:14It's an important part of your database availability group.

0:17And the file share witness acts as a tiebreaker when a quorum

0:20cannot be reached.

0:21This idea of a quorum is really important

0:24when you're working with clustering

0:26software, such as a database availability group.

0:29Imagine the following scenario.

0:31I've got a database availability group

0:33with two servers in it, one and two.

0:35In fact, that's the sample that I've been

0:36using throughout these videos.

0:38I have a two server database availability group.

0:40Let's say we bring down one of those servers in order

0:42for maintenance, or it crashes, or something else happens.

0:45In order for the database availability group

0:48to identify, to decide if that server is up or down,

0:52it needs a majority vote.

0:54A majority of servers have to agree, thumbs up,

0:56that, yep, that server is down.

0:58It's disconnected.

0:59But since only one server is up and running and able to vote,

1:03so to speak, that's only 50%.

1:05The most that we can get here is 50%.

1:08And that is not a majority.

1:10Well, enter the witness server.

1:12Every DAG has to have a witness server identified.

1:14And the witness server is going to operate as the tiebreaker

1:17in that scenario.

1:18It's going to look and say, yeah, you know what?

1:20Server number two is in fact down.

1:22That will get us over the 50% threshold

1:24and, consequently, allow the DAG to identify that that server is

1:27down and stop trying to replicate or send traffic

1:30or users to that server.

1:32So the witness server is basically

1:34used only in this scenario, when you

1:36don't have a full quorum of votes

1:39in order to identify if a member of the DAG is up or down.

1:44Importantly, witness servers can operate as witness servers

1:46for more than one DAG.

1:47So you may have more than one DAG in your network,

1:49and the witness server is able to be

1:51a witness for both of those.

1:53The only real requirement there is

1:54that you have separate folders, separate witness directories

1:57on that server for each DAG.

1:59So you recall, I identified a witness directory as SQL back

2:02slash dag 01 when I created my DAG, well,

2:05you'd have a dag 02 if that was the name of this DAG

2:07for instance, and so on and so forth.

2:09For every DAG that the witness server

2:11was going to operate as a witness of,

2:13it needs to have a separate folder, a separate directory

2:16on the server.

2:17There are very few requirements for the witness server.

2:19But those few requirements that exist are very, very important.

2:23For one, something called the Exchange Trusted Subsystem

2:26has to have local administrator rights.

2:29That's really important.

2:30In order for Exchange to write to that directory,

2:33it needs local admin rights, so it can create that folder

2:35and write out the information and store the information it

2:37needs inside of that C colon back slash dag 01 folder

2:41or whatever you set it up as.

2:43It also needs to be isolated in its own failure domain.

2:45This is not necessarily a requirement.

2:47But it's highly recommended.

2:49After all, if the file share witness is in the same failure

2:51domain as your DAG, and that failure domain goes down,

2:55well, then your file share witness also goes down.

2:57And you've lost that ability for it

2:59to operate independently of the DAG.

3:01Lastly, while it can be an Exchange server,

3:04it cannot be a DAG member, same as the item above.

3:08It really loses all of its benefit

3:10if the file share witness is a DAG member.

3:12So it can be an Exchange server.

3:14And actually, this is a good idea right here.

3:16This will ensure that this configuration is done for you.

3:19That will put the Exchange Trusted

3:20Subsystem as a local admin.

3:22And it will set up any other configurations

3:24that you might need to make it an appropriate witness server.

3:27But it cannot be a DAG member.

3:28So it can be Exchange.

3:29It can't be a member of the DAG.

3:32Lastly, one neat configuration that you

3:34might think about doing to get it truly isolated

3:36and outside of the failure domain of your existing network

3:39is to simply deploy it as a virtual machine in the cloud,

3:41such as on Azure.

3:43You can create a virtual machine on Azure

3:45and identify that as your DAG member.

3:48Of course, that means that the DAG needs

3:49to belong to a domain, and that domain

3:51needs to be connected to the rest of your Exchange

3:54subsystem.

3:55So there is some configuration required there.

3:58We'll talk a little bit more about that in another video

4:00on deploying on Azure.

4:01But the simple fact of the matter

4:03is that's going to get the DAG inside of its own failure

4:05domain because, well, yeah, if your data center's down,

4:08Azure is still going to be up and running for you.

4:10So that's a little bit about how you configure and set up

4:12your file share witness for a database availability group.

4:15I hope this has been informative for you,

4:17and I'd like to thank you for viewing.

0:01Given the nature of IT today, it seems likely

0:04that if you are planning to deploy Microsoft Exchange,

0:07you are probably considering a cloud service

0:09deployment on something like Microsoft Azure.

0:12That makes sense, right?

0:13Exchange needs a lot of servers.

0:14Those servers need a lot of resources.

0:17Well, that's exactly what Azure and other cloud service

0:19providers offer to you at a lower cost than rolling them

0:22out yourself.

0:23You can absolutely do this.

0:24This is a supported deployment for Microsoft Exchange.

0:27It does have a few rules in place, though.

0:29The thing to remember is that deploying

0:31on Microsoft Azure, or really any cloud service

0:33provider, largely mimics the rules for any virtual exchange

0:37deployment.

0:37We talked about deploying exchange

0:38on a virtual environment in a different video

0:41and how there are some rules.

0:42For instance, you need to ensure that you have enough resources

0:46dedicated to those VMs.

0:48That means that you're going to use whatever IaaS,

0:50Infrastructure as a Service, that your cloud

0:52provider offers, such as Azure VMs in the Microsoft Azure

0:55environment.

0:56You need to make sure that those VMs have enough resources

0:59dedicated to them.

1:00One of the cool things about IaaS services like Azure VMs

1:03is there's a lot of dynamic scaling

1:05that can be taken advantage of, so you're only

1:07ever using, and therefore paying for, whatever it is you need.

1:10Well, recall that virtual exchange deployments need

1:13to have those things preset.

1:15They don't want dynamic resource allocation.

1:18They want static resource allocation.

1:20So you need to ensure that your Azure VMs have

1:22enough resources dedicated to them based on your resource

1:25calculator spreadsheet in order to run your exchange

1:28deployment.

1:28You also want to make sure that you're using something

1:31called Azure Premium Storage.

1:32Azure Premium Storage uses SSD drives.

1:35This is going to ensure that you have

1:37enough throughput and enough performance and enough

1:39dedicated storage resources to your exchange machines

1:43to support your Azure deployment.

1:45You need to ensure that you have adequate latency and bandwidth

1:48between your on-premises environment and your cloud

1:50deployment.

1:50Azure recommends a latency of no more than 500

1:53milliseconds round-trip between on-premises and Azure cloud.

1:58And you need enough bandwidth to support

2:00the replication of any data from the Azure deployment

2:02to your on-site.

2:03So again, you sit down with your resource calculator,

2:06that Excel spreadsheet that Microsoft offers, and determine

2:09exactly what it is you need and ensure

2:10that you can get this with your cloud service provider.

2:14Lastly-- and this is kind of an esoteric one--

2:17but mail delivery and reception has

2:19got to be routed through another cloud service.

2:21Azure offers one called Exchange Online Protection.

2:24And this is because the IP address space of the Microsoft

2:27Azure deployment is going to be blocked for a lot of sending

2:30and receiving emails.

2:31This is spam protection.

2:32This is something that is implemented in order to ensure

2:35that people don't leverage Azure to-- well, to send out

2:38a bunch of spam to violate a bunch of mail rules.

2:40So you need to route everything through another service

2:43like Exchange Online Protection.

2:45Even if you're not going to go with a full Azure deployment,

2:47one thing that you might consider doing

2:49is using Azure for your file share witness server.

2:53Recall that your file share witness

2:54server operates as a tiebreaker and needs to be able to look at

2:58and see and determine the status of individual DAG members.

3:02But ideally, you want your file share witness

3:03at an isolated location-- geographically isolated,

3:06if you can.

3:07Well, not every company has the resources

3:09to afford a second geographic data center totally isolated

3:12and separate from their primary data center.

3:15This is where Azure comes in.

3:17With Microsoft Azure, you can leverage an Azure data center

3:20as your isolated second or third or fourth or fifth

3:22location for your file share witness

3:25and ensure that if you have a problem in your data center,

3:28the file share witness is not impacted and therefore can

3:31view that problem and help report and understand

3:33what's going on.

3:34To deploy file share witness in Azure

3:37is relatively straightforward.

3:38You do require two things, though.

3:40One, you need a multi-site VPN.

3:42This is a feature of Azure that allows

3:44you to connect multiple VPN sites to your Azure site.

3:48And two, you will need two servers inside of Azure.

3:51One is the file share witness.

3:53And one is the domain controller.

3:54Now, technically, these could be the same machine.

3:57Microsoft really does not recommend

3:59making a domain controller your file share witness.

4:02The recommended deployment is two servers,

4:03one for the witness, one for the domain controller.

4:06And this tripped me up a little bit at first.

4:08I was wondering why we needed another domain controller

4:10in Azure.

4:11If you have a multi-site VPN, then your file share witness

4:14is connected to domain controllers inside

4:16of your existing network.

4:17The answer is, it needs to operate inside

4:19of its own independent Active Directory

4:21subnet, its own isolated IP subnet,

4:23because it's over the VPN.

4:25And because it's in its own subnet,

4:26that means it needs its own domain controller also located

4:29inside of that subnet.

4:30You can learn all about Active Directory

4:32and subnets in the video 70-742 on identity

4:36with Microsoft server.

4:38So this covers the different Azure

4:40deployments that you can do with Microsoft Exchange Server.

4:42I hope has been informative for you,

4:44and I'd like to thank you for viewing.