Support for hosting and managing VDAs in Azure Resource Manager using Machine Creation Service(MCS) is available in Citrix Cloud’s XenApp and XenDesktop Service as well as XenDesktop 7.11 and above.

In the earlier blogs posted by our team we learned about creating a host connection to your Azure subscription and creating the MCS catalog. In this blog we will learn to update and rollback the catalog.

This information is a supplement to the guidance in the “Update a Machine Catalog” product documentation and assumes that you are aware of creating host connection to your Azure resource manager subscription, steps to create MCS catalog and delivery group in Azure.

Create image for Catalog Update from an existing master image

Master Image prepared from VM deployed in Azure

Stand-up VM in Azure using Azure gallery image and install the VDA software, necessary tools and applications on it and use the associated OS disk VHD as the master image.

In this case, it is best to keep the master image VM in Shutdown (deallocated) state when you are creating the catalog and then power it on when you want to make any changes to your image and then use that updated image for the catalog update.

Before you begin creating a catalog, however, we recommend that you make a copy of the master image in the same or different storage account and use that copy for creating the catalog. I will explain you why is that necessary when we will discuss the catalog rollback. Please note that it is not necessary to have the master image VHD attached to the VM for MCS provisioning.

I stood up a VM EL-Sr16-RDS in Azure, installed VDA software and applications on it and shutdown the VM from the portal. From Azure portal I can check the OS disk path for this VM.

https://rdshwestusstorage1.blob.core.windows.net/vhds/EL-Sr16-RDS20161013223432.vhd

The path tells me that this VM is hosted in rdshwestusstorage1 storage account and vhds container. Using PowerShell I created copy of the OS disk VHD into another container basevhd in the same storage account. The PowerShell commands used for image copy are provided below for the reference.

Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionId SubscriptionID #Provide Azure SubscriptionID

# VHD blob to copy #
$blobName = "EL-Sr16-RDS20161013223432.vhd"

# Source Storage Account Information #
$sourceStorageAccountName = "rdshwestusstorage1"
$sourceKey = AccessKey #Get the storage account access keys from Azure Portal storage account settings
$sourceContext = New-AzureStorageContext –StorageAccountName $sourceStorageAccountName -StorageAccountKey $sourceKey
$sourceContainer = "vhds"

# Destination Storage Account Information #
$destinationStorageAccountName = "rdshwestusstorage1"
$destinationKey = AccessKey #Get the storage account access keys from Azure Portal storage account settings
$destinationContext = New-AzureStorageContext –StorageAccountName $destinationStorageAccountName -StorageAccountKey $destinationKey

# Create the destination container #
$destinationContainerName = "basevhd"
New-AzureStorageContainer -Name $destinationContainerName -Context $destinationContext

# Copy the blob #
$blobCopy = Start-AzureStorageBlobCopy -DestContainer $destinationContainerName -DestContext `
$destinationContext -SrcBlob $blobName -Context $sourceContext -SrcContainer $sourceContainer

# Retrieve the current status of the copy operation #
$status = $blobCopy | Get-AzureStorageBlobCopyState

# Print out status #
$status

# Loop until copy complete #
While($status.Status -eq "Pending"){

$status = $blobCopy | Get-AzureStorageBlobCopyState
Start-Sleep 10

# Print out status #
$status } I created catalog EL Sr16 RDS Catalog1 using image EL-Sr16-RDS20161013223432.vhd in basevhd container, also created Delivery Group EL Sr16 RDS Catalog1 DG1 and published applications. Now I want to update this catalog. To do so, I will power-on and logon to master image VM EL-Sr16-RDS, install updates and make required changes. Post that I will shutdown the VM from the portal. Again as a best practice I will create copy of this updated image in another container named updatevhd in the same storage account.  Now we are ready for catalog update.

Update Catalog

Select Machine Catalogs in studio navigation pane.

Select the catalog and then select Update Machines from the Actions pane.

Click Next on the overview page.

overview

On the Master Image page select the image you want to use to update the catalog.

selectimage

From the above snapshot, notice that the master image attached to the VM is present in the vhds container, whereas the image used to create the catalog is present in the basevhd container and the image used to update the catalog is present in the updatevhd container in the same storage account.

Click Next to navigate to next page in the wizard.

You will notice the pop-up message asking you to confirm whether selected image is attached to VM that is running and if so shutdown the VM from the portal. We are showing this message as forced pop-up in XD 7.12 and in Citrix Cloud environment every time you navigate the create or update catalog wizard irrespective of whether the selected image is standalone or attached to VM that is already in Shutdown (deallocated) state to avoid failures in creating/updating catalog in case you forget to shutdown the attached VM. At present there is no mechanism in XenDesktop to automatically detect whether the image is standalone or the power state of the VM it is attached to.

Click Close on the pop-up message.

forced-popup

On the Rollout Strategy page, choose when the machines in the Machine Catalog will be updated with the new master image, on the next shutdown or immediately. Refer to Citrix product documentation for more details on rollout strategy.

rollout-strategy

Verify the information on the Summary page and click Finish.

finishupdate

Wait for the catalog update to finish. Each machine restarts automatically once it is updated.  You can use following PowerShell commands from the Controller to find out machine reboot status.

asnp citrix*
Get-BrokerRebootCycle

Ensure that BrokerRebootCycle output shows state completed and machinescompleted is equal to machines selected for update.

updatecomplete

Login to the VDA and confirm the image is updated with latest changes.

Master Image prepared from VM deployed in On-Premises Hypervisor

If you already have XenDesktop on-premises deployment, you will want to use the on-premises image in Azure. Let’s see how that can be achieved. You may stand-up a VM in your on-premises hypervisor, install the VDA software, install Azure VM agent, necessary tools and applications on it and upload the associated VHD into Azure storage account to use it as master image. In this case there is no need to stand-up VM in Azure since you have uploaded ready to use image into Azure.

I stood up a VM XS-VDA1 in on-prem Xenserver and installed VDA software, Azure VM agent and required applications. Post that I exported the VM as VHD using XenCenter and then uploaded associated VHD in the storage account in Azure. Post that I created MCS catalog in Azure. Now to update the catalog, I started the same VM XS-VDA1 hosted on XenServer hypervisor, installed updates, shutdown the VM and again exported the updated VM as VHD on my local machine. I uploaded image to Azure stroge account.

Upload image to Azure

Add-AzureRMVHD -ResourceGroupName OnPremVHDStore -Destination “https://xsvhdwestusstorage.blob.core.windows.net/updatevhd/XS-VDA1-Updated.vhd” -LocalFilePath “D:\XS-VDA\XS-VDA1-Updated.vhd”

Now to update the catalog follow the same steps as discussed above. Please find below the screenshot for the image selection screen.

xs-update-existingimage

Create new image for Catalog Update

We learned how to prepare the image for the catalog update by making changes in the existing image. You can also prepare a new image from scratch by standing up new VM in Azure  or in on-prem hypervisor and use that image for catalog update.

Note – In Azure this scenario is supported only if your catalog before and after the update is using VDA from XenDdesktop 7.12 If you are using VDA older than XD 7.12 you will observe the VDA registration failure post image update and you will not be able to logon to VDA. This issue is fixed in XenDesktop 7.12 So if you using earlier VDA version you need to maintain copy of your original master VDA and apply changes on top of that.

Create new image in Azure for Catalog Update

Stand-up new VM in Azure using Azure gallery image. Install VDA software and required tools, applications, shutdown the VM from the portal and as a best practice create a copy of the VHD associated with the VM. Use this copy as a input for the catalog update process.

I stood up a VM EL-Sr16-RDS2 in Azure and installed VDA and required tools and applications. Post that using the PowerShell script provided earlier in this blog created a copy of the image in the updatevhd container in the same storage account. I am now ready for the catalog update. Please follow the same steps as we discussed earlier in this blog to complete the catalog update.

See the screenshot of the image selection page below.

updatefromnewimage

Create new image in On-Premises hypervisor for Catalog Update

If you are managing images in the on-prem hypervisor, you can stand up new a VM in the on-prem hypervisor and install VDA software, the Azure VM agent, and required tools and applications, shutdown the VM and upload the associated VHD to Azure portal. Use this uploaded image as an input for the catalog update process. Remember as mentioned earlier this scenario is supported only when your existing and new catalog is using VDA from XD 7.12 As mentioned earlier there is no need to stand-up VM from this uploaded VHD, you can directly use it for creating\updating catalog.

I stood up a VM XS-VDA2 in on-prem Xenserver and installed VDA software, Azure VM agent and required applications. Post that I exported the VM as VHD using XenCenter and then uploaded associated VHD in the Azure storage account. I am now ready for the catalog update. Please follow the same steps as we discussed earlier in this blog to complete the catalog update.

Rollback Catalog Update

After you roll out new image, you can rollback the catalog update in case there are issues with updated image. When you roll back, machines in the catalog are rolled back to the last working image. Any new features that require the newer image will no longer be available.

The database keeps an historical record of the master images used with each Machine Catalog. This history is used for catalog rollback. So do not delete, move, or rename master images; otherwise, you will not be able to revert a catalog to use them.

Follow the steps below to rollback update

Select Machine Catalogs in the Studio navigation pane.

Select the catalog and then select Rollback machine update in the Actions pane.

On the Rollout Strategy page specify when to apply the earlier master image to machines.

On the Summary page review details and submit request.

Need to maintain image copies for successful rollback

Now I will explain you the need to manually make a copy of the image for the VM hosted in Azure before create/update catalog. Let’s see how the catalog rollback will behave when you don’t create copy of the master image.

We will use VHD associated with the VM EL-Sr16-RDS to create first catalog. The image selection will look like the screenshot below.

cretecatalog-vhdattachedtovm

XenDesktop records following image path in the database. Same path will be used for image rollback.

XDHyp:\HostingUnits\ARM-EL-HU1\image.folder\XDARMVDAStore.resourcegroup\rdshwestusstorage1.storageaccount\vhds.container\EL-Sr16-RDS20161013223432.vhd.vhd

To update catalog we will make changes to the same VM, shutdown the VM and point to the same VHD for the catalog update. Note that state of the master image is changed from that of first image due to update. Update image selection will look like the screenshot below.

updatecatalog-vhdattachedtovm

XenDesktop records following image path for the update image.

XDHyp:\HostingUnits\ARM-EL-HU1\image.folder\XDARMVDAStore.resourcegroup\rdshwestusstorage1.storageaccount\vhds.container\EL-Sr16-RDS20161013223432.vhd.vhd

Now we want to to rollback the update. Check image path in the rollback screenshot below.

rollbackcatalog-vhdattachedtovm

The image at this path is already modified during the update, so even though the image rollback finishes successfully, you will notice that the VDA after the rollback is same as the VDA after the update. Unfortunately Xendesktop does not recognize this and show any error. So you will be under the impression that rollback is completed successfully but in reality nothing is changed.

You can mitigate this limitation by manually creating the copies of the image.  Like we stored first catalog master image in basevhd container and update image in updatevhd container.

In this case XenDesktop will store following image paths.

Create Catalog – XDHyp:\HostingUnits\ARM-EL-HU1\image.folder\XDARMVDAStore.resourcegroup\rdshwestusstorage1.storageaccount\basevhd.container\EL-Sr16-RDS20161013223432.vhd.vhd

Update Catalog –  XDHyp:\HostingUnits\ARM-EL-HU1\image.folder\XDARMVDAStore.resourcegroup\rdshwestusstorage1.storageaccount\updatevhd.container\EL-Sr16-RDS20161013223432.vhd.vhd

Rollback Catalog – My rollback catalog image path in this case will look like below screenshot.

successful-rollback-image-path

Note that since we maintained copies of the image we have image with its original state available for the rollback. If you follow this recommended method you will be able to successfully create, update and rollback catalog.

Things to be aware of:

  1. If you are maintaining master image VM in Azure, always create copy of associated master VHD and use that for creating catalog. For catalog update, after you make changes in your master image, again create a copy of the associated VHD and use that copy to update the catalog. If you follow this method, you can maintain one master image VM in Azure and use it for multiple image updates, rollback etc.
  2. Do not rename, delete or move master image, otherwise you won’t be able to rollback the update if required.
  3. BrokerRebootCycle after catalog update/rollback happens only for those machines which are added in the delivery group. If you have only created catalog but not added machines in the delivery group, machines will not get automatically rebooted after update/rollback, you will have to manually reboot the machines from Studio console for the new image to take the effect.
  4. The rollback is applied only to machines that need to be reverted. For machines that have not been updated with the new/updated master image (for example, machines with users who have not logged off), users do not receive notification messages and are not forced to log off.
  5. During broker reboot cycle after the image update, machines eligible for the reboot are divided into two groups. The reboot cycle is started on all machines in the first group. The cycle then waits for at least one machine to register. If the machine fails to register in the configured timeout the cycle is abandoned.  This is by design and is intended to avoid taking all the machines in a delivery group out of service due to a bad update.

Summit banner