Showing App Volumes Application Attach Progress to Users with PowerShell

Omnissa App Volumes is a great solution for separating applications from the base Windows image. Instead of installing every application directly into a golden image, applications can be packaged separately and dynamically attached to a virtual desktop when required.

This approach is especially useful in non-persistent Omnissa Horizon environments, where keeping the Windows image as clean and generic as possible simplifies image maintenance considerably. App Volumes packages can be assigned to users or groups and attached to the virtual desktop as part of the user logon process.

There is, however, one small user-experience problem.

After the Windows desktop appears, App Volumes might still be busy attaching applications.

From an administrator perspective this is completely normal. From an end-user perspective it can be confusing.

The Start menu is already available, Explorer is running, and the desktop looks ready for use. However, some applications might still be missing because their App Volumes packages have not finished attaching yet if the on-demand option is not used.

In this blog post, I will show how I used a PowerShell script to monitor the App Volumes attachment process directly from the Windows registry and display a small graphical progress window to the user.

The solution runs completely in user context, does not require administrative privileges, and does not depend on access to the App Volumes Agent log files.

The Use Case

The environment where I implemented this solution consists of Windows 11 non-persistent Omnissa Horizon virtual desktops with Omnissa App Volumes 2512.

Applications are dynamically provided through App Volumes instead of being installed directly in the Windows image.

During logon, Windows itself can become usable before App Volumes has completed processing all application packages.

This can result in a situation like this:

This means that simply detecting an attached VMDK or checking Get-Disk is not necessarily a good indication that the application is ready for the user.

What I wanted instead was something like this:

The window automatically disappears after two seconds.

Using AppTracker to Determine the App Volumes Status

The main challenge was finding a reliable way to determine when App Volumes had actually finished attaching the applications.

Reading the App Volumes Agent log was not an ideal solution because the progress window must run completely in the logged-on user’s context. I also did not want to change permissions on App Volumes log files just to provide a progress indicator.

While investigating App Volumes 2512, I found a much more useful registry location:

HKLM\SOFTWARE\Omnissa\AppVolumes\AppTracker

App Volumes creates subkeys underneath AppTracker for the applications it is processing.

For example:

Each entry contains a Status value.

Monitoring these values during logon showed that the applications initially appeared with:

Status = 1

and changed individually to:

Status = 3

as App Volumes completed processing them.

Eventually every AppTracker entry had:

Status = 3

In one of my tests, 16 App Volumes entries were processed and the complete sequence took approximately 22 seconds.

This immediately gave me the information required for a progress indicator:

The percentage can then simply be calculated using:

So when 11 of 16 applications are ready, the graphical window can display:

11 of 16 ready 69%

Important: I have not found public Omnissa documentation that defines the numeric AppTracker\Status values. Status = 3 representing the completed state is therefore based on testing and observation with App Volumes 2512. I recommend validating this behavior again after upgrading the App Volumes Agent.

The Complete Script

Putting these pieces together results in the following PowerShell script:

Running It During User Logon

For this use case, the script should be started as part of the interactive user logon process.

In an Omnissa Horizon environment, Dynamic Environment Manager is an obvious place to launch it, but a user logon script or scheduled task can also be used.

I recommend starting PowerShell with the console hidden:

powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "AppVolumesProgress.ps1"

The script itself does not require elevation. It only reads the AppTracker information from HKLM and displays the Windows Forms interface in the user’s session.

Conclusion

In a non-persistent Horizon desktop, Windows being ready does not necessarily mean that all dynamically delivered applications are ready.

That distinction can be confusing to users. The Start menu is available and the desktop looks usable, but App Volumes can still be attaching applications in the background.

By monitoring:

HKLM\SOFTWARE\Omnissa\AppVolumes\AppTracker

the PowerShell script can provide useful feedback about what is actually happening instead of displaying an arbitrary timer.

The result is a lightweight solution that:

• runs completely in user context;
• requires no administrative privileges;
• does not require access to the App Volumes Agent logs;
• shows actual attachment progress;
• supports different application assignments per user;
• and automatically disappears when the applications are ready.

One final consideration is that AppTracker and the meaning of Status = 3 should be regarded as implementation details observed with App Volumes 2512 and the script tested in a Horizon VDI (single user) desktop, rather than a documented automation interface. I therefore recommend validating the behavior again after future App Volumes Agent upgrades.

For this particular use case, however, it provides exactly the information needed to make the final part of a non-persistent VDI logon much more transparent to the user.

It would be even better and very useful to have visible feedback during the attachment process available to the user as a native built-in option in the App Volumes agent. But who knows what the future brings 😉.