Before you begin
- The Enterprise plan. On lower plans the App Attach page shows an Upgrade required notice instead of the registry.
- The administrator role to register, remove or assign packages
- To upload package files: the locked-down App Attach storage account for your tenant (see Set up upload storage below)
When to use App Attach
App Attach works alongside the Winget packages and Application Catalog apps that Atlas installs when it builds a session host. Keep apps everyone needs, and anything that installs drivers, services or shell extensions, on the Winget path. Use App Attach for line-of-business apps that are not in a public catalog, apps that change often, and apps that only some departments on a shared pooled host should get.
Open the App Attach registry
The registry page is titled MSIX App Attach. It has no entry in the sidebar, so open it in one of these two ways:
- Global search: search for App Attach and open the result. The result is shown to administrators.
- From a host pool: open the host pool, go to Settings, choose the Apps & Automation category, and in the MSIX App Attach panel click the App Attach registry link.
If you manage several tenants, use the link in the host pool's panel. It opens the registry for the tenant that owns that pool.
Register a package by uploading a file
- In Register a package, choose Upload a file.
- Choose the package file. Accepted types are .msix, .appx, .cim, .vhd and .vhdx, and the image type is detected from the file extension. The largest file you can upload is 1 GB.
- Enter a Display name, such as Contoso ERP.
- Enter the Resource group and Location (for example eastus) where Atlas should create the package in Azure.
- Click Upload & register.
CIM is the format Microsoft recommends for App Attach. VHD and VHDX are supported for packages you already have. A traditional .msi installer is not an App Attach package; deploy it through Winget or a script instead.
Register a package by URL
If the package image is already on storage your session hosts can read, register it by its address instead of uploading it.
- In Register a package, choose Reference a URL.
- Enter a Display name and the Image URL, for example https://contoso.blob.core.windows.net/packages/app.cim.
- Enter the Resource group and Location.
- Pick the image type: CIM, VHD or VHDX.
- Click Register.
The URL must start with https://. File-share (UNC) paths such as \\server\share\app.cim are not accepted. If the package only lives on a file share, upload the file instead. Each image path can be registered once per tenant.
Set up upload storage
Uploaded packages often contain licensed software, so Atlas only stores them as private blobs in a locked-down storage account in your own Azure subscription. Atlas writes to it with its own identity and Azure role-based access, never with an account key, and your session hosts read from it the same way. Until an account is set up for your tenant, an upload fails with the code STORAGE_NOT_CONFIGURED. Registering a package by URL works without one.
- Deployed from your setup link: Atlas created the storage account during deployment (its name starts with atlasaa) and connected it, so uploads work with no extra step.
- Installed with the Cloud Shell installer, or a second tenant managed from the same Atlas deployment: no account is set up for that tenant yet. Contact Atlas AVD support, and we will help you create a locked-down account and connect it to the tenant.
- For full network isolation, the account can have public network access turned off and be reached only through a private endpoint in your session hosts' virtual network.
- Your session hosts need read access to the account (the Storage Blob Data Reader role). Granting it to an Entra group that holds the hosts' managed identities lets you add and remove hosts without changing the role assignment.
Review the registry
Once at least one package is registered, the page shows summary tiles above the list: Total packages, Active, In progress, Failed and Inactive. Click a tile to filter the list to that state, and click Total packages to show everything again.
- Active: the package is published in Azure and ready to assign.
- In progress: the package is pending (registered in Atlas but not yet in Azure, for example because the tenant has no host pool yet) or a new version is being swapped in.
- Failed: Azure could not create or update the package. Check that the resource group and location exist and that the image is reachable, then remove the package and register it again.
- Inactive: the package is kept in the registry but turned off.
The Registered packages table shows each package's name, image path, type, version and state. Use the search box to find a package by name, path, type, version or state, and sort by any column.
Assign a package to a host pool
Registering a package does not deliver it to anyone. Assign it from the host pool that should get it.
- Open the host pool, go to Settings, and choose the Apps & Automation category.
- In the MSIX App Attach panel, under Assign a package, choose the Package.
- Under Who gets it, choose Specific Entra groups and pick one or more groups (search by name, or paste a group's object ID), or choose Everyone who signs in to this pool.
- Click Assign. Users get the app the next time they sign in to a session host in the pool.
Assigned to this pool lists the pool's current assignments. Click the bin icon next to one to remove it. If you pick several groups and one of them already has the package, Atlas reports that group and still assigns the others. Atlas gives the pool and the groups access to the package in Azure. In a RemoteApp host pool, it does not yet add the package's apps to the pool's application group, so publish them there in the Azure portal.
Remove a package
In the Registered packages table, click the bin icon in the package's row and confirm. Removing a package also removes its assignments and deletes the package from Azure, so every host pool that used it loses the app at the next sign-in. You cannot undo this. An uploaded file is deleted from the storage account too.
If an app does not appear in a session
- Check that the package is assigned to the host pool, and that the user is in one of the assigned groups.
- Check that the session hosts can read the image: for uploads, the hosts need read access to the storage account; for a URL, the address must be reachable from the hosts' network.
- A package whose signing certificate has expired stops attaching unless it was signed with a trusted timestamp. Timestamp your packages when you sign them; if one was not timestamped, re-sign it and register the new image before the certificate runs out.
- To update an app, register the new version's image, assign it, and then remove the old version's assignment, rather than changing the old image in place. Users get the new version at their next sign-in.