Recently, I covered the first piece of the VMware Horizon and Windows 365 integration. Accessibility inside of the Horizon client and the Blast Extreme protocol elevate Windows 365 in a huge way. Today, we are covering the second part of this integration with App Volumes. Something I am coining “Instant Apps to Windows 365” handles the biggest challenge with Windows 365 (the wait!) We shift from relying heavily on Intune app deployments and move to an amazing new technology that separates apps from the OS and mounts apps at logon.

Today, we will discuss the architecture of App Volumes (for many of you who don’t work on the VMware side), installing and configuring App Volumes Manager (AVM), capturing applications, deploying apps, and the amazing user experience we deliver with this new capability.

Why App Volumes on Windows 365?

First, we start with why App Volumes with Windows 365?

The one challenge with Windows 365 is we rely heavily on Intune replication and app deployment timing, which can sometimes take a few hours. That just doesn’t work in some enterprises where there are TONS of applications. Enter, VMware App Volumes!

App Volumes helps deliver a few things:

• Agile delivery leveraging App Volumes to simplify application management. It delivers synergy between OS and applications despite being completely separate.
• Application flexibility by deploying apps, easy rollbacks, and effective app lifecycle management.
• Lowers IT costs by making application delivery easier, less invasive to use, and reduce unused app infrastructure.
• Empowers app modernization with faster app delivery, simplified app management, and easier packaging.

It’s easy to see that for customers with investments in VMware Horizon that the combination of Windows 365 and VMware App Volumes is a no-brainer.

App Volumes Architecture

App Volumes is a container-based model which decouples things like profiles, settings, and applications from the provisioning policy in Windows 365:

At this juncture, profile and settings are not things that are being considered as far as I know. Apps on their own are a great area to enhance for Cloud PCs. The overall best practice for Windows 365 is to avoid images and just use the base images available for OS optimzations/Office 365. This makes them a great fit.

You can deploy apps in one of two ways:

• Login (When the user logs in)
• On-Demand (App icons live on the desktop, which will dynamically mount the volume) (On-Demand is not a focus at this time, but I will revisit it at some point in the Public Preview)

Essentially, the way it works is:

1. App Volumes Agent is installed on the Cloud PC
2. Agent talks to App Volumes Manager to determine entitlements
3. VHDs are attached to the Cloud PC

Let’s discuss a few of the components for clarity:

• App Volumes Agent is the end-user component of App Volumes that enables on-demand delivery of apps using a mini-filter driver to abstract the file system and registry from the OS.
• SQL contains config info for apps, packages, and user entitlements
• Active Directory is the vehicle for assigning/entitling users to packages
• Storage Groups are groups of datastores for package replication.

One thing to note is the beta version of App Volumes which has a “Persistent VDI Mode” required for App Volumes to work on Windows 365 or VMs that do not refresh on logoff/restart.

The Three Layers of App Volumes

Now, we will discuss the aspects of App Volume Manager, which is the web console that we use for administration/configuration of App Volumes and assigning application packages/writeable volumes. From the Windows 365 perspective, we are focused on the application packages of course.

A Package is a read-only VHD that stores a specific version of an app. When a single app has multiple packages, one is selected with the marker of CURRENT to ensure the correct version of the program inside of the package is delivered. This is an example of a single package application:

A few best practices to mention before we start discussing the installation process.

• Kernel-mode apps should be part of an image instead of leveraging App Volumes
• Storage groups will be the best practice since vSAN will not be part of this design. Premium file shares should be considered for performance.
• Limit Applications to 8-10 per Cloud PC
• Apps that need to run when the user is not logged in should not be deployed via App Volumes

Installing and Configuring App Volumes Manager

Before we get started on this Windows 365 integration, the pre-requisite to start using App Volumes with Windows 365 is being a member of the VMware EUC Beta Program. Check out the link here to learn how to sign up. It’s a great program that gives you access to some really neat stuff VMware is working on.

The great thing about this implementation is that it is almost identical to what Horizon administrators have been doing on-prem today. There is a ton of familiarity, which limits the efforts needed to shift to Windows 365 and capitalizes on existing expertise in many environments.

Before we proceed, we need to build/configure the Azure storage account, which is the lifeblood of the entire process. That storage account will support you by storing your apps and their metadata for example.

Building and Configuring the Storage Account for App Volumes Manager

First, you will download and unzip the AzFilesHybrid module from here. My short video will walk you through the fairly simple process:

Just to help with the process, check out the code that will use to get it all done:

# Change the execution policy to unblock importing AzFilesHybrid.psm1 module
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

# Navigate to where AzFilesHybrid is unzipped and stored and run to copy the files into your path
.\CopyToPSPath.ps1 

# Import AzFilesHybrid module
Import-Module -Name AzFilesHybrid

# Login to Azure using a credential that has either storage account owner or contributor Azure role 
# assignment. If you are logging into an Azure environment other than Public (ex. AzureUSGovernment) 
# you will need to specify that.
# See https://learn.microsoft.com/azure/azure-government/documentation-government-get-started-connect-with-ps
# for more information.
Connect-AzAccount

# Define parameters
# $StorageAccountName is the name of an existing storage account that you want to join to AD
# $SamAccountName is the name of the to-be-created AD object, which is used by AD as the logon name 
# for the object. It must be 20 characters or less and has certain character restrictions.
# Make sure that you provide the SamAccountName without the trailing '$' sign.
# See https://learn.microsoft.com/windows/win32/adschema/a-samaccountname for more information.
$SubscriptionId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
$ResourceGroupName = "w365"
$StorageAccountName = "appvolumes"
$SamAccountName = "appvolumes-share"
$DomainAccountType = "ComputerAccount" # Default is set as ComputerAccount
# If you don't provide the OU name as an input parameter, the AD identity that represents the 
# storage account is created under the root directory.
$OuDistinguishedName = "OU=User Objects,DC=contoso,DC=com"
# Specify the encryption algorithm used for Kerberos authentication. Using AES256 is recommended.
$EncryptionType = "AES256"

# Select the target subscription for the current session
Select-AzSubscription -SubscriptionId $SubscriptionId 

# Register the target storage account with your active directory environment under the target OU 
# (for example: specify the OU with Name as "UserAccounts" or DistinguishedName as 
# "OU=UserAccounts,DC=CONTOSO,DC=COM"). You can use this PowerShell cmdlet: Get-ADOrganizationalUnit 
# to find the Name and DistinguishedName of your target OU. If you are using the OU Name, specify it 
# with -OrganizationalUnitName as shown below. If you are using the OU DistinguishedName, you can set it 
# with -OrganizationalUnitDistinguishedName. You can choose to provide one of the two names to specify 
# the target OU. You can choose to create the identity that represents the storage account as either a 
# Service Logon Account or Computer Account (default parameter value), depending on your AD permissions 
# and preference. Run Get-Help Join-AzStorageAccountForAuth for more details on this cmdlet.

Join-AzStorageAccount `
        -ResourceGroupName $ResourceGroupName `
        -StorageAccountName $StorageAccountName `
        -SamAccountName $SamAccountName `
        -DomainAccountType $DomainAccountType `
        -OrganizationalUnitDistinguishedName $OuDistinguishedName `
        -EncryptionType $EncryptionType

# You can run the Debug-AzStorageAccountAuth cmdlet to conduct a set of basic checks on your AD configuration 
# with the logged on AD user. This cmdlet is supported on AzFilesHybrid v0.1.2+ version. For more details on 
# the checks performed in this cmdlet, see Azure Files Windows troubleshooting guide.
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

The App Volumes Manager Install and Configuration Process

In the near future, you won’t need to install it as it is coming to the marketplace as a pre-built VM, but it’s good to know how to work through that process. Check out my video below that will take you through that process easily. In production, the recommendation is at least two App Volumes Manager servers behind an Azure Load Balancer. Additionally, you would obviously use full SQL vs. SQL Express for testing.

Replacing the SSL Certificate for App Volumes Manager

In the video below, we will go through the process which isn’t too hard. You create a CSR and get your PEM certificate and private key. You copy those into the nginx folder on AVM (c:\Program Files (x86)\CloudVolumes\Manager\nginx\conf\) and restart the service and reboot the VM.

The sample code for the openssl.cfg can be seen below:

[ req ]
default_bits = 2048
default_keyfile = svserver.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS: appvolumemanager, IP:10.0.0.4, DNS:appvolumemanager.agilewriter.ai

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = Massachusetts
localityName = Dedham
organizationName = Synterex
emailAddress = [email protected]
commonName = appvolumemanager.agilewriter.ai

The App Capture Process

A few best practices to mention before starting:

• Packages cannot have these characters: &”‘<>
• A clean machine must be used to be successful at the same OS patch and service pack level as the Cloud PCs receiving it.
• Should only have the App Volumes agent
• The packaging machine should not have had those applications previous before
• Snapshot the device first, unless you use my lifehack below.

Typically, you would create a VM and use that to capture your packages. We use a “capture machine” which is used for the app installation and capture. The capture process creates those packages that will be delivered to your Cloud PCs. The process is pretty easy. This demo below will walk you through the process of creating the application and package and kicking off the capture process. It will also show you after the capture process is completed that your package with its programs is now available in App Volumes Manager for deployment. We finish up, by assigning it to a group so we can see the amazing capabilities of App Volumes in action.

The super lifehack we came up with is using Reprovisioning on a Cloud PC as a capture machine, otherwise you would need to create an Azure VM with a Cloud PC template to capture apps. I think this is an awesome idea, which is easy to do. You just use this button:

One or two last points about updating the applications.

• You can change the CURRENT marker to get the new version out to your users. It will apply on next logon.
• Leverage the “package” assignment type to send new version to your test population before releasing to everyone.

App Volumes User Experience in Windows 365

Now, we have done some really cool stuff and its time to see things in action on our Windows 365 Cloud PC. Basically, once we have installed the App Volumes Agent in persistent mode, and rebooted we will see the device inside of AVM. Once AVM picks up the device as being online, it will mount your new application (with its friends packages and programs) instantly at login.

This is really a huge quality-of-life improvement on Windows 365 Cloud PCs that makes them an amazing user experience.

Final Thoughts

As you have seen, this new offering from VMware and Microsoft is a major improvement for application deployments in Windows 365. I truly believe the combination of Windows 365 and VMware Horizon with App Volumes rivals peanut butter and jelly as the best combination today. Making smart choices and integrating to elevate your platform was a common staple of one of VMware’s acquisitions (AirWatch) which we see today in Workspace ONE. These continued partnerships that Microsoft pursues make their platforms best-in-class and it is no wonder why Windows 365 is considered to be the top DaaS platform this year by Gartner.