Note: Ensure you are familiar with concepts like creating host connection to your Azure resource manager subscription, steps to create MCS catalog and delivery group in Azure etc before referring to this article.

Create image for Catalog Update from an existing master image.

Note: Before you begin creating a catalog, it is recommended that you make a copy of the master image in the same or different storage account and use that copy for creating the catalog.
It is not necessary to have the master image VHD attached to the VM for MCS provisioning.

Instructions

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.

For the below mentioned scenario, a VM EL-Sr16-RDS was used 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

1. Select Machine Catalogs in studio navigation pane.

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

3. Click Next on the overview page.
   

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

5. 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 updatevhdcontainer in the same storage account.

6. Click Next to navigate to next page in the wizard.

7. You would require to confirm whether selected image is attached to VM that is running and if so shutdown the VM from the portal. 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.

8. Click Close on the pop-up message.

9. 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.

10. Verify the information on the Summary page and click Finish.

11. 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

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

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. You may use 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. 

For this case, a VM XS-VDA1 was used in on-prem Xenserver and installed VDA software, Azure VM agent and required applications. Then the VM as VHD using XenCenter was exported and then uploaded associated VHD in the storage account in Azure. After that MCS catalog was created in Azure. Now to update the catalog, the VM XS-VDA1 hosted on XenServer hypervisor was started, installed updates, shutdown the VM and again exported the updated VM as VHD on my local machine.

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”

To update the catalog follow the same steps as discussed above. 

Create new image for Catalog Update

A new image from scratch can be created 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 are 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.

In this scenario,a VM EL-Sr16-RDS2 was used in Azure and installed VDA and required tools and applications. After that using the PowerShell script provided earlier in this blog create a copy of the image in the updatevhd container in the same storage account. Now you are ready for the catalog update. Follow the same steps to complete the catalog update.

See the screenshot of the image selection page below.

Create new image in On-Premises hypervisor for Catalog Update

If you are managing images in the on-prem hypervisor, you can use a new 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.

A VM XS-VDA2  was used in on-prem Xenserver and installed VDA software, Azure VM agent and required applications. After that export the VM as VHD using XenCenter and then upload associated VHD in the Azure storage account. Now you ready for the catalog update. Follow the same steps 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

1. Select Machine Catalogs in the Studio navigation pane.

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

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

4. On the Summary page review details and submit request.

5. Need to maintain image copies for successful rollback

6. Let’s see how the catalog rollback will behave when you don’t create copy of the master image.

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

8. 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

9. 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.
   

10. 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

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

12. 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.

13. 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 updatevhdcontainer.

14. 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

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

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.

Note:

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.