On Monday, VMware and Microsoft officially kicked off a foundational public preview that was announced almost a year ago: The Windows 365 and VMware Horizon integration that would bring “stuff” to Windows 365. We weren’t really sure what “stuff” that would be. Now, we know that some of those things are:

• Accessing Cloud PCs from the Horizon Client or Horizon Web
• Streaming your Cloud PC powered by the Horizon Broker with the amazing BLAST protocol
• AppVolumes integration (coming soon!)

Today, we will show you some really compelling things. First, we will cover how it actually works, how to set it up, and the user experience behind the new amazing friendship that has one true winner: YOU

How the Windows 365 and Horizon Integration Works

I figure most people don’t know much about the Horizon Cloud and even fewer know about NextGen. I think this is a logical place to start. This graphic is a basic representation:

Basically, in NextGen they’ve done a great job simplifying architecture. The brilliant thing is that you don’t need to worry about most of this with Windows 365. The entire Horizon Edge is out of the picture. We shift focus to a few key areas, which we will discuss now.

Horizon Cloud Providers

Providers are the lifeblood of the architecture. Providers are VMware-supported hypervisors and cloud platforms that provide the necessary resource capacity to deliver desktops and applications to end users. Typically, it’s been irrelevant as its only Azure, but now we have the new Windows 365 provider.

Normally, your provider would have Edges (A Horizon Edge is an instance of Horizon deployed into your resource capacity provider in a single region with the resources to deploying stuff like desktops and apps).

Luckily, that isn’t what the Windows 365 provider does. Our Windows 365 provider is sort of like a centerfielder telling the integration what your Entra ID directory is, what your UAGs are (more on this later), etc.

When you setup your Windows 365 provider, you’re tying in the Identity Provider (which is only Azure currently), the Enterprise App Integration for Horizon/Windows 365, and the Desktop, which we discuss next.

Desktop Pools and Pool Groups

Once you setup a provider, it creates a Desktop Pool with a Pool Group.

Basically a Pool Group is created by the provider. Pool groups allow you to entitle desktops and applications to any users or groups at any time. You can’t create additional pool groups (with Windows 365) as it does all of that for you.

You do get the ability to entitle your Pool Group to any Entra ID users or groups. Normally, you would create your desktop pools, which are added to pool groups, but this operates a bit differently from a Horizon Cloud NextGen setup to support the design by Microsoft and VMware.

The Managed Unified Access Gateway

The most interesting part of this setup is the new managed UAG component. I’ve written extensively on the UAG historically. Our UAG workflow is going to look very similar to this. Specifically, the UAG which is now a VMware managed service with this offering will sit in front of an Azure Load Balancer in a HCS (Horizon Cloud Service) Cluster. You can feel fancy because its not just any cluster, but a Kubernetes cluster! FANCY! You can read more in-depth about the Horizon Architecture here.

The Horizon Service Universal Broker

The final piece we want to discuss is the Horizon Universal Broker. The broker is a cloud-based brokering technology that facilitates brokering to desktops and apps for end-users across your Windows 365 integration. It’s completely infrastructure agnostic and brokers anywhere!

The core components include a VMware Horizon Client authenticating to the Horizon Cloud Service, which brokers connections to Cloud PCs and Apps. In a traditional Horizon Edge, this is a great example of how the Horizon Agents on your Cloud PC are communicating back to your Broker to ensure the connectivity functions as intended. Part of the integration involves the Horizon Control Plane pushing down a customized Horizon Agent to all Cloud PCs to make the magic happen!

Integrating the Windows 365 Provider to VMware Horizon

The Windows 365 provider setup, involves 4 parts:

• Switching or Setting up your IDP to Microsoft Azure (WS1 Access isn’t supported yet)
• Enabling the Windows 365 Partner Connector
• Connecting the Enterprise Application to grant the necessary permissions
• Entitling the Pool

My short video below will walk you through all of these setups, which are really simple, but let me provide a few tips:

1. Set the IDP “Company Domain” to whatever you want people to put in when logging into the Horizon Cloud console for the auto-discover.
2. Be careful with entitlements, I noticed if I remove my own entitlement from a pool it breaks entitlements (which I’m sure they fix, because I’m always breaking things)
3. Make sure you enable the partner connector first otherwise you will run into some fun errors like this:

Enjoy the video, as it covers it pretty easily. The real fun is coming next:

Installing the Horizon Agent in Windows 365

It’s important to preface that the Horizon Agent is a work-in-progress between people like me, VMware, and Microsoft to get it right (but it’s a Public Preview duh!). Once things go GA, it will be an automatic agent push when entitlements sync, but for now I’m finding manual provisioning to be most effective. The steps will be covered in the article. Check out the video demo below:

I came up with a really neat way of doing manual pairing below:

Unblock-File onboard.ps1
$PairingData = Import-Csv "C:\temp\manual_pairing_data.csv"
.\onboard.ps1 -hdcToken $PairingData.'HDC Pairing Token' -tenantId $PairingData.'AD Tenant ID'

One thing I did misspeak on, you need to see a status of “Agent Installed” for things to be in good shape.

The Windows 365 and Horizon User Experience

If you did everything right, you should see this as your final product: (truthfully I’d rather see the pool name, but still pretty neat)

Now, let’s check out our video demo:

Final Thoughts

For a public preview, things are coming along pretty well. We do have a few gaps that are still in the works like:

• SSO
• Only TCP streaming and no auto-reconnect
• Only 1 Cloud PC support

There are a few others as well, but overall I think this is a great experience even when network issues are prevalent. This is certainly a huge step in the evolution of Windows 365. Next up, we will cover the AppVolumes capabilities that are coming once the BETA releases in the near future!