Wednesday, November 30, 2022

The Innovation And Current Limitations Of VMware's Universal Broker For Horizon

VMware's Universal Broker allows Horizon users access to multiple Pods through a single URL, routing sessions based on resource availability, entitlements and shortest network paths.  Traditionally, multi-site Horizon deployments require a combination of Cloud Pod Architecture (CPA) and 3rd party global load balancers to provide fluid failover and fall back.  Universal Broker, part of the Horizon Control Plane, replaces these requirements with a purpose built SaaS based offering.  The solution leverages the control plane's privileged insight into Horizon environments to deliver more efficient and error free placement of Horizon sessions across Pods.  This addresses shortcomings of traditional CPA/GSLB deployments while laying the ground work for integrating Horizon deployments across various cloud vendors.  

All that said, there are certainly caveats and limitations to the solution.  In fact, you might say there's a conga line of caveats and limitations.  However, while the technology is currently going through an awkward teenage phase of sorts, overall its a clever and compelling solution with a promising trajectory. It's not just a one for one replacement for CPA and 3rd party GSLB.  Universal Broker is an elegant innovation, a purpose built SaaS based solution for Horizon that parlays environmental information from the control plane into more efficient and error free placement of sessions.  Key to its efficacy is an innovative bifurcation of the Horizon protocol, with the primary and secondary protocols following separate network paths.  This shift helps avoid the need for east-west replication traffic between Horizon Pods, as is the case with CPA.   Further it solves for a particularly acute affliction with east-west interpod traffic called Horizon protocol hair-pinning, a potential pitfall for the traditional combination of CPA and 3rd party GSLB.   Overall, Universal Broker simplifies and improves on-premises multi-site deployments while enabling the effective adoption of Horizon 8 cloud based workloads.  It's also integral to the new next-gen Horizon Control Plane currently supported for Horizon on Azure. This post will provide a brief overview of Universal Broker, the hair-pinning challenge it addresses, its setup for Horizon 8 environments and some current limitations.  

The Innovation Of Universal Broker For Horizon

Along with making it easier to deploy and support the cloudiness of Universal Broker is key to more efficient routing and placement of Horizon sessions across Pods.  As part the Horizon Control Plane it has privileged information about home sites, resource availability, and established sessions, affording its global load balancing functionality a greater degree of integration with Horizon.  Traditionally 3rd party GSLBs and CPA at best can be well coordinated with Horizon, but nothing near the synchronization achieved through Universal Broker.  A further departure from the traditional model is how Universal Broker bifurcates Horizon protocol traffic into two separate network paths.   The primary Horizon protocol traffic, which handles authentication, travels between the client endpoint device and Universal Broker in the cloud.  The secondary Horizon protocol traffic, the display protocol, traverses a second path between the client and actual Horizon environment.  

For context, below is a representation of the flow of Horizon protocol traffic for a normal remote Horizon connection.  Typically the primary protocol traffic is over TCP port 443 from the endpoint client through the Unified Access Gateway (UAG) appliance onto the Connection server.  If this authentication is successful the Horizon secondary protocol kicks into gear, establishing a display protocol connection between the endpoint client and the virtual desktop.   Under normal circumstances, using the Blast display protocol, this would consist of 8443 UDP based traffic to the UAG appliance and 22443 UDP traffic from the UAG appliance to the virtual desktop.  

With Universal Broker the Horizon protocol is bifurcated, traveling across two separate network paths.  The primary Horizon protocol consists of a connection directly against Universal Broker for authentication over TCP 443.   After successful authentication the secondary Horizon protocol traverses a connection between the endpoint device to the Horizon Pod itself.  Again, under normal circumstances for Blast it would be UDP 8443 to the UAG appliance and UDP 22443 from the UAG appliance to the virtual desktop.   Overall, we're talking about two very separate network paths.  One from the endpoint device to the Universal Broker service in the Control Plane and a second path from the endpoint device to the Horizon environment itself.  

So, when Universal Broker is in the mix the entire primary Horizon protocol connection is shifted and offloaded to the cloud.  Though, relatively speaking the vast majority of Horizon protocol traffic is secondary protocol traffic, this shift of the primary protocol traffic is still significant, simplifying support of initial connectivity.   If a user fails to authenticate to their Horizon environment through Universal Broker you don't need to investigate site specific challenges providing external world access to Horizon services.  No load balancers to troubleshoot, no questions about client network connectivity to your on-premises environment and, if you leverage a subdomain of, no concerns about DNS records or expired certificates.  All these typical primary protocol concerns are offloaded to Universal Broker.  If the user is failing to see their entitlements most likely they're fat fingering their password or just failing to have access to the internet.  By shifting the primary protocol exchange to the cloud a lot of the nittier grittier troubleshooting for remote connectivity is circumvented or at least simplified.  

The Horizon secondary protocol, the display protocol, is most relevant and impactful when it comes to user experience.  Fortunately, the network path traversed by this protocol is established post authentication based on Universal Broker's assessment.  An optimum Horizon Pod is judiciously selected based on, "insider information," regarding the status and configuration of the Horizon environment and entitlements.  This leads to global load balancing that's better informed by the Horizon solution, providing a tighter integration than normally achievable.   It's easy to appreciate this improvement when you consider an esoteric pitfall of the older traditional GSLB/CPA model: Horizon protocol traffic hair-pinning.  

Horizon Protocol Traffic Hair-Pinning - Ouch!

For over a decade now VMware has offered a fully redundant Horizon architecture for customers who need a bullet proof, highly available Horizon deployment. It used to be referred to as, "AlwaysOn Point Of Care," in homage to the healthcare customers that were particularly fond of the solution. Nowadays, it's consider just plain redundancy, or a Horizon Multi-Site architecture. Prior to Universal Broker, an absolute requirement for this architecture was some combination of a 3rd party global load balancer and Cloud Pod Architecture (CPA).  The GSLB solution provides a single name space for multiple sites, while CPA replicates entitlements, resource status and current session information between the separate Horizon Pods, providing minimal integration between otherwise fully redundant and independent Horizon environments.  This ensures fluid failover and fall back in response to disruptions and outages, while also ensuring folks get properly routed according to home site preferences or pre-existing sessions.  

This model has been good enough to make it throughout the last decade but has a couple caveats less than ideal for traditional on-premises deployments and complete deal breakers for certain types of cloud based deployments. First off, it's predicated on network connectivity and east-west traffic between Horizon Pods, a requirement for replicating entitlements, resource availability and session status across separate environments.  It's a potential challenge when you consider these Pods could be very far away from each other or on different clouds.  

While CPA traffic isn't too extensive and is typically manageable,  the need for east-west traffic between sites can really spike when remote connections through UAG appliances are in the mix and global load balancing isn't executed flawlessly.  This ties back to UAG and how it handles the Horizon protocol.  Traditionally you must have both the primary and secondary Horizon protocol traffic go through the same UAG appliance.   In fact, outside of Universal Broker deployments, it's an absolute requirement.  UAG's prime directive is to ensure all display protocol traffic passed is on behalf of a strongly authenticated user.  To achieve this it only passes secondary protocol traffic for sessions its handled primary protocol traffic for.  There's no way for UAG to communicate authenticity of a Horizon user to other UAGs.   So, under normal circumstances, the same UAG that handles primary protocol traffic must handle the secondary protocol traffic or the session will otherwise break.  This is by design.  Now, this requirement for UAG can have some rough consequences in the context of a traditional Horizon multi-site architecture.  If the 3rd party global load balancer doesn't do a flawless job getting folks routed to the proper Pod, there's potential for an inefficiency referred to as Horizon protocol traffic hair-pinning.  

For example, say an organization has two PODs, one in New York and one in Los Angeles.  Then a jet setting banker working for that organization connects to his virtual desktop from a Manhattan penthouse.  Accordingly, the GSLB routes him to the Horizon POD in New York.   He disconnects from his virtual desktop, kisses his wife and kids good bye, then jumps on a private jet with his mistress for a weekend getaway to the Grand Teton National park in Wyoming.   When he reaches the hotel room in Wyoming he remembers, "oh shoot I forgot a quick thing for work," then connects to his Horizon environment.  The global load balancer sees he's in Wyoming and routes him to the closer California Pod.   He hits the Horizon Connection server in California and through CPA the Connection Server is aware of the banker's currently open session in New York.  It routes him back to that currently open session.  Great, except, because he's initially connected the California Pod through a UAG appliance in California, he has to continue using that UAG appliance.  So his traffic has to go from Wyoming to California, then back across the US from the UAG appliance in California to the Horizon Pod in New York.  An extreme but perfect example of Horizon protocol hair-pinning.   Not only could it make for a lousy user experience, but it could lead to an excessive amount of east-west traffic beyond what's been planed for.  

This example is extreme, but by no means outside the world of possibilities.  There's certainly ways you could fine tune the coordination of your 3rd party global load balancer and Horizon environments to mitigate this challenge.  (For instance I've heard F5 has an APM module that can more accurately route a user to a Pod where they already have an established session.)  However, I don't think creating a GSLB/CPA solution that's bullet proof is a cake walk and that's why this challenge is called out in the Tech Zone article, Providing Disaster Recovery for VMware Horizon.   If you don't get things just right the impact could be fairly brutal on your user experience and networks, possibly in the middle of an outage, when hair-pinning challenges are the last thing you need.  Potential for particularly acute challenges arise when considering cloud hosted desktops.  Both the AWS and GCVE guides warn against this potential hair-pinning.  In these scenarios, hair-pinning has the potential to saturate capacity on NSX gateways and kill session density.   Further, it could lead to some expensive and senseless traffic flow between on-premises and cloud environments.  Accordingly, it's recommended to leverage Universal Broker instead of CPA for these Horizon 8 based cloud deployments. 

Despite working with Unified Access Gateway for over half a decade now I was completely blind sided by this esoteric gotcha.  It took awhile for this challenge to sync in, but when it did, oh boy, did it!   Fortunately, we can completely side step this potential pitfall by adopting Universal Broker.  With Universal Broker no traffic hits a UAG appliance until after there's been a successful authentication against the cloud and an ideal path has been determined.   So, with the adoption of Universal Broker we avoid this esoteric, but real, pitfall with on-premises Horizon environments while laying the ground work for successful multi-site adoption with cloud hosted virtual desktops.  Speaking of cloud hosted desktops lets talk about Universal Broker and it's role in the next-gen Horizon Control Plane for Horizon on Azure. 

Universal Broker And The next-gen Horizon Control Plane (Titan)

For the next-gen Horizon Control Plane, currently limited to Horizon on Azure, Universal Broker is an essential built-in component.  It plays a critical role in the transformation to a Horizon thin edge, helping eliminate the need to deploy Horizon Connection servers within Azure.  Instead, there's a light weight deployment of a thin Horizon Edge on top of native Azure, consisting of only UAG appliances and Horizon Edge Gateways.  The rest of the traditional infrastructure used to manage the Horizon environment is shifted to the next-gen Horizon Control Plane.  This reduces consumption of Azure capacity while simplifying the deployment and maintenance of Horizon.   

Again, with this next-gen architecture Universal Broker is an absolute requirement, an integral part of this new model. So much so, it doesn't even get specifically called out in the next-gen reference architecture or official documentation.  It's functionality requires no extra configuration and is assumed available as entitlements are created.  While this new, stealthier, iteration of Universal Broker is certainly easier to deploy it's only available with the next-gen Horizon Control Plane, so its limited to Horizon on Azure for now.   For those leveraging Horizon 8 deployments on-premises or on top of various SDDC public clouds - AVS, GCVE, AWS  - v1 of Universal Broker is still relevant. At Explore Europe 2022 VMware announced intent on extending next-gen architecture to Horizon 8, but it's limited in scope as of today and there's no committed time line for extending it's newer iteration of Universal Broker to Horizon 8.  In the mean time there's the traditional Universal Broker deployment that's been available for sometime now and, while it's not as easy to deploy as v2, it's not rocket science.  

Setting Up Universal Broker With My On-premises Lab 

Since the setup of Universal Broker for Horizon 8 is well documented I'm just going to provide a high level overview, call out some specific challenges, and include links to relevant documentation for those who want to get into the nitty gritty.   The official documentation calls out four major steps for setting up Universal Broker for Horizon 8 environments.  Assuming you already have a current version of Horizon Cloud Connector up and running, the next steps are:

  1. Installing the Universal Broker Plugin on all Connection Servers 
  2. Configuring your UAG appliances with the required JWT settings 
  3. Enabling Universal Broker in your Horizon Universal Console 
  4. Configuring multi-cloud entitlements within the Universal Console 

Again, these steps are well documented in both the official documentation for Horizon Cloud Control Plane and a really nifty Tech Zone article called, "Configuring Universal Broker For Horizon."   Below is an excellent graphical representation of the architecture.  

While in hindsight the configuration of UAG was relatively straightforward I personally struggled with it. The relevant settings are configurable through the web interface for the UAG appliance by navigating to  advanced settings and clicking the gear box for JWT.  All the settings to input are in regard to the supported Horizon Pod itself and are specially detailed here in the documentation.  First off there's the cluster name of the Horizon Pod.  Unless you've bee supporting CPA, you've probably never been aware of this property.  Its case sensitive so use caution.  (I had challenges with this portion of the setup because CPA had been enabled for my Pod in the past, though it currently wasn't in use.  That had the affect of changing the name of the cluster that was displayed versus what was needed for the UAG setting.)  

Another setting I initially struggled with was the Dynamic Public Key URL.  This essentially amounts to appending "/broker/publicKey/protocolredirection" to the internal FQDN of your Horizon Pod.  (I would think it's always going to be the same FQDN used for your, "Connection Server URL," under Horizon Edge settings.)   Likewise, the, "Public key URL thumbprints," is the certificate thumbprint used by the FQDN leveraged for the Dynamic Public Key URL. (Again, probably the same as your Connection Server URL Thumbprint under Horizon Edge settings.).  So, overall, the values are fairly similar to values you you're using already for your UAG's Horizon settings, but they have weird fancy names that can throw you off.   For context, here's the settings I typically use for my Horizon Edge settings:

And here's the JWT settings for Universal Broker: 

In hindsight it all makes sense enough but in the context of setting up a new solution it was a bit confusing at first.  Another gotcha I  bumped into was the need to define your desktop pools as, "Cloud Managed," when initially creating them, prior to creating your multi-cloud assignments within the Universal Console.  Fortunately, once you know to do this, the procedure is simple enough.  As you're walking through the desktop pool creation wizard check the box for, "Cloud Managed," and you're good to go.

Again, there's a great article in Tech Zone that covers the the setup of Universal Broker called, "Configuring Universal Broker For Horizon."  I'm sorry to say I didn't learn about this articles existence till I was almost completely done with the setup.  Instead, I slogged through the entire setup using the official documentation, "Administration of Your Horizon Cloud Tenant Environment and Your Fleet of Onboarded PODs."  It was doable, just not the smooth and enjoyable guidance of a well put together Tech Zone article.  

Other portions of the setup were fairly straight forward.  For instance, installing the Universal Broker Plugin was just a matter of locating the right version for my Connection Servers, accepting defaults, and going next-next-finish.  Configuring the Broker service in the Universal Console was easy and straight forward as well, particularly because I choose to go with a subdomain of, rather than a customer provided FQDN.  This avoids the need to generate any SSL certs or create any external DNS records, which I found to be a lovely convenience.  (Otherwise, you can go with the customer provided option, then enter in your own FQDN and provide a cert.). 

With the plug-ins installed on your Connection Servers, UAG's properly configured and Broker enabled, you're ready to start creating your multi-cloud entitlements from the Universal Console.   It's a relatively straight forward process so I'll leave that to the official documentation.  

One final thing I'd like to point out is that you can configure UAG's to support Universal Broker, without disrupting their use for traditional UAG access to Horizon environments.   So folks can continue to hit these UAG devices directly for access to traditional Horizon pools while in parallel they can support access through Universal Broker.  Further, while the local pools used for Universal Broker multi-cloud entitlements are configured from Universal Cloud, the entitlements made from the cloud trickle down to the local pools so these local pools are also accessible through direct UAG connections. 

Current Limitations Of Universal Broker 

While Universal Broker presents some interesting innovation and a compelling future there's definitely some limitations.  Most notably, Universal Broker v1 doesn't support application pools across multiple Pods.  You can deliver a single Pod based application pool but you're not going to get load balancing for application pools across multiple Pods.    So, as far v1 of Universal Broker is concerned, there's isn't parity between application pools and virtual desktop pools.  Another limitation as of today is no support for mixing Horizon 8 based Pods and Horizon Cloud based Pods. (Horizon on Azure.)  So, for example, you can't have a multi-cloud entitlement that spans across an on-premises Horizon 8 Pod and a Horizon on Azure environment.   However, you could have a multi-cloud assignment that spans across an on-premises Horizon 8 Pod and Horizon 8 Pod running on top of AWS, GCVE or AVS.   It comes down to whether your deployment use traditional Horizon 8 Connection Servers or not.   If they do then they can share multi-cloud entitlements with one another. (Assuming they're not application pools.)

There's also challenges regarding support for stronger forms of authentication.  Leveraging the built in capabilities of UAG, there's support for RADIUS and RSA.  However, there's no support for smart cards or certificate auth.  Further, there isn't support for direct SAML integrations between UAGs and 3rd party IDPs, one of the fastest growing methods for strong authentication within the DMZ through UAG.  So no support for direct integrations with IDPs like Okta, Ping or Azure.   That said, there is support for Workspace ONE Access, which in turn can be integrated with this 3rd party solutions.   So Workspace ONE Access can be configured as a trusted IDP for Universal Broker, which in turn can leverage 3rd party solutions that have been configured as trusted IDPs for WS1 Access. (Kind of like the good old days before UAG started supporting direct integrations.).  

The integration of Universal Broker with WS1 Access makes for interesting discussion because there's a lot of confusion about the ability to replace the solutions with each other.  While there's some slightly overlapping capabilities in the two products, by and large they are complementary solutions with very different competencies.   Sure, Workspace ONE Access is a way to provide users with a single URL for access to multiple Horizon PODs,  but the solution is squarely focused on identity and wrapping modern authentication around Horizon access.  It's by no means a global load balancing solution.  Conversely, while Universal Broker can support strong authentication through RADIUS and RSA,  its core competency is providing global load balancing based on shortest network path, assignments and current Horizon environment status.  So, when you focus on the core competencies of each of these solutions, what they're really good at, combing the technologies is possibility worthy of consideration.   For a great overview of this integration, check out the section, "Workspace ONE Access And Horizon Integration," with  the Tech Zone article, Platform Integration.  Below is a great diagram of the integration.  

However, there's an important caveat to be aware of.  With this WS1 Access integration, as it stands today, there isn't an option to configure unique WS1 Access policies for the multi-cloud entitlements supported by Universal Broker.  Buried in the documentation, under a section called, "Horizon Cloud - Known Limitations," it states, "access policies set in Workspace ONE Access do not apply to applications and desktops from a Horizon Cloud environment that has Universal Broker enabled." Instead, all the Universal Broker entitlements are protected by the default access policy of WS1 Access.  Depending on your deployment this may or may not be a deal breaker.   If you're using WS1 primarily for your Horizon deployment, and all your entitlements have the same access policy requirements, then having them all share the same default access policy could be feasible.  However, if you need granularity in terms of your WS1 Access policies for these multi-pod assignments, say stricter requirements for some specific pools than others, this could be a problem.   Or if you have a fairly mature WS1 Access deployment and want looser requirements for initial portal access it could be a challenge.  For more granular WS1 Access policies to use for your desktop you need to fall back to Virtual App Collections which, unfortunately, are incompatible with Universal Broker.   

The Trajectory Of Universal Broker And next-gen Horizon Control Plane

As called out earlier in this post, VMware recently announced plans to extend the next-gen Horizon Control Plane to Horizon 8 environments for better support of hybrid deployments across on-prem and Azure.   Given Universal Broker is transparent and built into the next-gen Control Plane, extending this new control plane architecture to Horizon 8 shows a lot of promise for addressing the limitations of Universal Broker v1 as of today.   Right off the bat, the next-gen Horizon Control Plane supports application pool entitlements across multiple Pods, addressing a long standing limitation.  Further, extending support to Horizon 8 certainly implies that challenges with multi-cloud entitlements across Horizon and Horizon Cloud PODs  will be addressed.  Finally, there certainly appears to be commitment to ironing out challenges combining Universal Broker functionality with Workspace ONE Access.  With this next-gen architecture, use of an IDP is no only supported, but is an absolute requirement.   As of today there's a choice between WS1 Access or Azure.  

Though there's no fixed promises made by VMware as of today, with this next-gen Horizon Control Plane and Universal Broker there's a clear trajectory towards addressing a lot of todays challenges.    


While there's work to be done and gaps to bridge I'm still incredibly excited about the Universal Broker technology and think every Horizon admin should at least be familiar with it.  In some ways it reminds me of Instant Clones circa 2016 or UAG in 2015, back when it was called, "Access Point."  Both these solutions seemed a little crackpot or science project-ish at the time.  They weren't quite ready yet, not done baking till... they just were.  Though we definitely had our reasons for being suspect or dubious upon their initial release these solutions eventually rounded the corner and established themselves as standard technologies, core to the Horizon stack.  I think the case will be the same for Universal Broker simply because it has a lot going for it.  First and foremost, it's not a solution looking for a problem, but rather a purpose built solution for addressing a Horizon specific requirement.  More notably, the way it solves this challenge from the cloud makes it both clever and easy to deploy, while lending Horizon admins a greater degree of autonomy.  Eventually, its adoption will become the path of least resistance.  I wouldn't necessarily implore admins to rip out their current working implementations of CPA\GSLBs and slam this technology in.  However, as new multi-site implementations get stood up I think the customer base will slowly migrate over to this new solution.  By the time it becomes a new standard we probably wont even call it Universal Broker anymore.  It will just be multi-cloud assignments through the Horizon Control Plane, something we take for granted.  

Wednesday, August 3, 2022

If You Can't Bring Your Virtual Desktop To The Cloud, Bring Cloud To Your Virtual Desktop

In late June of this year I had the honor of pre-recording a VMware Explore session with Todd Dayton and Cris Lau.  The session, "Can't Take Your Virtual Desktop To The Cloud? Bring Cloud To It,"  focuses on ways to enhance on-premises Horizon environments with VMware hosted services.   It stems from a recognition that shifting VDI capacity to the cloud is not quite feasible for many customers, at least not yet.   As Todd put's it, "VDI really isn’t an application workload itself. It’s a support system for Windows applications that typically can’t or wouldn’t be modernized….These Windows applications aren’t always a great cloud candidate."  So, sure, you can stuff any application in a cloud based desktop, but if it's too resource hungry, too latency sensitive, or generates too much ingress/egress traffic there could be problems.  Performance or cost savings, or both, can take a serious hit.  For this and other reasons lots of customers have decided to keep virtual desktop workloads on-premises.  However, all is not lost.  There's still plenty to gain from slathering cloud services on top of existing on-premises Horizon environments, shifting management, monitoring, and security to VMware's SaaS offerings.   

These VMware hosted services ease the burden of on-premises Horizon management while wrapping modern capabilities around traditional Windows workloads.  For day 2 operations the Horizon Control Plane, with features like the Universal Horizon Console, Help Desk Tool, and Assist for Horizon, enables effective support  from anywhere in the world.  Further, a subset of the Horizon Control Plane called the Cloud Monitoring Service (CMS) offers high level monitoring and reporting against Horizon from the cloud, capabilities recently improved upon through Workspace ONE Intelligence for Horizon.  Along with SaaS based support and monitoring there's the ability to enhance remote Horizon access with cloud based Workspace ONE and Carbon Black.   These services allow customers to wrap modern capabilities around Horizon sessions while facilitating adoption of 3rd party SaaS like Office 365, Okta, and ServiceNow.  The end result is a comprehensive remote access solution, an on-premises Horizon environment augmented with cloud based services to deliver a digital workspace for remote and hybrid workers. 

COVID-19 Brings Horizon Remote Access To The Foreground

Horizon is more relevant than ever given the spike in remote and hybrid work driven by the pandemic.  For nearly 15 years Horizon had been a relatively niche solution, adopted primarily by segments sensitive to security and regulations.  Despite this narrow vertical adoption, over the years Horizon progressively improved at remoting Windows through updates to its clients, agents and the Blast display protocol.  This finely tuned capability was an absolute godsend as customers scrambled to accommodate remote access in the early days of the pandemic.

While Citrix and Horizon are very similar solutions, a clear distinction emerges as one explores innovations for remote access.   For Citrix, remote access centers around hardware based versions of Citrix ADC, the artist formerly known as NetScaler.   You place these multipurpose network appliances in your DMZ and, as they are packed with impressive but for most customers largely extraneous features, they cost a small fortune.  In contrast, remote access for Horizon is handled by a free and flexible software based solution, a virtual appliance called Unified Access Gateway (UAG).  It's a mature bespoke technology for securing remote Horizon access with a proven track record integrating with 3rd party solutions to beef up security.  That said, it shines brightest when we combine it with the Workspace ONE suite to wrap functionality like identity and modern management around remote Horizon sessions.  This approach enhances remote access from the cloud while allowing customers to purchase germane technology a la carte. 

VMware Hosted Services Wrap Comprehensive Security And Management Around Remote Horizon Access

Over half a decade ago Workspace ONE UEM (AirWatch) was already shifting towards predominantly SaaS based adoption.  There's certainly exceptions, but generally speaking Workspace ONE UEM is a cloud first solution.   The same goes with Workspace ONE Access nowadays, as customers are entitled to a SaaS based tenant through their Horizon Universal subscriptions.  Offering a unique integration of identity and endpoint management capabilities, WS1 UEM and Access combined offer amazing enhancements to remote Horizon access like contextual authentication, endpoint management, and SSO.  This ideal model for remote and hybrid workers is further enhanced through Workspace ONE Intelligence.  Intelligence, along with providing advance reporting capabilities, enables ruthless automation against WS1 UEM environments as well as any 3rd party solutions supporting REST APIs.  Finally, Carbon Black, a VMware acquisition from 2019, provides cloud based next-gen antivirus for Windows 10 and macOS.   When these VMware hosted services are combined with Horizon you get a solution ideally suited for remote and hybrid workers, a superb remote access Horizon experience augmented with mature cloud based security and management. 

These SaaS offerings wrap remote Horizon sessions in modern capabilities like Zero Trust, beefing up security for Windows applications that historically have been less than secure.   Further, while these services are a natural fit for remote endpoints, we can also use them to manage virtual desktop images themselves.  WS1 UEM can be used to manage persistent VDI and Carbon Black is supported on both Instant Clones and Full Clones.  Likewise, WS1 Access can be used to secure SaaS adoption both inside and outside the virtual desktop. 

Harnessing 3rd Party SaaS Based Solutions For An Enhanced Horizon Experience

When it comes to enhancing Horizon from the cloud it's not just about VMware hosted services, but also 3rd party SaaS like Office 365, Okta or ServiceNow.  For over a decade WS1 Access has made access to 3rd party SaaS easy and secure for Horizon users.  Within the virtual desktop it offers incredibly convenient consumption of SAML integrated applications through the WS1 portal or directly from any supporting Windows apps.  Outside the virtual desktop security can be fully addressed by WS1 Access and the rest of the Workspace ONE suite.  As with Horizon, we can use the Workspace ONE suite to enhance and secure access to these SAML integrated solutions. 

In addition to enabling the adoption of cloud based service providers, there's the option to leverage solutions like Okta, Ping or Azure as identity providers.  By configuring these services as trusted IDPs we can leverage their authentication mechanisms for securing Horizon or any other Workspace ONE integrated application. It's a way to beef up the already impressive set of Workspace ONE security capabilities, another way of bringing cloud to the desktop. 

Finally, there are two very interesting ways in which Workspace ONE Intelligence facilitates cloud adoption.  First, through the Trust Network it can ingest threat events not only from Carbon Black, but other cloud based members of the Trust Network like Lookout.  Second, events collected in the Intelligence data lake can trigger actions through automation connectors.  Out of the box there's built-in connectors for WS1 UEM, Slack and ServiceNow, however there's an option to create custom connectors for any solution that offers a REST API. 

These automation connectors represent an amazing opportunity to fine tune enhancement and support of Horizon environments from 3rd party cloud services.  Horizon admins are usually grizzled veterans when it comes to scripting within the desktops.   With Intelligence they can now turn their attention to scripting against SaaS, automating REST API calls to 3rd party cloud solutions that are becoming increasingly relevant.

The Horizon Control Plane Services 

Horizon Control Plane Services enable day 2 support for on-premises Horizon environments from the cloud.  Its Horizon Universal Console provides Horizon administration enterprise wide through a single web based URL while also providing global access to the Help Desk tool.  So a support team, wherever they are in the world, without the need for direct network access to Horizon environments, can look up real time session details for any Horizon user.  They'll also have the ability to troubleshoot through actions like killing processes or restarting VMs.  If necessary there's even an option to remote into a virtual desktop using Workspace ONE Assist for Horizon.  Finally, for more high level support and monitoring, "the big picture," there's the Cloud Monitoring Service (CMS).  CMS provides health, capacity, and usage metrics for any cloud connected Horizon environment.  (For example, if a certificate expires on a Horizon Connection server, this challenge will trickle up to the Horizon Universal Console through CMS.)  The Universal Console, the Help Desk tool, Assist for Horizon and CMS all connect to on-premises environments through the Horizon Cloud Connector and clone Worker Node(s) that provide redundancy.   

While CMS provides high level insight Workspace ONE Intelligence for Horizon provides additional detail, granularity and customization in terms of monitoring and tracking the health of your on-premises Horizon environments.  This provides more in-depth support for day 2 operations while laying the ground work for future Workspace ONE integration with Horizon.

Workspace ONE Intelligence For Horizon 

Workspace ONE Intelligence For Horizon was first announced during VMworld 2021 and as of July 28th, 2022 is generally available.   This rounds out the overall strategy of porting information from all VMware EUC components into Intelligence.  For someone that specializes in both Horizon and Workspace ONE this is welcome news.  Intelligence has been offering advanced reporting and automation for WS1 UEM for years now and it's great to see VMware extend this functionality to Horizon.  

This first iteration provides built-in dashboards, custom reports, and custom dashboards, expanding beyond the canned reporting capabilities of CMS.  We're talking boat loads of raw and relevant data regarding the health and performance of Horizon. Just to give you a taste of how vast this dataset is here are screenshots from Intelligence custom reports detailing visible attributes from Horizon PODs, Pools and VMs:

Even more impressive and overwhelming are the available, "Session Snapshot," attributes:

So yeah, there's a lot to work with here. While this info is relevant for Horizon health and performance monitoring across the board, it certainly rounds out the already impressive model of supporting remote Horizon access with cloud based services. When troubleshooting performance challenges with remote access it can provide critical network insight like display protocol packet loss and round trip latency, along with detailed information of virtual desktop resource usage.  You also get invaluable context regarding general POD health and performance.  Finally, you get the ability to slice and dice through this information with WS1 Intelligence customizable dashboards and widgets, allowing you easily zero in on and visualize relevant data.

The fact we get this info enterprise wide from a cloud based service is quite compelling and affords Horizon customers an opportunity to really up their game in terms of monitoring Horizon performance.  Further, as a cloud based service that leverages Horizon Cloud Connectors many customers already have in place, it's very accessible and easy to stand up.  (It took me less than 15 minutes to get it working for my lab.)  Finally, it comes standard with most of the new Horizon entitlements at no additional cost, so the price is right.  

A VMware Explore Session On Extending Cloud To The Virtual Desktop

Though not everyone is ready to move their VDI workloads to the cloud all existing Horizon customers stand to benefit from the adoption of VMware hosted services.  These services, already available today, can be layered on top of existing Horizon environments non-disruptively and easily.  These are the main takeaways of the explore session,  "Can't Take Your Virtual Desktop To The Cloud? Bring Cloud To It."  It begins with an amazing introduction from Todd Dayton.  He elaborates on the benefits of cloud adoption, challenges with Windows workload migrations to the cloud, and the ideal compromise of shifting Horizon management to the cloud.  Then Cris Lau provides an impressive demo of the Horizon Universal Console, Help Desk tool, Assist for Horizon and Intelligence for Horizon.  Finally, I wrap things up reviewing ways we can enhance remote Horizon access with cloud based Workspace ONE and Carbon Black. 

Also, one final anecdote.  Todd pointed out that even if you're confident your virtual desktop workloads will eventually get migrated to the cloud there's absolutely nothing lost if you start off with these cloud based enhancements to your on-premises environment today.  It's not like you'd be burning any bridges or painting yourself in a corner.  In fact, arguably you'd be stacking the deck in your favor for a successful workload migration by already having cloud based management services configured, adopted and in place.  So there's really nothing to loose except the burden of managing on-premises resources. 

Tuesday, May 3, 2022

Driving Horizon Automation With WS1 Intelligence, Postman, And The Horizon REST API

Last year I published, "Ruthless Automation With Workspace ONE Intelligence," an article highlighting the impressive automation capabilities of Intelligence.  Well, in this post I'm going to detail adaptations to WS1 Intelligence that provide even ruthlesser automation! Huzzah!  Using Postman webhooks and VMware's Unified Access Gateway you can amplify the sophistication and reach of Intelligence Custom Connectors.  While any solution supporting a REST API may benefit from either enhancement, a Horizon on-premises environment benefits from both, making it an ideal use case to demonstrate.  Traditionally Horizon has been out of reach from Intelligence automation but Postman webhooks and UAG's web reverse proxy capabilities combine to close the gap and enable the use of Custom Connectors for Horizon.

In the illustrated solution a REST API call is triggered by a defined event within the Intelligence data lake, as with any Custom Connector implementation.  However, the call made from Intelligence is to a Postman webhook Url rather than directly to the Horizon environment.  The webhook triggers an entire collection to run from the Postman cloud against the Horizon environment, an activity that's tracked and managed through a Postman Monitor.  This allows Intelligence to trigger much more sophisticated REST API calls that are chained together and build upon each other, shifting complex logic to the Postman cloud where it's executed and tracked for fractions of a penny.  Further, the reach of these calls from Intelligence are extended to an on-premises environment by using UAG as a web reverse proxy.  This is critical for providing access to the Horizon REST API from the Postman cloud.  The video below demonstrates both enhancements working in concert to integrate Intelligence and Horizon on-premises.  

In the demo above actions against the Horizon environment are triggered manually using a test feature of the Custom Connector built for Horizon.  However, in the demo below actions against Horizon are triggered by Carbon Black malware detection on an endpoint device, as dictated by a configured Intelligence automation workflow.  

Again, both Postman webooks and UAG's web reverse proxy capabilities have potential to enable or enhance integration between Intelligence and any other REST API, not just Horizon's.  So a deeper understanding of these adaptations is useful beyond the Horizon use case and could be of interest to anyone looking to explore options for WS1 Intelligence Custom Connectors.  

This post reviews in depth an integration between Horizon and Intelligence, starting with the Postman client and Horizon REST API. It explains the logic behind API calls executed from Postman, followed by a discussion on how UAG, acting as a reverse proxy, enables communication between the Postman cloud and on-premises Horizon environment. Further, it details the creation of webhooks in Postman as well as the configuration of Custom Connectors within Intelligence.  Finally, it wraps up with a few security considerations and final thoughts.

Getting Up To Speed On Postman

Creating the Custom Connector detailed in this post definitely requires familiarity with Postman and REST APIs.  Fortunately, the Postman website includes a Learning Center with incredibly helpful walk-throughs.  Within minutes of reviewing this site I got my hands dirty with essentially the, "hello world," of Postman requests, postman-echo/get.  This call leverages an open API server that doesn't require any kind of authentication, providing a very accessible introduction to REST API calls from the Postman client.

Along with the Learning Center itself, there's enablement available from Valentin Despa on YouTube. He has a 3 part video series called, "Introduction To APIs," providing an excellent overview of the how and the why of REST APIs and API clients like Postman. Then there's his 6 part, "Intro To Postman," series which I absolutely loved. After working through this series I found myself dangerous enough to start hacking together my desired solution.

The series teaches that accessing a REST API from Postman can be as simple as executing a request against a single URL.  However, for more complex operations you can chain multiple calls together in a collection.  This allows you to take output from one call, then distill and leverage it during the execution of subsequent calls.  Variables are passed from call to call, with JavaScript running within the Tests and Pre-request Scripts associated with each call.  In a nutshell, your collection is a series of calls executed in a specific order, with chunks of JavaScript potentially performed before and after each call.  Despa covers chaining in episode 5, "Chain Requests." 

Finally, since the Tests and Pre-request Script scripting is based on JavaScript, well, there's a whole internet out there to help you work through that.   While I've executed Hello World in countless languages and have certainly gotten hot and heavy with VBScript and PowerShell, I had no prior experience with JavaScript.  However, through Google-fu I was introduced to foreach loops and if statements, along with some variable management, and that was enough for me to get cooking with JavaScript.  I think anyone with scripting experience could find themselves getting dangerous with Postman pretty quickly if they were motivated. 

The Horizon REST API 

Info on the Horizon REST API is available directly from the Horizon Connection Server by pointing your browser to https://<Your-Connection-Server-FQDN>/rest/swagger-ui.html.  However, there's a must see article available from VMware's Tech Zone, "Using The VMware Horizon Server REST API," written by Chris Halstead.  It provides an introduction to the Horizon REST API along with demonstrations on how to use its endpoints, "in combination to achieve your goals."  Along with tons of useful information, it includes a link to sample collections that can be directly imported into your Postman workspace.  The linked resource, available on VMware {code}, is called, "Postman Collection - Horizon REST API."  With Postman already open on my machine I clicked on the button, "Run In Postman," and voila, I had over a 100 preconfigured calls to work with.  

Dang!!!  Talk about making folks dangerous quick.  With a free Postman account you can import these samples and begin making calls against your local Horizon environment in a matter of minutes.  Just update a handful of collection level variables and you're off to the races.  These variables are required to successfully execute a call to the login endpoint on the Connection Server.  A successful call returns a token from the Horizon environment that is assigned to a global variable which in turned is used by the rest of the sample calls for authorization.  While some sample calls require additional information/parameters, many are immediately available once you've executed the login call successfully,  such as all the Monitor samples.  Other calls, arguably the more interesting ones, require additional info. For instance, the disconnect endpoint requires an active session ID from the Horizon environment to target its action.  Chaining calls together to execute more complex actions like this is what we'll review next. 

The Basic Logic Behind My Collections

All four collections associated with the Custom Connector detailed in this post follow the same basic logic, so we'll review just one of them in detail.  The collection, "Disconnect Horizon Session," is made up of 5 different calls to the Horizon REST API, each of which was copied from Halstead's samples.  The collection begins with a call to the login endpoint that uses the token returned to authorize the next 4 calls.  Based on an AD username fed to the collection - more to come on that a bit later - the second call retrieves a list of AD accounts from the Horizon environment, finds the matching AD username, then passes the associated user_id to the next call via a global variable.  This 3rd call retrieves a list of sessions from Horizon and finds the session associated with the targeted user_id.  The matching session yields a session id that's key to executing the final two calls to the send-message and disconnect endpoints.  

The first 3 calls are the real work horses of the collection, performing the critical task of locating the session ID to target.  All the logic happens in either the Pre-request Script or the Tests associated with each call.  For instance, here's the JavaScript used with the call to ad-users-or-groups:  

In a nutshell, we're taking the response of our call to ad-users-or-groups endpoint and saving it to jsonData. Then we're fetching the global variable, "user" and adding that value to a local variable called targetUser. Finally, using a foreach function, each object stored within jsonData is walked through while comparing its AD account name with the target username. If there's a match, the ID associated with that matching AD account is copied to a global variable called user_id. This user_id global variable is then consumed by the next call to the sessions endpoint. The sessions endpoint call uses pretty much identical JavaScript logic.

Looks familiar, right? The names have changed, but the logic is identical. The response to the sessions endpoint call is copied to jsonData. Then each object returned is searched for a matching user_id. When a match is found that objects session ID is copied to the global variable SessionHunt. And then the fun begins, with the session ID getting fed to the next call to the endpoint session-message.

And boom, you've got a message getting sent to your user's session.

Finally, there's the actual disconnect. Similar to the send-message call, the SessionHunt global variable is used to target the action.

And there you have it. Waka! Waka! 5 REST API calls, 2 foreach loops, two if statements, a handful of variables later and you've got yourself a sweet little collection for automating the task of messaging and disconnecting a specific user. An entire collection like this can be executed in sequence by right clicking on the collection and selecting the option, "Run Collection."

Now, to make these actions accessible from Workspace ONE Intelligence a first step is to make the Horizon REST API available to the outside world. While there's countless solutions for achieving this, I'm going to turn to one of my favorite and dearest pieces of technology, VMware's Unified Access Gateway.

Making Calls Remotely Against An On-Premises Horizon Environment Through UAG

While not the most popular of use cases, Unified Access Gateway (UAG) can act as a web reverse proxy.  It's been a feature for years now, originally developed to provide access to on-premises vIDM environments, but now available for any on-premises resource.  For my lab UAG plays the key role of making the Horizon REST API accessible to Postman, more specifically Postman Monitors that live in the cloud and are triggered by webhooks. 

Fortunately, the configuration as a reverse proxy is fairly straightforward.  The trickiest part is configuring the proxy pattern.   To narrow down the reverse proxy functionality to only the REST API destination URL I went with this for a proxy pattern:  (/rest(.*))

This prevents the reverse proxy from exposing the entirety of the Horizon Connection server to the outside world.  Instead, only access to the REST API is possible when hitting the UAG appliance with a URI path that's matched to the destination url for the Horizon REST API. 

UAG's web reverse proxy capabilities provide Postman Monitors access to the Horizon Connection Server's REST API, allowing us to run collections against the Horizon environment whenever they're triggered by Intelligence.  With a collection in Postman configured and reverse proxy solution in place, the next step is to create a webhook to trigger collections that runs across the UAG appliance. 

Creating the Webhook To Your Postman Collection  

While we can make calls directly to 3rd party REST APIs using a WS1 Intelligence Custom Connector, we can only make a single call at a time based on data already located within Intelligence.  There's no option to probe these 3rd party REST APIs, collect some input, then process it in additional follow up calls.   However, that's exactly what we need in order to do anything interesting with the Horizon REST API: chain multiple calls together.   For instance, with the collection I walked through earlier, we're executing 5 different calls, passing variables from the first 3 calls to the final 2.  To accommodate this challenge, we can leverage Postman webhooks to trigger a run of an entire collection stored in the Postman cloud.  

Creating a webhook generates a Url that can be called upon by a WS1 Custom Connector to trigger the collection associated with the webhook.  Further, we can pass variables from the Intelligence data lake to the collection in the process of making a call to the webhook.  In the case of the collection detailed earlier in this post, WS1 Intelligence passes an AD username to the collection through the webhook. While there's official documentation on webhooks in the Postman Learning Center, "Triggering Runs With Webhooks,"  I found this short and concise recorded presentation on Youtube, "Postman Webhooks," to be really helpful. (There's also a very interesting, though much longer, youtube video on Postman webhooks called, "Automate All The Things With Webhooks.") 

As you can see in the video a webhook is created leveraging the Postman API and an endpoint called webhooks.   Making this call successfully requires a workspace ID,  an API key for your Postman account, and a UID for the collection you want to trigger with the webhook.   Locating your workspace ID is easy enough, as you can see in the guidance provided here.  Generating an API key is fairly straight forward and is one of the first things covered in the official documentation for the Postman API.   Once you have this key generated and copied you can use it to obtain the required collection UID using the Postman API's collections endpoint.  To make a successful call against this endpoint you need to include the API key in the header, populating it as a value for the key, "x-api-key."    

With this proper header key in place execution of the call generates a response with info about all your collections, including the UID for the specific collection you want to trigger with your webhook.   With the collection UID and workspace ID in hand you can create your webhook, populating the body of your request with the UID and adding the workspace ID as a parameter. (As with the call to the collections endpoint you'll need to include the API key in the header.)    Successful execution will yield a webhook Url that can be called upon to trigger your collection.  In the example below, a webhook Url of,, has been created and associated with the collection. 

When making a call to this webhook behind the scenes your leveraging Postman Monitors.  These provide you the added bonus of a paper trail/tracking of collection execution.  For each webhook you create there'll be a corresponding Monitor within your Postman workspace. 

When trying to figure out what went wrong with collection execution, or, more optimistically, what went right, you can drill into the events detailed under each monitor to get play by play action.  Below, you can see all the calls that were made as a result of the collection getting triggered by its associated webhook at 2:34pm.  

You can also get more in-depth, play by play insight, by clicking on console log.   

So, as if having the ability to trigger collections with a webhook Url wasn't enough, you also get the tracking and performance visibility normally afforded by Postman Monitors.  Next, we'll create a Custom Connector that makes a call to our Postman webhook, completing a circuit between the WS1 Intelligence cloud and the on-premises Horizon environment.  

Creating A Custom Connector To The Webhook

While WS1 Intelligence provides out-of-the-box integrations with UEM, ServiceNow and Slack, for years now it's offered the option of using Custom Connectors to integrate with any solution that supports a REST API. A Custom Connector can be setup to make calls to a Postman webhook by following the same guidance that's always applied to Custom Connector creation. Accordingly, useful guidance can be found is a post by Andreano Lanusse and Adam Hardy called, "Workspace ONE Custom Connector Samples." Along with providing incredibly useful samples the article lays out the steps for creating your own Custom Connectors. The basic process is to craft an API call in Postman, save a successful result of the call, export the call as a json collection, then import the exported json into Intelligence while creating a Custom Connector. Accordingly, I went to Postman and created new collection called, "Disconnect Horizon Desktop - Execute webhook," placing in it a single call to the webhook Url that triggers the, "Disconnect Horizon Session," collection detailed earlier.

We can pass variables from WS1 Intelligence through a webhook.  In this example we're passing an AD username from Intelligence as a value for, "username2."  The triggered collection is designed to ingest this parameter and target its search accordingly.   Before exporting this collection, you need to execute this call successfully, then save the result as a sample.   

At this point, you're ready to export the collection by navigating to collection, clicking on the 3 dots representing, "View more actions," and selecting export.

Go with the, "Collection v2.1," option and the exported json will download.  Next, go to the WS1 Intelligence console, navigate to Integrations --> Outbound Connectors, and select add custom connector.  For a base URL, you'll enter in the base url for your webhook, 

Next, you're prompted to import your exported collection.   Consistently I've run into challenges importing my own hand made custom connectors at this point with an error message of, "Invalid Postman JSON file: Content-Type header must be present."   

This pitfall is referenced in the sample custom connector guidance article, which cautions, "Note: Consider adding headers as Content-Type: application/json. If you do not add headers as the content type JSON, the APIs can default to XML and XML does not work with custom connections."  Accordingly, one way I've gotten around this challenge is by copying the header from the working samples and inserting them into my custom connectors.   So it's all about replacing the default header on these exported collections from what's displayed here: 

    "method": "POST",
    "header": [

    "body": {

With this:

    "method": "POST", 

    "header": [ 


            "key": "Content-Type", 

            "name": "Content-Type",

            "value": "application/json",

            "type": "text" }


    "body": {

Once I made this edit to my exported collections the imports completed successfully.  In the end, after following this entire process for each of the collections a webhook was created for, I had these actions available from my outbound connector within Intelligence:  

While each action leverages a different collection, all actions traverse the same basic path:

Intelligence --> Postman webhook --> UAG --> Horzon REST API

To summarize, you have Intelligence triggering the Postman webhook based on reporting and automation configured within Intelligence.   The calls within the collection are executed from the Postman cloud, traversing the UAG web reverse proxy to the internal Horizon Connection Server.  Information about the environment is ascertained through a handful of initial calls and then leveraged by subsequent calls to target the automations within the internal Horizon environment.

Security Considerations

Exploring an option like this is destined to bring up security concerns. Below are a few I've run across as well as some relevant considerations.

Storing credentials in Postman:
Yes, scary indeed, particularly given that Horizon REST API credentials require root access for Horizon administration. However, any credentials stored in a Postman variable in your collections will be, "encrypted on the server-side before storage." Further, Postman has recently introduced support for MFA when you register using a Google based account. While both encryption and MFA take the edge of this concern, it should also be considered that the REST API credential account doesn't necessarily have any special AD rights.

Accepting Horizon Admin Credentials Through Public URL:
Having to open up an administrative REST API of your internal Connection Server to the external world is certainly a bit nerve wracking. However, the Professional and Enterprise Postman customers have the option to run their monitors with static IPs.  So, through firewall rules you can limit access to your UAG appliance to the public IPs used by Postman Monitors. That certainly reduces your risk. Also, while it hasn't been built yet, there's definitely Postman customers asking for the ability to leverage certificate auth for Postman Monitors. (I have seen client certificate authentication work through UAG for Postman requests from laptops, but it's not supported from Monitors yet.)

Triggering Administrative Actions Through Webhooks:
 I'll forgive anyone for being nervous about raining down ruthless automation from the sky based on calls to webhooks. However, my understanding is that webhooks are often known to rely on security by obscurity. The Postman webhook Urls are pretty long and ugly and I'm not sure how easily they're ascertained. I've had monitors running for over a month now and I haven't seen a single unsolicited request. Further, these webhooks aren't exposing folks to any credentials or direct access to Horizon. Bad guys can make calls to them for cheep thrills or random maliciousness but the chances of them getting any meaningful access to anything doesn't strike me as high. They're simply calls to perform administrative tasks with impact that depends on what's been automated. In addition, all these calls are tracked through Postman Monitors so you would have a paper trail. All that said, if push comes to shove, there definitely appears to be some do it yourself options for securing webhooks.

I'm Still Freaked Out:
Yeah, I get it. I think if security is a real sticking point for your team you could always develop your own full blown REST API. While developing your API would not be for the faint of heart, this post should provide a clear path forward to guide your development.

I certainly respect there's security considerations and concerns to address before implementing these adaptations. However, I think the subject is much more debatable than it seems at first blush and for some folks the benefits could out weigh the risks. Is the juice worth the squeeze? Well, depending on your use case, the juice could be awfully sweet. (If everything about these Custom Connector adaptations sounds awesome to you, but security is a real gotcha, I'd love for you to leave some comments, particularly around what use cases you have in mind.)

Final Thoughts 

The integration between WS1 Intelligence and Horizon detailed in this article is complicated and a lot to take in.  In a cantankerous mood you might go so far as to say, "it's a hot mess."  But, you know what's often the case with hot messes?  They hot, and this solution is absolutely, utterly, freaking gorgeous!  Driving automation against a Horizon environment based on a data lake in the cloud?   Hot!!!  Further, there's potential for the adaptations leveraged to span far beyond the Horizon use case.  UAG can extend the reach of Intelligence to any REST API within an on-premises environment.  Postman webhooks can increase the sophistication of REST API calls made to any 3rd party solution.  Combined together these adaptations significantly expand the reach and efficacy of Intelligence Custom Connectors.

Finally, as complex as the Horizon integration is, the overall objective is very much in line with the trajectory of VMware's EUC stack. "If you can't bring virtual desktop to cloud, bring cloud to the desktop," seems to be the battle cry for the entire Horizon suite, with more and more functionality getting shifted to the cloud even if workloads must remain on-premises.  Past success with SaaS based EUC solutions like UEM, Access and Intelligence not only enhance Horizon security, but also represent a shift to cloud management VMware's is striving to emulate for the Horizon stack.  For that matter, all of VMware seems to be charging in that direction, including vSphere itself.  It that light, the solution detailed in this article seems more like acceleration to a very probable destiny rather than some off the wall innovation. While this seemingly destined future isn't here today, in the meantime, if you've got the will for this functionality there's a way.