App Attach: Dynamic Application Delivery
App attach separates applications from the OS image by packaging them in VHD(X) or CIM disk images that mount at user sign-in. This keeps golden images clean, simplifies updates, and enables per-user app assignment without reinstalling anything.
What problem does app attach solve?
Think of app attach as plug-and-play app cartridges for your desktop.
Normally, apps are “baked into” the Windows image — like painting a wall. If you want to change a painting, you have to repaint the whole wall (rebuild the image). App attach is like hanging pictures with hooks instead. Each app is a separate picture (a disk image). When a user arrives, the pictures they need are hung on the wall. When they leave, the pictures come down. You can swap, add, or update pictures without touching the wall.
This means faster image updates, cleaner images, and different users see different apps.
App attach vs “MSIX app attach”
You might see both terms — here is the distinction:
| Term | What It Means |
|---|---|
| MSIX app attach | The original feature — supported MSIX and MSIX Bundle formats only |
| App attach | The newer, broader feature — supports MSIX, MSIX Bundle, CIM, and Appx formats |
App attach is the evolution of MSIX app attach. For the exam, app attach is the current term. It supports more package formats and has a simplified management experience in the Azure portal.
How app attach works
The lifecycle — four stages
| Stage | What Happens | When |
|---|---|---|
| Stage | The app package (VHD/CIM) is mounted to the session host. Files are made available to the OS. | Before user signs in (or at boot) |
| Register | The app is registered for the specific user — it appears in their Start menu and file associations | At user sign-in |
| Deregister | The app registration is removed for the user — no longer visible | At user sign-off |
| Destage | The app package is unmounted from the session host | When no users need the app (or at shutdown) |
This lifecycle means apps appear and disappear per user without ever being traditionally “installed” or “uninstalled.”
🏢 Raj’s Citrix migration: “At TerraStack, we used Citrix App Layering for years. App attach is Microsoft’s answer to the same problem — separate apps from the OS image. The migration was smoother than I expected. Our 15 LOB apps went from baked-in-image to app attach packages in two weeks. Image rebuild time dropped from 4 hours to 45 minutes because the image now only has Windows, FSLogix, and the AVD agent.”
The mounting process visualised
Azure Files Share
├── finance-app-v2.1.cim (Finance app package)
├── hr-app-v1.5.vhdx (HR app package)
└── cad-viewer-v3.0.cim (CAD viewer package)
↓ mount at sign-in
Session Host VM
├── Windows 11 (clean image)
├── FSLogix agent
├── AVD agent
└── [Mounted apps appear as locally installed]
├── Finance App (for Finance group users)
└── CAD Viewer (for Engineering group users)Package formats
MSIX
MSIX is Microsoft’s modern application packaging format:
- Containerised installation — apps run in an isolated container
- Clean install/uninstall — no registry pollution, no leftover files
- Created using the MSIX Packaging Tool (converts Win32 apps to MSIX)
- Code signing required — packages must be signed with a trusted certificate
CIM (Composite Image Filesystem)
CIM is the newer, recommended format for app attach:
| Feature | MSIX in VHD(X) | CIM |
|---|---|---|
| Mount performance | Good | Better — faster mount times |
| Storage efficiency | Standard VHDX overhead | More efficient — no VHD overhead |
| Supported in app attach | Yes | Yes (recommended) |
| Creation | MSIX Packaging Tool + expansion to VHD | msixmgr.exe tool |
| File system | NTFS inside VHD(X) | Native CIM format |
Microsoft recommends CIM over VHD(X) for app attach packages due to better performance and storage efficiency.
Creating app attach packages
Step 1: Package the application as MSIX
Use the MSIX Packaging Tool (free from Microsoft Store):
- Install the MSIX Packaging Tool on a clean VM
- Run the tool and select “Application package”
- Install your Win32 application through the tool — it captures all changes
- The tool creates an MSIX package with all files, registry entries, and dependencies
Step 2: Convert to CIM or expand to VHD(X)
Use the msixmgr.exe command-line tool:
- To create a CIM image:
msixmgr.exe -Unpack -packagePath app.msix -destination \\share\app.cim -applyACLs -create -fileType cim - To create a VHD(X) image:
msixmgr.exe -Unpack -packagePath app.msix -destination \\share\app.vhdx -applyACLs -create -fileType vhdx
Step 3: Store on a file share
Upload the CIM or VHD(X) file to an Azure Files share or Azure NetApp Files volume accessible by session hosts.
Step 4: Add to AVD in the Azure portal
- Navigate to the host pool
- Go to App attach and select Add
- Browse to the package on the file share
- Configure the application name, display name, and icon
- Assign the package to one or more application groups
Exam tip: CIM vs VHD(X) for app attach
If the exam asks which format is recommended for app attach packages, the answer is CIM. It has faster mount times, better storage efficiency, and is the Microsoft-recommended format for new deployments.
VHD(X) is still supported and works fine, but CIM is the preferred choice. Expect questions that test whether you know CIM exists and is recommended over VHD(X).
Storage for app attach packages
App attach packages must be stored on a file share accessible by all session hosts:
| Storage Option | Pros | Cons |
|---|---|---|
| Azure Files (Premium) | Easy setup, integrated with Azure AD | Cost per GB higher |
| Azure Files (Standard) | Lower cost | Higher latency, not recommended for large packages |
| Azure NetApp Files | Best performance, lowest latency | Higher minimum cost, more complex setup |
NTFS permissions on the file share:
- Session hosts need Read access to the package files
- Only admins need Write access (for uploading new packages)
- Users do NOT need direct share access — session hosts mount the packages
Benefits of app attach
| Benefit | How |
|---|---|
| Smaller images | Core OS only — apps are separate |
| Faster image updates | Update Windows without touching apps |
| Independent app updates | Replace an app package without rebuilding the image |
| Per-user app assignment | Different users get different apps from the same host pool |
| Faster deployment | New apps are added by uploading a package, not rebuilding infrastructure |
| Reduced storage | One package serves all session hosts (not duplicated per VM) |
Limitations — what app attach cannot do
Not every application is a good candidate:
| Limitation | Why |
|---|---|
| Kernel-mode drivers | Apps that install drivers cannot be packaged (e.g., antivirus, VPN clients) |
| Windows services running as SYSTEM | Services that must start at boot before user sign-in are not compatible |
| COM+ and DCOM registrations | Some legacy COM components do not work in MSIX containers |
| Heavy registry modifications | Apps that modify system-wide registry beyond HKCU may fail |
| Boot-time dependencies | Apps required before any user signs in (e.g., agents, security tools) |
These apps should be installed in the golden image instead.
| Aspect | Install in Image | App Attach | RemoteApp |
|---|---|---|---|
| Where app runs | On session host (in desktop session) | On session host (appears locally installed) | On session host (appears as window on client) |
| Where app is stored | In the OS image (baked in) | On file share as VHD/CIM (mounted at sign-in) | In the OS image (published individually) |
| Image maintenance | Rebuild image to update apps | No image change — replace package on share | Rebuild image to update apps |
| Per-user assignment | No — all users get all apps | Yes — assign packages to app groups | Yes — assign users to RemoteApp groups |
| Update speed | Slow — image rebuild + redeployment | Fast — swap package on file share | Slow — image rebuild + redeployment |
| App isolation | No — installed in OS | Yes — MSIX container isolation | No — installed in OS, published individually |
| User experience | App in Start menu inside desktop | App in Start menu inside desktop | App appears as local window on client device |
| Best for | Core apps (OS agents, drivers, always-needed) | Department-specific, frequently updated apps | Legacy LOB apps for non-desktop users |
🎧 Mia’s app delivery strategy: “We use all three methods. Windows, FSLogix, Teams, and the EHR system are in the image — every clinician needs them. PACS viewer and speciality clinical tools use app attach — only specific departments need them and they update monthly. The patient satisfaction survey is a RemoteApp for admin staff who only need that one app on their tablets.”
Raj wants to add a new Finance application to TerraStack's AVD environment without rebuilding the golden image. The app is a standard Win32 desktop application. What is the correct approach?
Mia needs to deliver a PACS viewer application that updates monthly. She wants the fastest update process with minimal disruption. What format should she use for app attach?
An application requires a kernel-mode driver for USB token authentication. Can it be delivered via app attach?
🎬 Video coming soon
App Attach: Dynamic Application Delivery
Next up: Monitoring with Azure Monitor — moving into Domain 4, learn how to monitor AVD health, performance, and user experience with Azure Monitor and AVD Insights.