The recent addition of Azure Resource Manager support in XenApp and XenDesktop provides a powerful new tool for creating and managing cloud hosted VDAs.
As part of an ongoing blog series, we will explore how to get started by connecting XenApp/XenDesktop to your Azure subscription.
Using Azure Resource Manager in XenApp/XenDesktop
Azure Resource Manager (ARM) functionality is available via Machine Creation Services (MCS). While some basic familiarity with MCS may be helpful in understanding how to best use this new feature, getting started is pretty straightforward.
At a high level, creating machines consists of two distinct phases. You first connect XenApp/XenDesktop to your Azure infrastructure. You then use the established connection and specified resources to create a catalog of virtual machines. This article deals primarily with the first task.
- An Azure Subscription.
- An account which is a member of the Azure Active Directory (Azure AD) associated with your subscription, which is also co-administrator of the subscription.
- An ARM virtual network and subnet in your preferred region with connectivity to an AD controller.
To create your connection from Studio, first navigate to ‘Hosting’ settings under ‘Configuration’ and select the option to ‘Add Connection and Resources.’ From the wizard you should select the ‘Microsoft Azure’ connection type. After copying your subscription ID into the text box, name your connection and select the ‘Create new’ option to connect to your subscription.
All of the existing connection types in Studio ask for credentials, but you may notice that these fields are conspicuously absent when using ARM. Rather than directly using your credentials, Studio instead requests that you authenticate to Azure with your Azure AD account credentials. There you are prompted to grant consent for Studio to operate on your behalf. If you choose to grant the requested permissions, an Application and corresponding Service Principal are created in your Azure AD for future use by XenApp/XenDesktop. It is these details which are then stored with your connection and Studio never sees your personal Azure AD credentials.
After connecting to your subscription, you next define a set resources for use with the connection. The region selection controls where virtual machines will be deployed. Your users’ location is an important consideration here and you would ideally choose an Azure region close to where they will access their applications.
The next page allows you to select the ARM-based virtual network and subnets to make available for machines provisioned through your connection. You will notice that the available networks are filtered based on the previous region selection. Machines can only connect to a virtual network in their own region and this filtering ensures that you select a compatible network.
After naming your resources on the network page for future reference, you should proceed to summary and verify that you are satisfied with your selections before clicking ‘Finish.’
Authentication behind the scenes
Although the authentication process is quite streamlined, there is more going on than initially meets the eye. For the interested, we’ll take a brief detour into some of the more technical details to show what Studio does on your behalf.
You can think about the process in two parts, divided by the yellow line. In the first phase, Studio obtains your authorization to talk to Azure APIs on your behalf using standard OAuth2. Studio then uses your consent to setup an Application and Service Principal in your Azure AD, granting the Service Principal authorization on the subscription. The first phase really only facilitates the second, but the benefit to this approach is that you can use Studio to handle the otherwise error prone steps. Nothing stops you from creating the Application and Service Principal explicitly as the next section shows.
Notes on automation
As you might expect, you can choose to automate the creation of a connection rather than use Studio’s interactive authentication option. The following example script uses standard Azure PowerShell commands along with the Citrix Snap-Ins to create the application identity and specify the connection:
param([string]$connectionName = "AzureConnection", [string]$subscriptionName = "Pay as you go", [string]$applicationName = "CitrixXaXd", [Parameter(Mandatory=$true)] [string]$applicationPassword, [Parameter(Mandatory=$true)] [string]$subscriptionId, [Parameter(Mandatory=$true)] [string]$tenantId
$azureAdApplication = New-AzureRmADApplication -DisplayName $applicationName -HomePage “https://localhost/$applicationName” `
-IdentifierUris “https://$applicationName” -Password $applicationPassword
New-AzureRmADServicePrincipal -ApplicationId $azureAdApplication.ApplicationId
New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $azureAdApplication.ApplicationId –scope “/subscriptions/$subscriptionId”
$customProperties = @”
$connection = New-Item -ConnectionType “Custom” -CustomProperties $customProperties -HypervisorAddress @(“https://management.azure.com/”) `
-Path @(“XDHyp:\Connections\$connectionName”) -Persist -PluginId “AzureRmFactory” -Scope @() `
-SecurePassword (ConvertTo-SecureString -AsPlainText -Force $applicationPassword) -UserName $azureAdApplication.ApplicationId
New-BrokerHypervisorConnection -HypHypervisorConnectionUid $connection.HypervisorConnectionUid
Resource selection can be automated in a manner similar to other connection types in XenApp/XenDesktop. You can consult product documentation for full details, but if you quickly want to peek at what commands Studio runs under the hood you can inspect the PowerShell log from the site information section after running through the connection wizard.
Using an existing Application/Service Principal
If you are very familiar with ARM and Azure AD, you may already be using Applications and Service Principals in your day-to-day operations. XenApp/XenDesktop also supports the use of these items with the ‘Use existing…’ option on Studio’s connection page.
This page provides a number of fields, but for most uses only four should be changed from their defaults: ‘Subscription name’, ‘Active Directory ID’, ‘Application ID’, and ‘Application secret.’ If you are familiar with Azure AD applications these fields should be self-explanatory, with the possible exception of the Directory ID. It will correspond to the tenant associated with the subscription being used and it is perhaps easiest to get from the output of the Login-AzureRmAccount PowerShell cmdlet:
C:\Login-AzureRMAccount –SubscriptionId 24017984-06a3-4bfb-82e0-7c6b8384d5da Environment : AzureCloud Account : firstname.lastname@example.org TenantId : 7f640958-960e-4226-b3c7-4956af5da363 SubscriptionId : 24017984-06a3-4bfb-82e0-7c6b8384d5da
Note that any existing Service Principal used in this manner must have been granted contributor role for the subscription being targeted.
Things to be aware of:
- When creating the first connection through Studio, Azure will prompt you to grant it the necessary permissions. For future connections you will still authenticate, but Azure will remember your previous consent and not display the prompt again.
- All Service Principals created through this process require contributor role on the subscription.
- Accounts used for authentication must be a co-administrator of the subscription you wish to use. This can be setup in either of Microsoft’s portals.
- The account used for authentication must be a member of the subscription’s directory. There are two types of accounts to be aware of, which Microsoft distinguishes between as ‘Work or School’ and ‘personal Microsoft account.’ Prasanna has written a great blog which deals with this distinction and walks through the process of adding an appropriate account.
- While it is possible to use an existing Microsoft account by adding it as a member of the subscription’s directory, there can be complications if the user was previously granted ‘guest’ access to one of the directory’s resources. In this case, they may have a placeholder entry in the directory which does not grant them the necessary permissions, and Studio will return an error indicating their guest status. One way to rectify this would be to remove them from the directory and add them back explicitly, but one should exercise this option carefully as it may have unintended side effects for other resources that account has access to.
- There is a known issue where certain accounts are detected as directory guests when they are actually members. This typically occurs with older established directory accounts. You can work around this issue by adding a new account to the directory which will take the proper membership value.
- Resource groups are simply containers for resources, and they may contain resource from regions different than their own region. This could possibly cause confusion if you glance at a resource group’s region in the portal and expect all of the resources you see there to be available when you select that region in Studio.
- Your network and subnet should be large enough to host the number of machines you require. This may require some foresight but Microsoft’s portal helps you dial in the right values with guidance about the address space capacity.
Stay tuned to Citrix blogs in the coming weeks for more in depth explorations of how to leverage ARM to deliver virtual apps and desktops to your users. Topics will include best practices for ARM deployments and the process of catalog creation in XenApp/XenDesktop.