{"id":3820,"date":"2014-06-06T07:27:00","date_gmt":"2014-06-06T05:27:00","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/"},"modified":"2014-06-06T07:27:00","modified_gmt":"2014-06-06T05:27:00","slug":"sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/","title":{"rendered":"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager"},"content":{"rendered":"

\"\"<\/p>\n

A couple of weeks ago, I worked for a customer that wanted to implement SQL Server 2012 (and not SQL Server 214) AlwaysOn with availability groups. During our tests we performed a bunch of failover tests and the customer tried to perform a failover of one of the installed availability group by using the failover cluster manager (FCM). Of course, I told him this is not best practice because the failover cluster manager is not aware of the synchronization state of the availability group. But with SQL Server 2014, the story has changed because I noticed a different behavior. I would like to share this information with you in this posting.<\/p>\n

But let me first demonstrate the SQL Server 2012 behavior with the following example:<\/p>\n

I have an availability group named SQL12 configured with 2 synchronous replicas and automatic failover. However, as you can see, the synchronization state of my availability database is not healthy as shown below:<\/p>\n

\"blog11_-_0_-_agg_sql12_not_healthy\"<\/p>\n

Now, if I try to failover my availability group using the failover cluster manager …<\/p>\n

\"blog11_-_0_-_agg_sql12_fcm\"<\/p>\n

\"blog11_-_0_-_agg_sql12_try_to_failover_by_using_FCM\"<\/p>\n

…. the next available node is SQL143 …<\/p>\n

\"blog11_-_0_-_agg_sql12_choose_the_next_node_by_using_FCM\"<\/p>\n

\"blog11_-_0_-_agg_sql12_try_to_failover_by_using_FCM_2\"<\/p>\n

… and we can notice the failover did not occur as expected because the SQL12 resource is still on the SQL141 node as shown in the following picture:<\/p>\n

\"blog11_-_0_-_agg_sql12_fcm\"<\/p>\n

Having a look at the cluster error log does not help us in this case because we have a classic 1069 error number without helpful information:<\/p>\n

\"blog11_-_0_-_agg_sql12_cluster_error_log\"<\/p>\n

Generating detailed cluster error logs could help us but I prefer to directly look at the SQL Server side for the moment. The AlwaysOn_health extended event is a good start to check for some existing records associated to the problem.<\/p>\n

\"blog11_-_0_-_agg_sql12_alwayson_xe\"<\/p>\n

 <\/p>\n

We have indeed some information about the failover attempt. First the SQL141SQL12 replica state changed from PRIMARY_NORMAL to RESOLVING_NORMAL due to the manual failover issued by the FCM.<\/p>\n

\"blog11_-_0_-_agg_sql12_alwayson_xe_-_1\"<\/p>\n

Then we can see an error message that explains that the dummy database is changing its role from PRIMARY to RESOLVING because there is a problem with a role synchronization. This error is issued by the forced failover of the availability group resource that I used.<\/p>\n

\"blog11_-_0_-_agg_sql12_alwayson_xe_-_2\"<\/p>\n

Finally, we notice the failover process did not complete succesfully and the dummy database failbacks on the SQL141SQL12 replica (availability_replica_id 1B9007CA-EE3F-486D-A974-838EFED0203D associated to the SQL141SQL12 replica in my case)<\/p>\n

\"blog11_-_0_-_agg_sql12_alwayson_xe_-_3\"<\/p>\n

On the other side, the SQL143SQL12 secondary replica also features a lot of useful information:<\/p>\n

\"blog11_-_0_-_agg_sql12_alwayson_xe_-_4\"<\/p>\n

\"blog11_-_0_-_agg_sql12_alwayson_xe_-_5\"<\/p>\n

To summarize, this test demonstrates clearly that the FCM is not aware of the availability databases synchronization state inside an availability group. Using FCM may result in unintended outcomes, including unexpected downtime!<\/p>\n

Now, it’s time to test the same scenario with SQL Server 2014 and a configured availability group. During the failover attempt, I get the following error message:<\/p>\n

\"blog11_-_1_-_failover_cluster_sql14\"<\/p>\n

\"blog11_-_2_-_failover_cluster_sql14\"<\/p>\n

If we take a look at the possible owners of the corresponding availability group resource, we can see that the current cluster node that hosts the availability group is the only possible owner – unlike SQL Server 2012.<\/p>\n

\"blog11_-_2_-_possible_owners_sql14\"<\/p>\n

As a reminder, possible and preferred owners are resetted during the availability group creation and failover based on the primary replica and its secondaries. For fun, I decided to compare the two processes issued by the both versions of SQL Server and availability groups (SQL Server 2012 and SQL Server 2014) after having triggered an availability group failover and generating the associated cluster logs:<\/p>\n

Get-ClusterLog -UseLocalTime -Span 5<\/p>\n

Result with SQL Server 2012<\/h3>\n
000005d4.00000778::2014\/05\/26-22:10:55.088 INFO [RCM] rcm::RcmApi::AddPossibleOwner: (sql12, 1)<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.088 INFO [GUM] Node 1: executing request locally, gumId:215, my action: \/rcm\/gum\/AddPossibleOwner, # of updates: 1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.088 INFO [RCM] rcm::RcmGum::AddPossibleOwner(sql12,1)<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 ERR\u00a0\u00a0 mscs::GumAgent::ExecuteHandlerLocally: (5010)’ because of ‘The specified node is already a possible owner.’<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 WARN [DM] Aborting group transaction 29:29:613+1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 ERR\u00a0\u00a0 [RCM] rcm::RcmApi::AddPossibleOwner: (5010)’ because of ‘Gum handler completed as failed’<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 WARN [RCM] sql12 cannot be hosted on node 3<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 WARN [RCM] Possible owners: <\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 WARN\u00a0\u00a0\u00a0\u00a0 2<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 WARN\u00a0\u00a0\u00a0\u00a0 1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 WARN <\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] rcm::RcmApi::RemovePossibleOwner: (sql12, 2)<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [GUM] Node 1: executing request locally, gumId:215, my action: \/rcm\/gum\/RemovePossibleOwner, # of updates: 1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] rcm::RcmGum::RemovePossibleOwner(sql12,2)<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] Removing node 2 from resource ‘sql12’.<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [GEM] Node 1: Sending 1 messages as a batched GEM message<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] rcm::RcmApi::AddPossibleOwner: (sql12, 2)<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [GUM] Node 1: executing request locally, gumId:216, my action: \/rcm\/gum\/AddPossibleOwner, # of updates: 1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] rcm::RcmGum::AddPossibleOwner(sql12,2)<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] Adding node 2 to resource ‘sql12’.<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [GEM] Node 1: Sending 1 messages as a batched GEM message<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [GUM] Node 1: executing request locally, gumId:217, my action: \/rcm\/gum\/SetGroupPreferredOwners, # of updates: 1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO [RCM] rcm::RcmGum::SetGroupPreferredOwners(sql12,<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO\u00a0\u00a0\u00a0\u00a0 1<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO\u00a0\u00a0\u00a0\u00a0 2<\/span><\/div>\n
000005d4.00000778::2014\/05\/26-22:10:55.103 INFO <\/span><\/div>\n

 <\/p>\n

Result with SQL Server 2014<\/h3>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 INFO [RCM] rcm::RcmApi::AddPossibleOwner: (AdventureWorksGrp, 1)<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 INFO [GUM] Node 1: executing request locally, gumId:230, my action: \/rcm\/gum\/AddPossibleOwner, # of updates: 1<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 INFO [RCM] rcm::RcmGum::AddPossibleOwner(AdventureWorksGrp,1)<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 ERR\u00a0\u00a0 mscs::GumAgent::ExecuteHandlerLocally: (5010)’ because of ‘The specified node is already a possible owner.’<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 WARN [DM] Aborting group transaction 29:29:627+1<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 ERR\u00a0\u00a0 [RCM] rcm::RcmApi::AddPossibleOwner: (5010)’ because of ‘Gum handler completed as failed’<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 WARN [RCM] AdventureWorksGrp cannot be hosted on node 3<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 WARN [RCM] Possible owners: <\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 WARN\u00a0\u00a0\u00a0\u00a0 2<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 WARN\u00a0\u00a0\u00a0\u00a0 1<\/span><\/div>\n
000005d4.00000bb0::2014\/05\/26-22:14:54.578 WARN <\/span><\/div>\n
000005d4.00000c34::2014\/05\/26-22:14:54.578 INFO [RCM] rcm::RcmApi::RemovePossibleOwner: (AdventureWorksGrp, 2)<\/span><\/div>\n
000005d4.00000c34::2014\/05\/26-22:14:54.578 INFO [GUM] Node 1: executing request locally, gumId:230, my action: \/rcm\/gum\/RemovePossibleOwner, # of updates: 1<\/span><\/div>\n
000005d4.00000c34::2014\/05\/26-22:14:54.578 INFO [RCM] rcm::RcmGum::RemovePossibleOwner(AdventureWorksGrp,2)<\/span><\/div>\n
000005d4.00000c34::2014\/05\/26-22:14:54.578 INFO [RCM] Removing node 2 from resource ‘AdventureWorksGrp’.<\/span><\/div>\n
000005d4.00000c34::2014\/05\/26-22:14:54.578 INFO [GEM] Node 1: Sending 1 messages as a batched GEM message<\/span><\/div>\n
000005d4.000011f4::2014\/05\/26-22:14:54.578 INFO [GUM] Node 1: executing request locally, gumId:231, my action: \/rcm\/gum\/SetGroupPreferredOwners, # of updates: 1<\/span><\/div>\n
000005d4.000011f4::2014\/05\/26-22:14:54.578 INFO [RCM] rcm::RcmGum::SetGroupPreferredOwners(AdventureWorksGrp,<\/span><\/div>\n
000005d4.000011f4::2014\/05\/26-22:14:54.578 INFO\u00a0\u00a0\u00a0\u00a0 1<\/span><\/div>\n
000005d4.000011f4::2014\/05\/26-22:14:54.578 INFO <\/span><\/div>\n

As I said earlier, possible and preferred owners properties are managed automatically by SQL Server AlwaysOn. We can see here this is done by the cluster resource control manager and the following functions:<\/p>\n

rcm::RcmApi::AddPossibleOwner()<\/em>, rcm::RcmApi::RemovePossibleOwner()<\/em> and rcm::RcmApi::SetGroupPreferredOwners ()<\/em> .<\/p>\n

You can notice that two nodes are added as possible owners with SQL Server 12. However, with SQL Server 2014 only one node is added as possible owner of the concerned availability group resource. Interesting change isn’t it?<\/p>\n

By David Barbarin<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

A couple of weeks ago, I worked for a customer that wanted to implement SQL Server 2012 (and not SQL Server 214) AlwaysOn with availability groups. During our tests we performed a bunch of failover tests and the customer tried to perform a failover of one of the installed availability group by using the failover […]<\/p>\n","protected":false},"author":26,"featured_media":3590,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[199],"tags":[466,38,84,49,52],"type_dbi":[],"class_list":["post-3820","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hardware-storage","tag-alwayson","tag-cluster","tag-high-availability","tag-microsoft","tag-sql-server-2014"],"acf":[],"yoast_head":"\nSQL Server 2014: Availability groups failover impossible with Failover Cluster Manager - dbi Blog<\/title>\n<meta name=\"description\" content=\"It is no longer possible to failover SQL Server 2014 availability groups using the Microsoft Failover Cluster Manager (FCM).\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager\" \/>\n<meta property=\"og:description\" content=\"It is no longer possible to failover SQL Server 2014 availability groups using the Microsoft Failover Cluster Manager (FCM).\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2014-06-06T05:27:00+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"245\" \/>\n\t<meta property=\"og:image:height\" content=\"149\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Microsoft Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Microsoft Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\"},\"author\":{\"name\":\"Microsoft Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"headline\":\"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager\",\"datePublished\":\"2014-06-06T05:27:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\"},\"wordCount\":1092,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg\",\"keywords\":[\"AlwaysOn\",\"Cluster\",\"High availability\",\"Microsoft\",\"SQL Server 2014\"],\"articleSection\":[\"Hardware & Storage\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\",\"name\":\"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg\",\"datePublished\":\"2014-06-06T05:27:00+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"description\":\"It is no longer possible to failover SQL Server 2014 availability groups using the Microsoft Failover Cluster Manager (FCM).\",\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg\",\"width\":245,\"height\":149},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\",\"name\":\"Microsoft Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"caption\":\"Microsoft Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager - dbi Blog","description":"It is no longer possible to failover SQL Server 2014 availability groups using the Microsoft Failover Cluster Manager (FCM).","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/","og_locale":"en_US","og_type":"article","og_title":"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager","og_description":"It is no longer possible to failover SQL Server 2014 availability groups using the Microsoft Failover Cluster Manager (FCM).","og_url":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/","og_site_name":"dbi Blog","article_published_time":"2014-06-06T05:27:00+00:00","og_image":[{"width":245,"height":149,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg","type":"image\/jpeg"}],"author":"Microsoft Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Microsoft Team","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/"},"author":{"name":"Microsoft Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"headline":"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager","datePublished":"2014-06-06T05:27:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/"},"wordCount":1092,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg","keywords":["AlwaysOn","Cluster","High availability","Microsoft","SQL Server 2014"],"articleSection":["Hardware & Storage"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/","url":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/","name":"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg","datePublished":"2014-06-06T05:27:00+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"description":"It is no longer possible to failover SQL Server 2014 availability groups using the Microsoft Failover Cluster Manager (FCM).","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/2e1ax_default_entry_sqlserver2014.jpg","width":245,"height":149},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-2014-availability-groups-failover-impossible-with-failover-cluster-manager\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"SQL Server 2014: Availability groups failover impossible with Failover Cluster Manager"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4","name":"Microsoft Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","caption":"Microsoft Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/3820","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/26"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=3820"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/3820\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/3590"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=3820"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=3820"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=3820"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=3820"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}