Wednesday, June 28, 2017

Azure Resource Manager templates for Citrix Cloud workloads

Welcome to the start of some prototypes to aide in onboarding and lifecycle events for your Citrix Cloud environment running on Azure.

You can find the template repository here:

It is just getting started with some common requests received from customers.

The first Azure Resource Manager (ARM) Template will provision Citrix Cloud Connectors following best practice recommendations:
  • two Citrix Cloud Connector machines
  • In an availability set
  • joins to your existing domain 
  • always pulls the latest Cloud Connector
  • and linked to a Resource Location in your Citrix Cloud customer
  • a Resource Group separate from your Citrix workers
  • supports the selection of your existing virtual network
Why might you use this template?
  • You mind manual installation to be cumbersome
  • It is repeatable
  • Your organization has tight controls on who can provision machines
Give this first template a test drive and let me know what you think and any other ideas that you have for additional templates.

Friday, April 14, 2017

Getting started with Citrix Essentials on Azure

Earlier this month two Citrix Essentials products hit the Azure Marketplace;
XenApp Essentials and XenDesktop Essentials.

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:

If you were wondering if you could take advantage of Azure Active Directory Domain Service? Yes, you can:

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:

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.

Friday, April 7, 2017

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

When you need to add Group Policy to lock things down;

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:
Active Directory Sync / Connect to Azure AD:
(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.

Wednesday, April 5, 2017

Manually creating a Service Principal for XenDesktop Express

I have been looking at the customer experience around XenDesktop Express 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.

Tuesday, February 7, 2017

A reason to use state with Octoblu

I have been posting an 8 part series going though some advanced use of Octoblu.

Part 1: Use configuration events in Octoblu
Part 2: Creating custom devices in Octoblu
Part 3: Setting the state of an Octoblu device from a flow
Part 4: Listening to and acting on device state change in Octoblu
Part 5: Breaking values into new keys with a function node
Part 6: Reformatting nested JSON with JavaScript
Part 7: Logical data nesting with your Octoblu state device
Part 8:

Back at the beginning I introduced the concept of a state device.

Now, if you aren't yet understanding why I might introduce a state device, consider this:

Have you ever found yourself using SetKey and GetKey within flows to persist data, even if only for a little while?

Have you ever run into complex timing issues where you would love to break something into multiple flows and instead end up with one huge complex one?

This is where the state device is an easy fit.  Persist your data, in a common object that you can reference between flows.

Then, instead of relying on some message chugging through the system, you act upon a change to your state device.  So you could dev null some message, perform no update and exit your logic stream.

In the example I have been laying out I have two primary scenarios: 

Scenario 1: there are multiple incoming data sources
I have multiple devices that are all similar and they are feeding in data that I need to evaluate in a common way.  Each flow can update my state device independently, and then I simply have one evaluation flow to determine if I am going to send out my alert.

Scenario 2: there are multiple data listener paths
Just the opposite.  I have one primary input data source, it is big and complex.
Then I have multiple flows, each of which evaluates a specific type of data or specific properties.

Either way, it allows me to compartmentalize my flow logic and reduce / remove redundancy across the system.

So I end up with something like this:
Combined with this:
To do what I was doing in the first screenshot.

The big upside for me is that I removed all of the hardcoded naming filtering that I started with in order to persist the data.
The flows are now able to be more dynamic and handle the same sets of data no matter if it was mine, or someone else's.