![\"\"](\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/21\/2021\/02\/insentra_james_kindon_09142020_img_1.jpg\")
<\/p>\n<\/p>\n
Azure Site Recovery (ASR)<\/a>\u00a0is Microsoft\u2019s multi-faceted solution for performing services such as Disaster Recovery (DR), Business Continuity Planning (BCP) execution and migration services (these days primarily wrapped into the Azure Migrate service).<\/p>\n When deploying\u00a0dedicated\/persistent machines<\/a>\u00a0on the Microsoft Azure platform, it is often desirable to protect these workloads via ASR, providing cross-region failover capability. Chances are if you are a Citrix customer, you may be deploying both pooled and dedicated workloads via Citrix Machine Creation Services (MCS), which does not lend itself well to ASR capabilities, or several other Azure availability technologies (yet).<\/p>\n This post focuses on dedicated\/persistent workloads deployed via MCS on Microsoft Azure. If you are deploying pooled workloads, ignore this article and simply deploy a secondary pooled catalogue in your target (failover) region, ASR serves little to no purpose for you outside of maybe replicating your master image across regions.<\/p>\n My fellow CTP and all-round good fellow\u00a0Neil Spellings<\/a>\u00a0and I discovered several considerations when dealing with ASR and Citrix workloads when consuming Citrix Cloud:<\/p>\n It is worth having a read through the\u00a0Citrix Virtual Apps and Desktops Service on Azure tech zone<\/a>\u00a0article to wrap your head around considerations.<\/p>\n The long and short of MCS deployed workloads is that you simply cannot successfully leverage ASR to protect VM\u2019s and have them failed over to another region whilst keeping Citrix power management awareness in check. This is down to the fact that with MCS deployed workloads, the\u00a0HostedMachineID\u00a0and\u00a0HypervisorConnectionUid\u00a0attributes cannot be altered, which is what Citrix uses to identify the workload from a power management perspective. In Azure, this is identified by the Resource Group (in lower case I might add) that the machine resides in and the\u00a0HypervisorConnectionUid.<\/p>\n So, whilst we can replicate the workload and have it restored, we end up in a split-brain scenario where power management awareness proves immensely problematic (ASR also does not replicate the storage account which MCS uses to cache power management status etc. from Azure) and brokering does not occur appropriately.<\/p>\n MCS dedicated workloads are a \u201cdeploy once and leave alone\u201d methodology from Citrix and as such, keeping the machines in an MCS catalogue serves little to no purpose once deployed outside of some optimized power management calls to Azure. Given that MCS blocks our ability to leverage ASR appropriately, our first step is to boot MCS out of the way (thanks for the assist!) and leverage a \u201cmanual power managed\u201d\u00a0Catalogue<\/a>\u00a0and Delivery Group. You may wish to continue to consume MCS provisioning to deploy the workloads from a central image, but post provisioning, it will be beneficial to move these workloads away from MCS management, and unlock some additional controls and capability that ASR offers.<\/p>\n You should ensure that if you leverage MCS to deploy your persistent VM\u2019s, that you power on these machines at least once post provisioning. MCS leverages \u201con-demand\u201d provisioning in Azure, so the VM does not actually exist until the first power on occurs (hence why dedicated workloads still use an identity disk on the first pass).<\/p>\n I have\u00a0written a script here<\/a>\u00a0which actions the following:<\/p>\n What it does not do:<\/p>\n Once you have performed this migration, we unlock the ability to leverage Azure Site Recovery to protect these VM\u2019s. There are still several considerations when dealing with failover scenarios, but I have a second script to cover this (read on).<\/p>\n Conversely, this script should also do the job with traditional on-premises deployments where you need to change hosting connection details such as a new VMware VCenter \u2013 but you would have to ensure you are running on a Delivery Controller and I haven\u2019t tested it (no reason for it not to work).<\/p>\n Once you have a manual catalogue and are protecting your dedicated workloads with ASR, you will need to think about the following:<\/p>\n I have a\u00a0second script here<\/a>\u00a0which will perform the following:<\/p>\n My suggestion is to leverage the JSON input capability, as it will allow you to map out both your failover and failback scenarios in a controlled fashion.<\/p>\n With the above in place and executed the following is entirely possible:<\/p>\n Provide full failback capability once the source (production) region is restored<\/p>\n I took into consideration several scenarios whilst performing my testing, outlined below. There may be others, but these are the low hanging easy to test and document for now.<\/p>\n The following components are common across all models:<\/p>\n Single Azure Subscription, single hosting connection, multiple Azure Regions<\/strong><\/p>\n Here is the subscription outline in a happy state:<\/p>\n Happy, Healthy Azure Region with single hosting connection<\/span><\/p>\n And here is what happens in a failure scenario, where we effectively lose the Azure South East Asia region:<\/p>\n Broken Azure Region with single hosting connection<\/span><\/p>\n Single Azure Subscription, multiple hosting connections, one per Azure Region<\/strong><\/p>\n Here is our second scenario in a fail state. Note that in this scenario, I needed to put the source (production) hosting connection into maintenance mode for sessions to launch.<\/p>\n Broken Azure Region with dedicated hosting connection<\/span><\/p>\n Multiple Azure Subscriptions, multiple hosting connections, multiple regions<\/strong><\/p>\n Note that I have not been able to test this scenario in earnest due to limitations in my Azure lab capability. However, the model should work, and ASR restoration across subscriptions is supported.<\/p>\n Broken Azure region with multiple hosting connections and subscriptions<\/span><\/p>\n This is focusing purely on brokering services and there are additional considerations such as profile management, user personalisation layers etc. which need to be considered outside of ASR capability.<\/p>\n I hope the above helps when working through capabilities associated with Azure Site Recovery and Citrix Cloud-based Dedicated VDI workloads. The good folks at Citrix (you know who you are) have been very helpful in sharing knowledge around how MCS operates and considerations of it in Microsoft Azure. They are also working hard to bring in additional availability options to ensure that we can leverage the power and availability options associated with Microsoft Azure.<\/p>\n This blog was originally published on jkindon.com<\/a> on 29\/07\/20 and reprinted with permission.<\/p>\n","protected":false},"excerpt":{"rendered":" Azure Site Recovery (ASR)\u00a0is Microsoft\u2019s multi-faceted solution for performing services such as Disaster Recovery (DR), Business Continuity Planning (BCP) execution and migration services (these days primarily wrapped into the Azure Migrate service). When deploying\u00a0dedicated\/persistent machines\u00a0on the Microsoft Azure platform, it is often desirable to protect these workloads via ASR, providing cross-region failover capability. Chances are… Continue reading Azure Site Recovery and MCS Provisioned Workloads<\/span><\/a><\/p>\n","protected":false},"author":86,"featured_media":1876,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[21],"tags":[],"class_list":["post-1875","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-and-modern-data-center","entry"],"_links":{"self":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/posts\/1875","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/users\/86"}],"replies":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/comments?post=1875"}],"version-history":[{"count":0,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/posts\/1875\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/media\/1876"}],"wp:attachment":[{"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/media?parent=1875"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/categories?post=1875"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.insentragroup.com\/us\/wp-json\/wp\/v2\/tags?post=1875"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}CITRIX AND AZURE SITE RECOVERY CONSIDERATIONS<\/h3>\n
\n
\n
\n
CITRIX AND AZURE SITE RECOVERY FAILOVER<\/h3>\n
\n
\n
\n
SCENARIO OUTLINES<\/h3>\n
\n
![\"\"](\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/21\/2021\/02\/insentra_james_kindon_09142020_img_2.jpg\")
<\/p>\n![\"\"](\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/21\/2021\/02\/insentra_james_kindon_09142020_img_3.jpg\")
<\/p>\n![\"\"](\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/21\/2021\/02\/insentra_james_kindon_09142020_img_4.jpg\")
<\/p>\n![\"\"](\"https:\/\/www.insentragroup.com\/wp-content\/uploads\/sites\/21\/2021\/02\/insentra_james_kindon_09142020_img_5.jpg\")
<\/p>\nSummary<\/h3>\n