First published on TECHNET on Jan 27, 2015
~ John Patterson
This article will guide you through the recommended way to setup and configure a typical, highly available (HA) System Center 2012 R2 Virtual Machine Manager (VMM) and later installation. While this topic was written for System Center 2012 R2 Virtual Machine Manager, it also applies to later versions including System Center 2016 Virtual Machine Manager. Some screenshots may not reflect changes in the UI since 2012 R2. Topics we’ll cover include the following:
In any VMM installation there are three primary servers that you’ll need to be concerned with. As a note, a production VMM environment will likely have other servers within it such as System Center Operations Manager (OpsMgr) and System Center Data Protection Manager (DPM). VMM can also integrate with other infrastructure servers such as WDS and WSUS servers for deployment and patching workflows respectively. However, for the purpose of this article we will ignore these other servers as they mostly integrate with VMM and are not really a part of the VMM installation itself.
With these three servers in mind, we recommend following these guidelines when installing VMM in your production environment:
(1) Use a highly available installation of SQL Server (if using AlwaysOn see the note* below)
(2) Use a highly available installation of VMM.
(3) Install the highly available installation of SQL Server on a separate failover cluster from the failover cluster on which VMM is installed.
* When using SQL AlwaysOn in asynchronous-commit mode (the mode most of our customers use) there is a chance that the primary replica dies and failover to the secondary replica occurs while the secondary replica lags behind the primary database. Essentially some data loss is possible ( https://msdn.microsoft.com/en-us/library/ff877884.aspx#AvailabilityModes ). If this happens, VMM will failover to the secondary replica and the database VMM references will have gone "back in time." This is similar to restoring from a backup that is out of date by a few VMM transactions. If this happens there can be security risks such as information disclosure. We support AlwaysOn, but be aware that asynchronous replication has its risks.
In this article we’ll be setting up and configuring a highly available VMM installation on a two node Windows Failover Cluster along with some of the less obvious objects required for a HA installation. I’ll assume you already have a highly available SQL server installation, however there is a very informative MSDN article on various high availability MSSQL solutions at http://msdn.microsoft.com/en-us/library/ms190202.aspx that I suggest you read to discover the different HA SQL solutions available and how to configure the HA SQL solution that is appropriate for you. I also won’t go into setting up a file server cluster to use as a highly available library server. In short, I’ll stick to setting up VMM.
The first order of business when installing a highly available VMM server is to set up a domain account for the VMM service to use. There are no requirements for this account except that it must be a member of the Local Administrators group on each of the nodes in the cluster that VMM is installed on. We refer to this account as the VMM Service Account and it needs to be created in Active Directory before VMM is installed.
Creating the VMM Service Account
(1) Open Active Directory Users and Computers (dsa.msc)
(2) Expand the domain that contains the VMM cluster and right-click on the User folder in the left pane. Then select New > User
(3) Provide the appropriate account details and select Next
(4) Provide a password and set the appropriate password policy settings. Then click Next
(5) Select Finish and complete the wizard.
(6) Close Active Directory Users and Computers
Add the VMM Service Account to the Local Administrator Group on the VMM Nodes
(1) On each node that will be a member of the failover cluster you plan on installing VMM on, open Control Panel
(2) In the top right select View By: Category
(3) Click User Accounts
(4) Again click User Accounts
(5) Select Manage User Accounts
(6) In the pop-up, click the Add… button
(7) Supply the username and domain name for the VMM Service Account we just created
(8) Select Administrator as the level of access for this account
(9) Click Finish to complete the wizard
VMM stores Run As Accounts (RAAs) in its database to manage VM hosts, file servers, VMs, and many other credential-required resources. Essentially this results in VMM storing usernames and passwords in its database and, as security is a paramount concern in any environment, these usernames and passwords have to be encrypted. There are two ways to encrypt this data in a standalone VMM installation: DPAPI and DKM.
DPAPI: When choosing to use DPAPI for encryption, VMM essentially uses the hardware ID of the physical computer that VMM is installed on as the seed for encrypting data. If the physical computer crashes or needs to be replaced there is no way to retain this information. You’ll have to re-enter all your RAA information. Further, with DPAPI there is no way for multiple computers to access the encrypted data.
DKM: When choosing to use DKM for encryption, VMM stores the encrypted keys in a container in Active Directory. It is not stored or tied to a specific physical computer.
Since in a HA VMM installation the VMM service may run on any node in the failover cluster, DPAPI is not a valid option for encryption. As such we’ll have to use DKM and as a result we will need to create a container in AD.
Creating the Container in AD
(1) Open the Active Directory Service Interfaces Editor (adsiedit.msc)
(2) Right-click the ADSI Edit object in the left tree and select Connect To…
(3) In most environments it should be sufficient to connect to the Default Naming Context, so the defaults are ok. Click Ok
(4) Once connected, expand the connection object and then right click the domain’s container and select New > Object…
(5) Select container as the class. Click Next
(6) Provide a value for the name of the container
(7) Click Finish
(8) Now the container is created but you will still need to take note of the distinguishedName property of the container and provide it to VMM during installation.
(9) Right-Click the container and select Properties
(10) Write down the value of the distinguishedName property
(11) Later we will need to provide this text string (“CN=VMM,DC=contoso,DC=com”) to the VMM installer during VMM installation. Write it down, and close the Active Directory Services Interfaces Editor.
Now we need to set up the 2-node Windows Server 2012 R2 Failover Cluster that the HA VMM service will run on. In this case we are trying to set up a two node cluster, but if you already have a failover cluster in your environment you can skip this step. Regardless, for any production environment you should read the about extensively documented feature on to ensure your failover cluster meets your resiliency needs ( http://technet.microsoft.com/en-us/library/hh831579.aspx ). In this example I’m setting up an extremely simple failover cluster.
Installing the Windows Failover Clustering Feature
(1) First we are going to add both servers into the Server Manager of vVMM01 (yeah, there is an extra “v” in there in my environment). This will make it easier for us to add the Failover Clustering feature to both servers from one console.
(2) Open Server Manager in the left navigation pane, right click All Servers and then click Add Servers
(3) A pop-up will open, ender the computer name of the second node to add to the server. In my environment vVMM02. Once it’s found in your domain click the right arrow to add it to the selected computers. Then click OK.
(4) Click All Servers in the left navigation pane. The vVMM02 server is being brought under management. Give it a minute until it says “Online” like vVMM01.
(5) Once it’s online, in Server Manager in the top right corner click Manage > Add Roles and Features
(6) Click Next
(7) Select Role-based or feature-based installation and click Next
(8) Select a server from the server pool to add the feature to. We will have to do this for both servers, and I chose to do the remote server first (vVMM02) and then add the feature to the local server (vVMM02). Select the server and click Next.
(9) Click next , Failover Clustering is a Feature not a Role.
(10) Select Failover Clustering
(11) A pop-up will open. Click Add Features
(12) Click Next then click Install . Since this is the remote computer I don’t mind if it restarts automatically.
(13) Repeat steps 5-12 for the other server (in my case vVMM01). The window is not modal and you can save some time by running both at once. Note: out of fear that restarting the local (vVMM01) machine might tamper with the feature installation on the remote machine (vVMM02), I did not select Restart the destination server automatically, if required when I repeated the steps. Below is an ugly screen shot of the two installations running side by side.
(14) As a final step, restart the servers as needed.
Creating the Failover Cluster
(1) On either of the two nodes that you enabled the failover clustering feature on, open Failover Cluster Manager. In the right hand pane click Create Cluster.
(2) A pop-up will open. Click Next .
(3) Enter the names of the two servers you want to cluster. The click Next.
(4) For a cluster to be supported by Microsoft, cluster validation must be run. Choose to run cluster validation and click Next .
(5) The Validate a Configuration Wizard dialog will open. Click Next
(6) Select Run all tests (recommended) and click Next
(7) Click Next again.
(8) It can take a long time to run cluster validation (sometimes hours). Let it run, and assuming it works and your cluster is configured correctly, you’ll be presented with a report. Click Finish .
(9) Now we’re back to the Create Cluster Wizard. Enter the Cluster Name and click Next.
(10) Click Next to confirm the configuration.
(11) Click Finish to create the Wizard. The failover cluster has been created. I’m getting a few cluster warnings but they won’t impact my environment substantially. We can move on now to installing VMM.
Woo! We’ve finally made it to the point where we can install VMM in a highly available mode. Let’s do it.
Installing VMM in a highly available mode on the first cluster node
(1) On either node of the cluster you created, run the VMM installer. Click Install
(2) Since you are installing VMM on a clustered node, clicking the VMM management server check box will pop up a confirmation box asking if you would like to make the VMM installation highly available. Click Yes.
(3) Both check boxes should be checked, click Next
(4) Enter product registration info, click Next
(5) The next two pages will be the EULA and CEIP program involvement. Accept the EULA and choose whether or not to enroll in the CEIP. Click Next
(6) Specify the Installation location for VMM.
(7) The next page will check for all software requirements. VMM has a strict requirement on the Windows Assessment and Deployment Kit (WADK). If you don’t have it installed on the machine, download and install it. Note that you will only need the Deployment Tools and the Windows Preinstallation Environment, not a complete installation of all the available WADK features. Also, you don’t have to close the installation wizard while you do it. You can click Check prerequisites again and it will let you move forward once WADK is installed.
(8) I installed the WADK, checked the prerequisites again, and presto, we can move forward.
(9) Enter the database information for the MSSQL database you want VMM to use. As stated earlier, this should be a highly available SQL installation installed on a separate failover cluster from the cluster we are installing VMM on.
(10) Enter the service name for the VMM installation. Click Next
(11) Now it’s time to utilize the VMM service account and DKM container we created earlier. Enter the information and click Next .
(12) Enter the port numbers and click ok, I’m leaving the defaults.
(13) Finish installing VMM and close the wizard. At this point you won’t be allowed to create a library share or add an existing one. For a highly available installation you’ll have to create the file server share within VMM after its installed.
Installing VMM in a highly available mode on the second cluster node
Finally you need to install VMM on the second node in the cluster. To do this, log on to the second node and run the VMM installer. The steps to install this are EXACTLY the same as the steps to installing VMM on the first node except that:
1) You’ll be prompted to add this server as a node to the highly available VMM installation (you’ll obviously say you do).
2) You won’t have to enter the DKM information again (you’ll still have to enter the VMM service account password but not the username.
3) You won’t have to enter database information.
4) You won’t have to enter port numbers.
Essentially, installing VMM on the second node is exactly the same as the first node only easier. Finish the installation, sit back and relax.
At this point we have successfully installed VMM in a highly available mode! It’s ready to go! Hopefully this article has been informative and has helped you make your HA VMM installation successful and straight forward.
Best!
John Patterson | Program Manager | Microsoft
Get the latest System Center news on Facebook and Twitter :
System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
When using SQL Always on in asynchronous-commit mode (the mode most customers use) there is a chance that the primary replica dies and fails over to the secondary replica BEFORE the secondary replica receives and processes the committed transactions. Essentially some data loss is possible (https://msdn.microsoft.com/en-us/library/ff877884.aspx#AvailabilityModes). It’s a limitation of the technology.
~ John Patterson
This article will guide you through the recommended way to setup and configure a typical, highly available (HA) System Center 2012 R2 Virtual Machine Manager (VMM) and later installation. While this topic was written for System Center 2012 R2 Virtual Machine Manager, it also applies to later versions including System Center 2016 Virtual Machine Manager. Some screenshots may not reflect changes in the UI since 2012 R2. Topics we’ll cover include the following:
- Overview of a VMM Environment
- What We Will Be Installing
- The VMM Service Account
- The Container in AD DS for Distributed Key Management
- The VMM Failover Cluster
- Installing Highly Available VMM
Overview of a VMM Environment
In any VMM installation there are three primary servers that you’ll need to be concerned with. As a note, a production VMM environment will likely have other servers within it such as System Center Operations Manager (OpsMgr) and System Center Data Protection Manager (DPM). VMM can also integrate with other infrastructure servers such as WDS and WSUS servers for deployment and patching workflows respectively. However, for the purpose of this article we will ignore these other servers as they mostly integrate with VMM and are not really a part of the VMM installation itself.
| Server Role | Description |
| VMM Server | The server where the VMM engine is installed. |
| VMM Library Server | A file server that VMM uses for storing a variety of files such as stored virtual machines, virtual hard disks (VHDs), physical computer profiles, and virtual machine templates. |
| MSSQL Server | VMM stores nearly all its settings, management data, and configuration in a centralized, SQL Server database. |
With these three servers in mind, we recommend following these guidelines when installing VMM in your production environment:
(1) Use a highly available installation of SQL Server (if using AlwaysOn see the note* below)
(2) Use a highly available installation of VMM.
(3) Install the highly available installation of SQL Server on a separate failover cluster from the failover cluster on which VMM is installed.
* When using SQL AlwaysOn in asynchronous-commit mode (the mode most of our customers use) there is a chance that the primary replica dies and failover to the secondary replica occurs while the secondary replica lags behind the primary database. Essentially some data loss is possible ( https://msdn.microsoft.com/en-us/library/ff877884.aspx#AvailabilityModes ). If this happens, VMM will failover to the secondary replica and the database VMM references will have gone "back in time." This is similar to restoring from a backup that is out of date by a few VMM transactions. If this happens there can be security risks such as information disclosure. We support AlwaysOn, but be aware that asynchronous replication has its risks.
What We Will Be Installing
In this article we’ll be setting up and configuring a highly available VMM installation on a two node Windows Failover Cluster along with some of the less obvious objects required for a HA installation. I’ll assume you already have a highly available SQL server installation, however there is a very informative MSDN article on various high availability MSSQL solutions at http://msdn.microsoft.com/en-us/library/ms190202.aspx that I suggest you read to discover the different HA SQL solutions available and how to configure the HA SQL solution that is appropriate for you. I also won’t go into setting up a file server cluster to use as a highly available library server. In short, I’ll stick to setting up VMM.
The VMM Service Account
The first order of business when installing a highly available VMM server is to set up a domain account for the VMM service to use. There are no requirements for this account except that it must be a member of the Local Administrators group on each of the nodes in the cluster that VMM is installed on. We refer to this account as the VMM Service Account and it needs to be created in Active Directory before VMM is installed.
Creating the VMM Service Account
(1) Open Active Directory Users and Computers (dsa.msc)
(2) Expand the domain that contains the VMM cluster and right-click on the User folder in the left pane. Then select New > User
(3) Provide the appropriate account details and select Next
(4) Provide a password and set the appropriate password policy settings. Then click Next
(5) Select Finish and complete the wizard.
(6) Close Active Directory Users and Computers
Add the VMM Service Account to the Local Administrator Group on the VMM Nodes
(1) On each node that will be a member of the failover cluster you plan on installing VMM on, open Control Panel
(2) In the top right select View By: Category
(3) Click User Accounts
(4) Again click User Accounts
(5) Select Manage User Accounts
(6) In the pop-up, click the Add… button
(7) Supply the username and domain name for the VMM Service Account we just created
(8) Select Administrator as the level of access for this account
(9) Click Finish to complete the wizard
The Container in AD DS for Distributed Key Management
VMM stores Run As Accounts (RAAs) in its database to manage VM hosts, file servers, VMs, and many other credential-required resources. Essentially this results in VMM storing usernames and passwords in its database and, as security is a paramount concern in any environment, these usernames and passwords have to be encrypted. There are two ways to encrypt this data in a standalone VMM installation: DPAPI and DKM.
DPAPI: When choosing to use DPAPI for encryption, VMM essentially uses the hardware ID of the physical computer that VMM is installed on as the seed for encrypting data. If the physical computer crashes or needs to be replaced there is no way to retain this information. You’ll have to re-enter all your RAA information. Further, with DPAPI there is no way for multiple computers to access the encrypted data.
DKM: When choosing to use DKM for encryption, VMM stores the encrypted keys in a container in Active Directory. It is not stored or tied to a specific physical computer.
Since in a HA VMM installation the VMM service may run on any node in the failover cluster, DPAPI is not a valid option for encryption. As such we’ll have to use DKM and as a result we will need to create a container in AD.
Creating the Container in AD
(1) Open the Active Directory Service Interfaces Editor (adsiedit.msc)
(2) Right-click the ADSI Edit object in the left tree and select Connect To…
(3) In most environments it should be sufficient to connect to the Default Naming Context, so the defaults are ok. Click Ok
(4) Once connected, expand the connection object and then right click the domain’s container and select New > Object…
(5) Select container as the class. Click Next
(6) Provide a value for the name of the container
(7) Click Finish
(8) Now the container is created but you will still need to take note of the distinguishedName property of the container and provide it to VMM during installation.
(9) Right-Click the container and select Properties
(10) Write down the value of the distinguishedName property
(11) Later we will need to provide this text string (“CN=VMM,DC=contoso,DC=com”) to the VMM installer during VMM installation. Write it down, and close the Active Directory Services Interfaces Editor.
The VMM Failover Cluster
Now we need to set up the 2-node Windows Server 2012 R2 Failover Cluster that the HA VMM service will run on. In this case we are trying to set up a two node cluster, but if you already have a failover cluster in your environment you can skip this step. Regardless, for any production environment you should read the about extensively documented feature on to ensure your failover cluster meets your resiliency needs ( http://technet.microsoft.com/en-us/library/hh831579.aspx ). In this example I’m setting up an extremely simple failover cluster.
Installing the Windows Failover Clustering Feature
(1) First we are going to add both servers into the Server Manager of vVMM01 (yeah, there is an extra “v” in there in my environment). This will make it easier for us to add the Failover Clustering feature to both servers from one console.
(2) Open Server Manager in the left navigation pane, right click All Servers and then click Add Servers
(3) A pop-up will open, ender the computer name of the second node to add to the server. In my environment vVMM02. Once it’s found in your domain click the right arrow to add it to the selected computers. Then click OK.
(4) Click All Servers in the left navigation pane. The vVMM02 server is being brought under management. Give it a minute until it says “Online” like vVMM01.
(5) Once it’s online, in Server Manager in the top right corner click Manage > Add Roles and Features
(6) Click Next
(7) Select Role-based or feature-based installation and click Next
(8) Select a server from the server pool to add the feature to. We will have to do this for both servers, and I chose to do the remote server first (vVMM02) and then add the feature to the local server (vVMM02). Select the server and click Next.
(9) Click next , Failover Clustering is a Feature not a Role.
(10) Select Failover Clustering
(11) A pop-up will open. Click Add Features
(12) Click Next then click Install . Since this is the remote computer I don’t mind if it restarts automatically.
(13) Repeat steps 5-12 for the other server (in my case vVMM01). The window is not modal and you can save some time by running both at once. Note: out of fear that restarting the local (vVMM01) machine might tamper with the feature installation on the remote machine (vVMM02), I did not select Restart the destination server automatically, if required when I repeated the steps. Below is an ugly screen shot of the two installations running side by side.
(14) As a final step, restart the servers as needed.
Creating the Failover Cluster
(1) On either of the two nodes that you enabled the failover clustering feature on, open Failover Cluster Manager. In the right hand pane click Create Cluster.
(2) A pop-up will open. Click Next .
(3) Enter the names of the two servers you want to cluster. The click Next.
(4) For a cluster to be supported by Microsoft, cluster validation must be run. Choose to run cluster validation and click Next .
(5) The Validate a Configuration Wizard dialog will open. Click Next
(6) Select Run all tests (recommended) and click Next
(7) Click Next again.
(8) It can take a long time to run cluster validation (sometimes hours). Let it run, and assuming it works and your cluster is configured correctly, you’ll be presented with a report. Click Finish .
(9) Now we’re back to the Create Cluster Wizard. Enter the Cluster Name and click Next.
(10) Click Next to confirm the configuration.
(11) Click Finish to create the Wizard. The failover cluster has been created. I’m getting a few cluster warnings but they won’t impact my environment substantially. We can move on now to installing VMM.
Installing Highly Available VMM
Woo! We’ve finally made it to the point where we can install VMM in a highly available mode. Let’s do it.
Installing VMM in a highly available mode on the first cluster node
(1) On either node of the cluster you created, run the VMM installer. Click Install
(2) Since you are installing VMM on a clustered node, clicking the VMM management server check box will pop up a confirmation box asking if you would like to make the VMM installation highly available. Click Yes.
(3) Both check boxes should be checked, click Next
(4) Enter product registration info, click Next
(5) The next two pages will be the EULA and CEIP program involvement. Accept the EULA and choose whether or not to enroll in the CEIP. Click Next
(6) Specify the Installation location for VMM.
(7) The next page will check for all software requirements. VMM has a strict requirement on the Windows Assessment and Deployment Kit (WADK). If you don’t have it installed on the machine, download and install it. Note that you will only need the Deployment Tools and the Windows Preinstallation Environment, not a complete installation of all the available WADK features. Also, you don’t have to close the installation wizard while you do it. You can click Check prerequisites again and it will let you move forward once WADK is installed.
(8) I installed the WADK, checked the prerequisites again, and presto, we can move forward.
(9) Enter the database information for the MSSQL database you want VMM to use. As stated earlier, this should be a highly available SQL installation installed on a separate failover cluster from the cluster we are installing VMM on.
(10) Enter the service name for the VMM installation. Click Next
(11) Now it’s time to utilize the VMM service account and DKM container we created earlier. Enter the information and click Next .
(12) Enter the port numbers and click ok, I’m leaving the defaults.
(13) Finish installing VMM and close the wizard. At this point you won’t be allowed to create a library share or add an existing one. For a highly available installation you’ll have to create the file server share within VMM after its installed.
Installing VMM in a highly available mode on the second cluster node
Finally you need to install VMM on the second node in the cluster. To do this, log on to the second node and run the VMM installer. The steps to install this are EXACTLY the same as the steps to installing VMM on the first node except that:
1) You’ll be prompted to add this server as a node to the highly available VMM installation (you’ll obviously say you do).
2) You won’t have to enter the DKM information again (you’ll still have to enter the VMM service account password but not the username.
3) You won’t have to enter database information.
4) You won’t have to enter port numbers.
Essentially, installing VMM on the second node is exactly the same as the first node only easier. Finish the installation, sit back and relax.
You’re Done!
At this point we have successfully installed VMM in a highly available mode! It’s ready to go! Hopefully this article has been informative and has helped you make your HA VMM installation successful and straight forward.
Best!
John Patterson | Program Manager | Microsoft
Get the latest System Center news on Facebook and Twitter :
System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/
App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
When using SQL Always on in asynchronous-commit mode (the mode most customers use) there is a chance that the primary replica dies and fails over to the secondary replica BEFORE the secondary replica receives and processes the committed transactions. Essentially some data loss is possible (https://msdn.microsoft.com/en-us/library/ff877884.aspx#AvailabilityModes). It’s a limitation of the technology.
Updated Mar 11, 2019
Version 4.0
System-Center-Team
Microsoft
Microsoft
