Many Citrix customers with non-persistent Machine Creation Services (MCS) deployments that use Azure have told us they want to be able to deploy the Azure Monitor Agent (AMA) on their VDAs to align with their enterprise monitoring standards. Unfortunately, simply provisioning a machine catalog with the AMA installed on the master image did not yield unique monitoring data for child VDAs in Azure Monitor. As a result, child VDAs would report to Azure Monitor with the same parent ID.
Until now.
Citrix has released a new feature that provisions MCS VMs with the AMA installed as an extension and enables the ability to uniquely identify non-persistent VDAs. Now customers can monitor MCS-managed non-persistent VMs using Azure Monitor. This blog post will provide an overview of this new capability and show you how to get up and running with it.
What is the Azure Monitor Agent?
Azure Monitor is Azure’s monitoring service, which gathers, stores, and analyzes deployment metrics. It can collect data from several sources and use that data to provide monitoring and alerting capabilities. The Azure Monitor agent is used to collect monitoring data from guest operating systems and to send that data to Azure Monitor. According to Microsoft documentation, all of Azure Monitor’s legacy monitoring agents including the Log Analytics agent, Telegraf agent, and the Azure Diagnostics extension will be replaced.
Azure Monitor uses data collection rules (DCRs) to define which data an administrator wants each agent to collect and from which Azure resources. You can install the AMA in several different ways, including as an extension defined in an Azure Resource Manager (ARM) template. In turn, an ARM template can be generated via either a template spec or a VM. You can find the full list of prerequisites for installing the AMA in the Microsoft documentation.
Prerequisites
1) Set the Necessary Permissions
The following Azure permissions are required for the service principal used with MCS. You should follow the security principle of least privilege when assigning permissions. These permissions are detailed in the Citrix DaaS product documentation.
Microsoft.Compute/virtualMachines/extensions/read
Microsoft.Compute/virtualMachines/extensions/write
Microsoft.Insights/DataCollectionRuleAssociations/Read
Microsoft.Insights/dataCollectionRuleAssociations/write
Microsoft.Insights/DataCollectionRules/Read
2) Remove Any VM Extensions from the MCS Master Image
Microsoft strongly recommends removing VM extensions from an existing machine before creating a new machine from it, per their documentation. If you don’t, leftover files on the master VM can result in unexpected behavior on child VMs. In our case, when using a machine as a master image for MCS, we should remove any extensions from the master image. Once the necessary child VMs are provisioned, you can reinstall any extensions.
3) Create a Log Analytics Workspace
When you collect logs and performance data from monitored resources, the information is stored in one or more Log Analytics workspaces. To use this feature and create a data collection rule, at least one workspace must be created. A workspace has a unique workspace ID and resource ID. The workspace name must be unique for a given resource group. Refer to the Microsoft documentation for guidance on creating a workspace.
4) Create Data Collection Rule
A DCR must be set up to deploy the AMA to child VMs once they have been provisioned. After the DCR is created, the AMA will be installed on resources that don’t already have it installed. Please note that this will enable Azure Managed Identity as well. For more on creating a DCR, refer to the Microsoft documentation.
The screenshot below shows how an admin can add a Data Collection Rule from within the Azure console:
5) Approval for Your VM Extensions (Optional)
Extensions defined in the machine profile VM or template spec are currently ignored unless they are explicitly approved. With this feature, Citrix has explicitly defined the AMA for Windows and Linux as Citrix-defined and approved extensions. However, customers may have other VM extensions applied. Some VM extensions can be exported as documented here. For other extensions, they need to be manually placed back into the ARM template. To verify if the VM extensions are correctly approved, run Get-ProvMetadataConfiguration and review the output per the example below.
PS C:\Windows\system32> Get-ProvMetadataConfiguration
PluginType ConfigurationName ConfigurationValue CitrixDefined
———- —————– —————— ————-
AzureRM Extension AzureMonitorWindowsAgent True
AzureRM Extension AzureMonitorLinuxAgent True
AzureRM Extension CustomScriptExtension False
How MCS with Azure Monitor Agent Works
When creating or updating an MCS catalog in Citrix Studio, the administrator has the option of using a machine profile to apply to the catalog’s VMs. This can be done either using a template spec or a VM. For the purposes of this blog post, I will focus on doing this via a VM.
First, choose a VM with the same OS type as the catalog. Before proceeding further, please validate that the VM is added to the DCR that was previously created (prerequisite #4). Please note that the machine profile VM should be added to the DCR, not the master image VM. As a result of adding the machine profile VM to the DCR, the AMA will be automatically installed on the VM if it wasn’t already installed. You can verify this by going to the Azure portal, viewing the machine profile VM, navigating to ‘Extensions + applications’ under Settings in the navigation menu, and then confirming that the appropriate extension is listed. For Windows VMs, the extension name is AzureMonitorWindowsAgent. For Linux, the name is AzureMonitorLinxuAgent.
The screenshot below shows an example of the admin selecting a machine profile from within Citrix Studio:
If you’re updating an existing machine catalog, use the Set-ProvScheme and Request-ProvVMUpdate commands. Refer to the examples below, where the ProvisioningSchemeName refers to the name of the machine catalog, and the MachineProfile refers to the machine profile VM or template spec to be used as the machine profile:
Set-ProvScheme -ProvisioningSchemeName “TEST” -MachineProfile “XDHyp:\HostingUnits\Unit1\machineprofile.folder\Student52030RG.resourcegroup\AUE-machine-profile.vm”
Request-ProvVMUpdate -ProvisioningSchemeName “TEST“
After you’ve selected a machine profile, proceed with the rest of the MCS wizard. Once complete, Citrix will validate that the AMA is installed in the machine profile VM’s image and that the machine profile VM is part of a DCR as part of the provisioning process. As part of the provisioning process, Citrix exports the machine profile and strips out any non-whitelisted extensions. Following that, the wizard will parameterize and generate the final ARM template, which will then be used to power on child VMs in that catalog.
Any extensions that are filtered out are saved in a list on the VM’s hardware profile. When the VM is powered on, these non-exported extensions are appended to the child VM’s ARM template. Please note that not all extensions can be exported into an ARM template. If an extension is not supported, it needs to be manually placed back into the exported template, per the Microsoft documentation.
Finally, when the child VMs are powered on, the AMA extension should be successfully installed on all child VMs and the DCR will show the child VMs included as resources. If all is well, after a few minutes, data will begin to appear in Azure Monitor.
For help troubleshooting, refer to the Microsoft documentation on troubleshooting Azure Monitor Agent and on creating a troubleshooting template.
Get Started Today
MCS now allows the ability to deploy child VMs with the Azure Monitor agent! Organizations which have standardized on Azure Monitor will finally be able to monitor their MCS-managed non-persistent VMs. Check out our product documentation here and here to learn more.
Thanks to my colleague Ankita Pagaria, whose contributed her expertise to this blog post.
