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

0:00Email may well seem like an old fashioned technology at this point, but it continues to be a mission-critical piece of enterprise software for every organization. All of us rely heavily on email. And if you're going to be deploying and running your own email server with Microsoft Exchange, you want to ensure that the normal hiccups and routine maintenance that occur within a computer network don't disable or bring down access to your entire email infrastructure. So in these videos, we'll talk a little bit about how you can set up some high availability solutions to ensure that your email or your exchange deployment can weather those problems.

0:34We will talk about isolating fault domains. We'll talk about setting up DAGs in the file share witness, and even briefly a little bit about how you can deploy on the Microsoft Azure cloud platform for even more redundancy. So stick around. I'm glad you're here. This is a pretty interesting topic, and we have a lot to learn.

0:00I'm not going to lie. I find the concept of identifying failure domains to be kind of interesting and cool. And it's all about recognizing in your systems where failures may occur that would actually have systemic or system-wide impacts. A failure domain is a way of thinking about encompassing or enclosing a portion of your system, of your deployment, both physical and logical, software and hardware, that is self-contained and is either going to work or fail together as a unit. So it's a little bit of a difficult concept to get your head around at first.

0:31But I think once we think about it some and provide some examples, you'll start to get the hang of it. So first of all, you need to understand, or you need to recognize that your systems are going to fail. I'm sorry. I don't care how good at this job you are, eventually, something is going to go wrong. There is going to be a problem. And DR is all about having a plan to deal with those problems when they occur. But you cannot deal with those problems until you recognize how those problems are going to impact your wider system. And one of the first steps in doing that is identifying these things that we call failure domains. In a failure domain, we want to encompass a physical or logical section of our processing and computing environment.

1:07So what does that mean? Well, think about if you were running Microsoft Exchange on a single server. You might consider this server to be a failure domain. After all, if there is any problem on this server, if it loses power, if the hard drive fails, if the operating system gets corrupt-- any issue with this server, and you have a failure in your system. Your Exchange databases are no longer accessible. Users can no longer get to their email. Exchange is down. That's bad. So a single server running a single piece of your software would be considered a failure domain.

1:37And one of the ways that you might extend or expand or create some higher availability is to simply run two servers, right? Now, you'd have one run server and a second backup server. And now, you have two separate failure domains. One server may crash, may go down, but it's unlikely that both servers will go down at the same time. Of course, this can introduce its own challenges as well. After all, first of all, you need some way to copy or replicate your data between those two servers. And you need some way to know if one server has gone down that everyone should be switching over and accessing the second server.

2:10You also have a new failure domain in that, say, for instance, if this network communication between these two servers goes down, well, you have a different problem altogether. You also have a total encompassed failure domain. If these are all in the same data center, for instance, and what happens if that data center loses power? So that data center is a failure domain as well, which you might solve by creating a couple of data centers. This is called geo-replication or geo-redundancy. They are physically separated geographically, your two servers, so that if one data center goes down for whatever reason, your second data center is still up and running.

2:42And you can introduce a lot of these. You may have two or three or four or five different geo-replicated centers. Now, one of the things you start to notice here, of course, is that, well, not only do we also have network communication between these data centers, which is a potential failure point, but this is starting to get very complex and costly. Not every organization is going to have the ability to replicate their systems over a wide geographic area and many different data centers. Cloud deployments are certainly making this more possible and more widely accessible. But the simple fact of the matter is, at a certain point, you're going to look at ways that you reduce your risk or reduce your chances of failure as being too costly and not worth the effort.

3:20So identifying failure domains is not just about identifying how your system can fail, but it's also about recognizing which failure points you are actually in a position to address and which failure points are going to be too complex to reasonably address, and instead, you want to have a recovery plan in place for when those failures occur. There is no hard, fast rules. There's no technical document that explains exactly how to do this. It's going to be different for every organization and every budget and every deployment scenario. The first step, like we're saying, is to identify these domains so you can understand how to address the potential issues of failure.

3:53Now, one of the things that Microsoft recommends in their preferred architecture is for you to reduce the complexity as much as possible. What they suggest you do is rely on a feature in Exchange called database availability groups. So rather than relying on a bunch of things like redundant network connections and RAID disk installments, all of which have their own complexity and costs in implementing, as well as their own potential failure points, you can use database availability groups to simply replicate your Exchange server in multiple different locations. Remember, I talked about the administrative overhead of ensuring that your data is copied from one server to another?

4:27Well, that's exactly what a database availability group is. With a database availability group, you have one or more copies of your Microsoft Exchange server running. And all of the data is copied between those two copies. All of the members, in fact, of the database availability group have a replica of the databases that are stored in that database availability group. And that means that if one of those servers goes down-- if you lose storage, if you lose network connectivity, if any host of software or hardware problems occur, well, you know that the second member or more members of the DAG are still available to serve up those users' mailboxes.

5:02In fact, you can recover the failed disk from those other servers as well. That's a part of database availability groups is recoverability. So these really cover a lot for you. And they don't have to be in the same data center. They can be scattered across multiple data centers if you want. Some of the features of database availability groups-- well, one, you can have up to 16 servers in a DAG. That means up to 16 different replicas or copies of each database. And that means that your database can be widely scattered geographically, and they can be highly redundant. This protects from both software and hardware failures, because it is a holistic solution, a collective solution to the server going down.

5:37And because the DAG itself will recognize when a server is no longer available and redirect user access to a different copy of the database, it's going to protect both from software and hardware failures. Database availability groups allow you to switch over either administratively, so you can tell the database availability group to stop using one copy, one member in the DAG, and start using another one. But there's also automatic failover. Like I just talked about, the DAG itself can recognize when a system has failed and trip and send users over to a different system. And you can add servers incrementally.

6:08So when you create your database availability group, you can add a second server, and then maybe a few weeks later add a third server. If you decide you want a fourth one, you can add that a few months later. That does not cause any downtime in your DAG. They simply add incrementally and grow up too-- well, like we said, a maximum of 16 servers. So plan to take some time and sit down and look at your deployment or your planned deployment and understand where your failure domains are and how those lines are going to be drawn in your system. Understand that you should likely be implementing database availability groups if you want any sort of high-availability access for your Exchange database.

6:40And make sure that you document your potential failure points and how you are going to address those, either with automated software solutions, or with DR and business continuity practices documented and tested by your staff. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00The most important part of downtime that you need to plan for or account for is the planned downtime, the maintenance that you intend to do on your servers and services. After all, it's not just going to be unexpected outages. Sometimes you purposefully need to pull these things down in order to apply updates. So meeting your service level agreement, your SLA, is critical for your end users. After all, I don't think you need me to tell you how important having access to email is in a modern business. This is a mission-critical piece of software. And you need to provide-- well, you really need to provide the most uptime that you can.

0:31But you definitely need to meet the SLA, the agreement that you make to your users that you'll provide. And meeting that SLA means planning for downtime. You are expected to have downtime in your servers, not just because of unexpected events, not just because of outages, but because you are planning to do things and maintain and upgrade and keep your servers up to date. And that's going to include operating system updates to the underlying operating system, exchange server updates to the exchange software, network or communication management and updates, things that might change your routers or your hardware, even your cables between your computers, security updates that are going to apply to all of these different things, as well as disaster recovery and business continuity testing.

1:09Sometimes you are going to purposefully bring things down to test and ensure that your plans for recoverability and keeping your business continuing work as they are documented. Now, how to help improve all of this is, well, an answer that you're going to be less and less surprised with as this video series continues. And that is, of course, the database availability group, the DAG. A DAG is going to help reduce your amount of downtime and improve your maintenance reliability. It's a bit of a panacea. It's going to help out in a lot of different ways. The most notable way that your DAG is going to help with this is it allows you to apply updates or maintenance to your servers in a round robin style.

1:46And what I mean by that is, if you have a collection of servers running in a database availability group, you can apply your updates one at a time. You bring down one server to apply updates to run your maintenance to update the security, and the other two servers pick up the load in the meantime. Once that one's complete and you verified that it's updated and running appropriately, you can move on to the next one and bring it down, and then move on to the third one once you've completed that one, and so on and so forth, all the way up to even if you have a full 16 servers running in your DAG. So you can continually apply or incrementally apply these updates without having any downtime at all.

2:19Your servers are simply going to pick up the slack inside of your DAG so that your users are redirected to those servers as opposed to the one you're specifically applying your updates to. Now, this can also improve the reliability of our updates, because it allows you to use, well, some really modern DevOps kind of practices for rolling out these things, in particular, blue, green, and canary deployments. These are deployments where you roll out your updates or your changes to part of your infrastructure, part of your organization, and then test and slowly bring that online, and verify that it's working as intended.

2:52This is all to help develop DevOps, good DevOps practices, good CI/CD practices, and ensure that your updates are tested and applied in a production scenario as best as possible. Now, applying this downtime and applying this maintenance really involves a few different steps. And at a high level, that means bringing the server down for maintenance, applying the updates, and then bringing the server back up for maintenance. In another video, I'm going to walk you through the specific steps that you're going to do in PowerShell in order to bring the servers down appropriately and then bring them back up appropriately and verify that everything has worked while you've done that.

3:25But for now, just understand the high-level steps. You need to bring the server into maintenance mode, then apply your updates, and then bring the server out of maintenance mode. So this is planning for downtime in meeting your SLA with your exchange server and using in particular a database availability group. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00All right, are you ready to create a database availability group? Well, let's do exactly that. But first, I want to establish a few things that we should be aware of ahead of time before we actually run the commands-- the PowerShell commands-- to create the DAG for us. And I am going to call it DAG going forward because Database Availability Group is a real tongue twister. So first of all, you may recall that your DAG can have between 1 and 16 member servers. Now, you are unlikely to have or run with only a single-member server. Obviously if you only have one server, you don't have any high availability.

0:30And high availability is the entire purpose of running a DAG. If you have a DAG with only one member in it and that member goes down for whatever reason, well, you're out of luck, just like if you were only running a single server not inside of a DAG. So at the very least, you're probably going to have two member servers in your database availability group. We are going to set that up and configure that in this video, although Microsoft would recommend a minimum of three to truly be a highly-available solution. With three member servers, you can lose one either due to planned maintenance or an unplanned outage, and you still have two redundant servers backing you up for the entirety of that outage on the third server.

1:05So the minimum recommendation is three. You can run as few as two. And you should never run just a single one. However, it's important to note that you can add servers incrementally to your DAG, so you're never stuck with the number that you've added. You can always simply add a new server as needed once it's up and running and ready to host copies of your mailboxes. While we're on that topic, you may recall that our databases, when I created my mailbox databases in my video on doing that, were created in a very specific folder location. And that folder location is actually really important.

1:35It's critical for a successful DAG implementation because every member server has to have that same folder location available to it. So I created something that looked like this. I had a folder called ExchangeDatabases in the C-colon, a subfolder in that called DB01, and then I had two subfolders, DB01.db and DB01.log. This exact folder structure has to exist on all of the member servers inside of my DAG that are going to host copies of the mailbox databases that are in there, right up down to the drive letter.

2:06So I'm running it on a C-colon. I know that there's always going to be a C-colon drive on all my computers, but if you stored your databases on a mapped drive, like an E, or F, or S, or whatever letter you chose, that same letter drive has to be available on all of your servers. When DAG copies, and seeds, and synchronizes the databases, they're going to be located in that same location. So let's jump into our server and see how we do this. I currently have three servers running in my environment-- two servers with Microsoft Exchange installed on them set up and running and a third one and with just a Windows Server installation.

2:37They are all members of the domain mydomain.com by the way. I'm here on Exchange Server 01, where I have already created a couple of databases following my create mailbox databases video. And they are in the ExchangeDatabases folder under DB01 and DB02. You can see the full folder structure for each of these databases exists here on the server. I will launch the Exchange Management Shell, which is a PowerShell window that allows me to connect to and run Exchange cmdlets against my Exchange server. And the cmdlet in question is going to be New-DatabaseAvailabilityGroup, which will create the DAG for me.

3:10I need to give it a name with the name parameter. I'll call it DAG01. And I need to specify something called a WitnessServer. That's where that third Windows Server is coming into play. We'll cover the file WitnessServer more in-depth in another video. The short version of the story is it operates as a tiebreaker when the members of the DAG cannot come to a majority agreement on some topic. So the witness server, in my case, will be WINSVR-01.mydomain.com and the WitnessDirectory on that server is going to be C colon backslash DAG01.

3:45Execute this command, and my DAG is going to be created. So now, the DAG has been created, but that's all it is. It's a very simple logical structure that is going to contain my member servers, but it doesn't have any member servers yet. You can see right here on screen, member servers is totally blank right now because nothing has been added to it yet. In order to add servers to the DAG, I'm going to run the Add DatabaseAvailabilityGroupServer cmdlet. Very precise, very verbose, like PowerShell often is. Pass in the identity parameter, which is going to be DAG01, the database availability group name that I chose in the earlier cmdlet.

4:17And I need to specify which specific server I want to add. In this case, it's going to be EXSVR-01. When I want to do the same thing for EXSVR-02, I'm going to call exactly this cmdlet, but pass in EXSVR-02. Before I do that though, what I would like to do is create the folder structure in Exchange 02, and so I'm going to bring up that server. Here it is. And because this does not have any of those folders on it yet, when we come to the C drive, it doesn't have anything installed on it or it doesn't have that folder structure on it, so I'm going to create it.

4:55OK, and with those folders created, Exchange Server 02 is now ready to be added to the DAG. I will run that once the Exchange Sever 01 is finished adding to the DAG. There we go. Looks like it's complete. I'm simply going to run this cmdlet again, change 01 to 02, and now once this finishes, both members will be a member of the DAG. You can validate that with the Get-DatabaseAvailabilityGroup cmdlet, pass in DAG01 for the identity, the Status switch, and then I'm going to pipe this out into a Format-List.

5:27We'll get that out, and we can see all of the members of our DAG in DAG01 and what their status is, whether or not they are members and whether or not they're up. So that is how you create your database availability group and add your member servers to it. Importantly, the databases are still not being made highly available. They're not being replicated or seeded. Across the servers, those databases only exist on the server on which they're created. In the next video, we're going to talk about managing these databases and how we can actually copy them to our various member servers. I hope this has been informative for you and I'd like to thank you for viewing.

0:00If you've been following along with this video series, you know that we now have a database availability group that doesn't actually yet provide any high availability for us. And that's because while we do have multiple servers inside of our availability group, Exchange Server 01 and 02, we don't have any of our mailbox databases themselves being replicated to other servers inside of that group. Replicating servers in your DAG is, well, a manual process. You have to indicate which specific databases you want to be replicated to which servers in the availability group.

0:32And what that means is that, well, A, of course, you don't have high availability until you actually go through this process, but it also means that, for example, you can pick and choose how and where you want your databases to be scattered. Imagine if you had, let's say, you've got six DAG members scattered across the globe. You've got them geolocated for georedundancy. And here, you may have databases A and B. And you can have them replicated out here. Maybe you have A here and B here. And over here, you might have databases C and D, and you might have C over here and D over here.

1:04And you get the idea, right? Even though you have six database members, you may not have six copies of every individual database. You get to pick and choose which databases have copies and where those copies are stored. So there's a lot of flexibility in how you can design your high-availability solution. And that includes prioritization, so that your users can be focused on a single copy of the database and only fail over to another copy when that one is not actually available. We'll talk about all that right now. To begin with, let's bring up our Exchange Server.

1:36And I am going to launch my Exchange Management shell so that we can hit PowerShell. And I'm going to run the Add-MailboxDatabaseCopy cmdlet. That makes sense, right? We're going to add a copy of a mailbox database. We need an identity to indicate which mailbox we want to copy. And you could look up the GUID for this mailbox or you could use the name that you gave it. In my case, I gave it the name DB01. Actually, we can see that real quick if we launch our Admin Center here. Come down to the Servers, and hit Databases, and you can see I've got DB01 and 02.

2:08I've also got the default databases that were created on Exchange Server 01 and 02. I'm not going to worry about those. I just want to deal with the ones I created, DB01 and DB02. I am going to add this to -MailboxServer EXSVR-02. Now, recall from my video when I set up that server, I already created the folder structure that these files need to be stored in. So you have to have your folder structure replicated on every server, so that they can store the database files in the same place that they are stored on in the primary server where the database was created.

2:42Execute this cmdlet, and that is going to begin something called seeding. Seeding is where the database is copied and moved from the current active database onto the remote server-- in this case, EXSVR-02. It doesn't take very long to do. And if we bounce over to Exchange Server 02, I should be able to see those files actually coming into the folder here. So if I go to my C drive, I already have my exchange databases DB01 folder, DB01.db. And look, there it is. So it is building this folder structure for me, including the logs here on the Exchange Server 02 server.

3:16If we come back to 01, yup, it's already done. So I do need to restart the information store on that service, just like when I create new mailbox databases. I have created a new mailbox database on that server. So before it's actually working, I'll need to restart that service. I can take a look at the status of what's going on here with the Get-MailboxDatabaseCopyStatus. If I run that cmdlet, and I'm going to select just a few parameters from the output of that-- Name, Status, ActivationPreference, and CopyQueueLength-- and take a look at my status here, I can see that on EXSVR-01, it is mounted and on EXSVR-02, it is healthy.

3:51The mounted one is preference one. What that means is like I was talking about before, that's the server that is going to host the mailbox database, all else being equal. Users are going to store and retrieve their email from the database on that server. And that server will in turn replicate that to all of the other copies inside of the DAG. Whether there's 1, or 2, or 10 different copies, you're all going through that one server. You're not being load balanced across multiple databases. So Exchange Server 01 is activation preference one. Exchange Server 02 is activation preference two.

4:21If I added a third, it would be three. And as these servers failed or if they potentially failed, I would be automatically reduced down to the next preference. You can use the Set-MailboxDatabase cmdlet to change the activation preference for a given copy of your database, so you can pick and choose which servers are going to be your primary, your secondary, your tertiary, et cetera. Otherwise, this looks like a good highly-available database. I now have DB01 replicated across both my servers. Importantly, I don't have DB02. Why not? I didn't create a copy of it on the other server.

4:53So you can individually create these copies for these databases using this cmdlet, and you got to ensure that you have your databases copied onto multiple servers in order to have high availability for your mailbox databases. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Once you are using a database availability group, you introduce some new network traffic that you need to contend with, specifically the MAPI traffic, which handles mailbox messaging to and from your servers, as well as database replication traffic, which allows your databases to be replicated or copied from one member of the Dag to another. Now previously, in older versions of Microsoft Exchange, Microsoft recommended a somewhat complex configuration to ensure that these two types of traffic had their own network connections and ran on their own network backbones. But that's no longer the case.

0:32Because data centers and network connectivity has gotten so robust and so fast, Microsoft actually now recommends a much simpler, much more straightforward single connection use. Let's talk a little more in-depth about this network connection that we use for our DAG. So like I said, you do need to establish or identify some network connectivity, network paths for these two types of traffic, your database replication and your MAPI traffic. Now, these should be on a single network connection. And this is actually established automatically for you when you install and set up your Exchange server if your network connections meet some specific and pretty general requirements.

1:13Your DAG network, in order to be a successful DAG network, needs to have a static IP address, a defined DNS server, and a default gateway. If this all sounds like things that you would normally have on your network interface connection on your server, well, you're not wrong. It's pretty straightforward and pretty standard. And even on my servers that I set up, I didn't do a single thing to establish network connectivity. I simply installed Exchange server. It recognized the network connection. And you see here if I'm in Exchange Admin Center, when I select Servers, and go to my Database Availability Groups, down on the right hand side, DAG network, I have one called the MAPI DAG network.

1:48It identified the only network connection that I have. It identified that it met those requirements. And it set up my network for me. You can see this in PowerShell as well with the commandlet get database availability group network. I run that, and there is my identity for my group network, the DAG01 backslash MAPI DAG network. Replication enabled is true. And it's running on the subnet 223.0 at 24. And it's up and running. So that exists there. And it exists on both my servers. If I look at Exchange server 02, and I were to launch the Exchange Management Shell here, same thing.

2:23It also created itself a MAPI DAG network. Now, this will automatically at least attempt to create additional networks based on the number of network interface connections on my servers. So my servers right now only have a single connection. But if I were to bring up my management shell and give each of my servers a new network connection, well, let's look at first here, we'll see that get database availability network now has two networks up and running. It found the new network connection.

2:54And it automatically configured it to run on the server for me. This is an Exchange server 02. If I jump back to Exchange server 01, run that command again, there it is on Exchange server 01 as well. So it created both networks for me automatically based on the network connections that are available. Other than that, there isn't really much to do to configure your networks for your database availability groups. You don't really want to spend a lot of time configuring these. Microsoft Exchange server is going to identify and recognize the networks that it can use to communicate DAG traffic.

3:26It is going to recognize whether or not they are configured properly. As long as you have at least one good network that can handle both MAPI and replication traffic, you are good to go. And your network is going to work fine. This is really the kind of thing that Microsoft handles for you, and you don't need to worry too much about anymore. So that covers your database availability group networks. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00You might recall that when we created our database availability group, we created something called a file share witness. It was just identified as the witness server along with a directory in our PowerShell commandlet. And I didn't really extrapolate on what that was. Well, let's talk about the file share witness. It's an important part of your database availability group. And the file share witness acts as a tiebreaker when a quorum cannot be reached. This idea of a quorum is really important when you're working with clustering software, such as a database availability group. Imagine the following scenario.

0:31I've got a database availability group with two servers in it, one and two. In fact, that's the sample that I've been using throughout these videos. I have a two server database availability group. Let's say we bring down one of those servers in order for maintenance, or it crashes, or something else happens. In order for the database availability group to identify, to decide if that server is up or down, it needs a majority vote. A majority of servers have to agree, thumbs up, that, yep, that server is down. It's disconnected. But since only one server is up and running and able to vote, so to speak, that's only 50%.

1:05The most that we can get here is 50%. And that is not a majority. Well, enter the witness server. Every DAG has to have a witness server identified. And the witness server is going to operate as the tiebreaker in that scenario. It's going to look and say, yeah, you know what? Server number two is in fact down. That will get us over the 50% threshold and, consequently, allow the DAG to identify that that server is down and stop trying to replicate or send traffic or users to that server. So the witness server is basically used only in this scenario, when you don't have a full quorum of votes in order to identify if a member of the DAG is up or down.

1:44Importantly, witness servers can operate as witness servers for more than one DAG. So you may have more than one DAG in your network, and the witness server is able to be a witness for both of those. The only real requirement there is that you have separate folders, separate witness directories on that server for each DAG. So you recall, I identified a witness directory as SQL back slash dag 01 when I created my DAG, well, you'd have a dag 02 if that was the name of this DAG for instance, and so on and so forth. For every DAG that the witness server was going to operate as a witness of, it needs to have a separate folder, a separate directory on the server.

2:17There are very few requirements for the witness server. But those few requirements that exist are very, very important. For one, something called the Exchange Trusted Subsystem has to have local administrator rights. That's really important. In order for Exchange to write to that directory, it needs local admin rights, so it can create that folder and write out the information and store the information it needs inside of that C colon back slash dag 01 folder or whatever you set it up as. It also needs to be isolated in its own failure domain. This is not necessarily a requirement.

2:47But it's highly recommended. After all, if the file share witness is in the same failure domain as your DAG, and that failure domain goes down, well, then your file share witness also goes down. And you've lost that ability for it to operate independently of the DAG. Lastly, while it can be an Exchange server, it cannot be a DAG member, same as the item above. It really loses all of its benefit if the file share witness is a DAG member. So it can be an Exchange server. And actually, this is a good idea right here. This will ensure that this configuration is done for you.

3:19That will put the Exchange Trusted Subsystem as a local admin. And it will set up any other configurations that you might need to make it an appropriate witness server. But it cannot be a DAG member. So it can be Exchange. It can't be a member of the DAG. Lastly, one neat configuration that you might think about doing to get it truly isolated and outside of the failure domain of your existing network is to simply deploy it as a virtual machine in the cloud, such as on Azure. You can create a virtual machine on Azure and identify that as your DAG member. Of course, that means that the DAG needs to belong to a domain, and that domain needs to be connected to the rest of your Exchange subsystem.

3:55So there is some configuration required there. We'll talk a little bit more about that in another video on deploying on Azure. But the simple fact of the matter is that's going to get the DAG inside of its own failure domain because, well, yeah, if your data center's down, Azure is still going to be up and running for you. So that's a little bit about how you configure and set up your file share witness for a database availability group. I hope this has been informative for you, and I'd like to thank you for viewing.

0:01Given the nature of IT today, it seems likely that if you are planning to deploy Microsoft Exchange, you are probably considering a cloud service deployment on something like Microsoft Azure. That makes sense, right? Exchange needs a lot of servers. Those servers need a lot of resources. Well, that's exactly what Azure and other cloud service providers offer to you at a lower cost than rolling them out yourself. You can absolutely do this. This is a supported deployment for Microsoft Exchange. It does have a few rules in place, though. The thing to remember is that deploying on Microsoft Azure, or really any cloud service provider, largely mimics the rules for any virtual exchange deployment.

0:37We talked about deploying exchange on a virtual environment in a different video and how there are some rules. For instance, you need to ensure that you have enough resources dedicated to those VMs. That means that you're going to use whatever IaaS, Infrastructure as a Service, that your cloud provider offers, such as Azure VMs in the Microsoft Azure environment. You need to make sure that those VMs have enough resources dedicated to them. One of the cool things about IaaS services like Azure VMs is there's a lot of dynamic scaling that can be taken advantage of, so you're only ever using, and therefore paying for, whatever it is you need.

1:10Well, recall that virtual exchange deployments need to have those things preset. They don't want dynamic resource allocation. They want static resource allocation. So you need to ensure that your Azure VMs have enough resources dedicated to them based on your resource calculator spreadsheet in order to run your exchange deployment. You also want to make sure that you're using something called Azure Premium Storage. Azure Premium Storage uses SSD drives. This is going to ensure that you have enough throughput and enough performance and enough dedicated storage resources to your exchange machines to support your Azure deployment.

1:45You need to ensure that you have adequate latency and bandwidth between your on-premises environment and your cloud deployment. Azure recommends a latency of no more than 500 milliseconds round-trip between on-premises and Azure cloud. And you need enough bandwidth to support the replication of any data from the Azure deployment to your on-site. So again, you sit down with your resource calculator, that Excel spreadsheet that Microsoft offers, and determine exactly what it is you need and ensure that you can get this with your cloud service provider. Lastly-- and this is kind of an esoteric one-- but mail delivery and reception has got to be routed through another cloud service.

2:21Azure offers one called Exchange Online Protection. And this is because the IP address space of the Microsoft Azure deployment is going to be blocked for a lot of sending and receiving emails. This is spam protection. This is something that is implemented in order to ensure that people don't leverage Azure to-- well, to send out a bunch of spam to violate a bunch of mail rules. So you need to route everything through another service like Exchange Online Protection. Even if you're not going to go with a full Azure deployment, one thing that you might consider doing is using Azure for your file share witness server.

2:53Recall that your file share witness server operates as a tiebreaker and needs to be able to look at and see and determine the status of individual DAG members. But ideally, you want your file share witness at an isolated location-- geographically isolated, if you can. Well, not every company has the resources to afford a second geographic data center totally isolated and separate from their primary data center. This is where Azure comes in. With Microsoft Azure, you can leverage an Azure data center as your isolated second or third or fourth or fifth location for your file share witness and ensure that if you have a problem in your data center, the file share witness is not impacted and therefore can view that problem and help report and understand what's going on.

3:34To deploy file share witness in Azure is relatively straightforward. You do require two things, though. One, you need a multi-site VPN. This is a feature of Azure that allows you to connect multiple VPN sites to your Azure site. And two, you will need two servers inside of Azure. One is the file share witness. And one is the domain controller. Now, technically, these could be the same machine. Microsoft really does not recommend making a domain controller your file share witness. The recommended deployment is two servers, one for the witness, one for the domain controller.

4:06And this tripped me up a little bit at first. I was wondering why we needed another domain controller in Azure. If you have a multi-site VPN, then your file share witness is connected to domain controllers inside of your existing network. The answer is, it needs to operate inside of its own independent Active Directory subnet, its own isolated IP subnet, because it's over the VPN. And because it's in its own subnet, that means it needs its own domain controller also located inside of that subnet. You can learn all about Active Directory and subnets in the video 70-742 on identity with Microsoft server.

4:38So this covers the different Azure deployments that you can do with Microsoft Exchange Server. I hope has been informative for you, and I'd like to thank you for viewing.