Getting started with Citrix Essentials on Azure

Earlier this month two Citrix Essentials products hit the Azure Marketplace;

XenApp Essentials and XenDesktop Essentials. https://www.citrix.com/blogs/2017/04/03/xendesktop-essentials-xenapp-essentials-now-available-in-azure-marketplace/

In this short period of time, there has been  customers who have purchased the services or are kicking the tires.

While I didn't give a number, I can say that it has been a pretty exciting first two weeks, and the interest from customers has been great.  Really great.

Both Essentials offerings run on Azure (exclusively) and are managed through Citrix Cloud.

Since these are new services, the documentation is constantly coming on-line. Here are some references that should get you over the initial hurdles of understanding how to implement it all.

The newly updated XenDesktop Essentials guide: http://docs.citrix.com/en-us/citrix-cloud/xenapp-and-xendesktop-service/xendesktop-essentials.html

If you were wondering if you could take advantage of Azure Active Directory Domain Service? Yes, you can: https://www.citrix.com/blogs/2017/04/11/xenapp-xendesktop-services-support-azure-ad-domain-services/

If you are in a hybrid cloud scenario (user workers in Azure with a VPN back to the datacenter where they need Kerberos or Windows pass-through authentication) you will need to setup up an Active Directory replica server in Azure: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-install-replica-active-directory-domain-controller

Are you setting up Windows Desktops in Azure? 
Be aware that you must implement Azure Active Directory. More details on the way.

And take advantage of the Hybrid Use Benefit Windows 10 image in the Azure Gallery if you create a new golden desktop image.

Active Directory with XenDesktop Essentials in Azure

XenDesktop Essentials and XenApp Essentials have hit the Azure Marketplace, and they are catching on.

For those of you that remember Azure RemoteApp, XenApp Essentials is the replacement for that.  And for those of you that want to give Windows Client desktops to your user-base, XenDesktop Essentials is for that.
And, for those that want it all, There is XenApp and XenDesktop Service.  Which offers it all.

Now, the reason for my post.  Active Directory and Azure Active Directory.
There is a requirement of all of these solutions that the provisioned machines are joined to a domain.  This is where I see many folks getting confused between all of the various Active Directory options.

In reality, there are only two models that will work today (at the date of this post).  Let me describe them in terms of what you need to accomplish.

In both models, you have the user side running in Azure.  Whether that be XenApp Servers (Terminal Servers for you really old folks) or Desktops (Windows Client or Windows Server desktops).

Your answer to this next question defines the path that you need to head down.

Do your Azure based user sessions need to access resources in some other cloud / datacenter?
A different way to ask this - do you need a VPN between your users in Azure and whatever other resources they need to access in some other cloud / datacenter.

If your answer was no; 
Then I am calling you 'cloud born' or 'Azure based'.
Knowing this you can use Azure AD plus Azure Active Directory Domain Service.

AD Sync is built in, and most likely Azure AD is your source for users.  But you need the additional service to support domain join, group policy, and those traditional things that Active Directory provides.

I personally love the following guide for getting AADDS all up and running: Azure Active Directory Domain Services for Beginners

The trick here is that you need to use FQDNs for domain joins and domain references.  If you customize your Azure AD domain, use that.  If you don't it is YourDomain.onmicrosoft.com.

When you need to add Group Policy to lock things down; https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-administer-group-policy

If your answer was yes;
Then you are more of a 'traditional' enterprise that is in some hybrid deployment model.
Knowing this you need to use Azure AD plus Active Directory.

You will need to enable AD Sync, you will need to establish a replica domain controller in Azure, and you (probably) already have a VPN between your datacenter and Azure virtual network.

The replica domain controller in Azure: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-install-replica-active-directory-domain-controller
Active Directory Sync / Connect to Azure AD: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect
(It does not matter where you install / run that, just that you do).

In both cases; Don't forget to update the DNS settings of your Virtual Network with these new machine IP addresses.

Manually creating a Service Principal for XenDesktop Essentials

I have been looking at the customer experience around XenDesktop Essentials lately, and I have helped a few customers with issues around defining their Service Principal accounts.

Backing up a bit.  What is this 'Service Principal' account and what is it used for?

The Service Principal is the username / secret that is used by Citrix Cloud to talk to the Azure API and perform machine lifecycle actions in your Azure Subscription.

You could call it a delegated user, or an application user, or simply an application account.
The Service Principal is not a new concept in the enterprise world.  In my background we always created very restricted user accounts for use by applications, granting only those permissions that were necessary for the application to perform its functions.

I know there is guidance on using various PowerShell scripts to do this.  But quite honestly, it is so few clicks in the Azure Portal, you might as well do it there.  Far less hassle than installing the Azure cmdlets.

Plus - by doing it this way, you can quickly identify if you have the permissions necessary, and get it fixed or pass the responsibility to the person that can do it.

First, login to the Azure Account that 'Citrix' will be deploying workstations to.
Next make sure that you have a subscription container for the 'Citrix stuff' and a Virtual Network for the workstations to use all ready to go.

Create the App Registration / Service Principal

1. Select the Azure Active Directory blade in the Azure Account
2. Select 'App registrations'
3. Select 'Add +'
4. Enter a name, leave the application type as web app / API, and enter a Sign-on URL such as 'https://localhost/xde'
5. Select Create

Grant it permission to interact with the Azure API for your account

1. Once the registration is created, select it to view its settings
2. Select 'Required permissions'
3. Select 'Windows Azure Active Directory'
4. Select 'Sign in and read user profile' and
5. Select 'Read all users' basic profiles'
6. Select 'Save'
7. Select Add, Select an API, Select 'Windows Azure Service Management API', Select 'Select'
8. Select 'Access Azure Service Management as organization users'
9. Select 'Select'
10. Select 'Done'

Add a Key (the secret)

1. In the Settings, Select 'Keys'
2. Enter a Key description, select a duration
3. Select 'Save'
4. Copy the Value of the key  (this value is necessary when this Service Principal is used with Citrix Cloud - and there are warnings that you can never see this key again)

Grant the Service Principal access to the Subscription for 'Citrix stuff'

1. Select the Billing Blade
2. Select the Subscription that you would like Citrix Cloud to be using
3. Select 'Access control'
4. Select '+ Add'
5. Under 'Role' select 'Contributor'
6. Under Select, type in the name of the App Registration you created (mine was 'xendesktop')
7. Select the Azure AD user
8. Select 'Save'

At this point in time, the Service Principal information can be handed off to your Citrix Administrator for establishing the Host connection to Azure in the Citrix Cloud portal.  

When Adding the Connection select the 'Use existing' option.

They will need;

• the Subscription UUID
• the Active Directory ID
• the Application ID
• the Application secret (that value that I mentioned you had to copy and save)

If you return the Azure Active Directory blade, Select the Properties, you will find the Directory ID.

Then select App registrations, select the one you created you can find the Application ID.

The Subscription id, is back under the Billing blade.