Tag: DEM

The Puzzle Behind a Two Minute Delay
A few weeks after upgrading App Volumes, an upgrade that hadn’t gone entirely smoothly, we started receiving reports from end users. They noticed that certain applications were suddenly taking much longer to launch. It quickly became clear that the issue was specifically related to App Volumes On Demand applications. What normally opened within seconds now took more than two minutes. The applications did eventually start, but the delay was unacceptable.

At first, the svservice.log didn’t reveal anything unusual, aside from a few CPU‑related messages. The applications still launched, so nothing pointed directly to the root cause. Even older versions of the master image, including those with the previous agent, showed the same behavior. Disabling the DEM layer didn’t help, nor did excluding GPOs.

Next, I turned my attention to the App Volumes Managers, but again, nothing suspicious appeared in the logs.

To rule out other possibilities, I tested the same packages on our PackageVM, the machine we use to build and validate App Volumes packages. Interestingly, I couldn’t reproduce the issue there. With the same configuration and software stack as our VDI environment, everything worked flawlessly. It became clear that the App Volumes Manager or upgrade wasn’t part of the problem.

So I went back to the svservice.log and examined it line by line. That’s when a specific entry caught my attention, one that pointed toward the Print Spooler.

Restarting the Print Spooler service took just over two minutes, exactly matching the delay users were experiencing. That was the breakthrough. As a test, I applied the App Volumes registry key that prevents the Print Spooler from restarting when loading packages. Immediately, application launches returned to normal speeds.
```
HKLM\SYSTEM\CurrentControlSet\Services\svservice\Parameters\
DisableSpoolerRestart 
Type: REG_DWORD 
Value: 1
```
Of course, leaving that registry key in place wasn’t a long term solution. We needed to understand why the Print Spooler was causing delays. Special thanks to Gunther Leeman for digging deeper. He discovered that a print driver monitor was responsible for the slowdown. Removing the related registry keys instantly resolved the issue. Further investigation showed that this component wasn’t required for printing functionality at all, so we want to removed it from the master image.

That was the moment the last piece of the puzzle fell into place!
We discovered that the problematic print driver wasn’t actually part of the master image. It was being installed on specific workstations during startup through a targeted action. That explained why the issue didn’t appear on the PackageVM, yet still occurred on earlier master images.

We’ve now resolved the problem by including the print driver directly in the master image, but without the unnecessary print driver monitor.

This issue was a reminder that even the smallest, most unexpected component can cause major disruptions. Sometimes it’s not the big changes or complex systems that trip you up, but a tiny detail hiding in plain sight.
08/04/2026
Behind the Scenes of an App Launch
In our daily practice with Omnissa AppVolumes and DEM, you sometimes run into unexpected challenges. This week I encountered one myself with an application that relies on shortcuts containing specific parameters.

Since the application only needs to be available to a relatively small group of employees, we decided to deliver it through an AppVolumes On Demand package. The shortcut itself was created in DEM, pointing to svservice.exe with the required app run parameters. Time to test…

The Problem

When launching the shortcut, the familiar AppVolumes notifications appeared, but then nothing happened: the application simply didn’t start. After checking, the AppVolumes package was indeed attached. So the next step was to look at the logs.
In “C:\Program Files\Omnissa\AppVolumes\Agent\Logs\svservice.log” everything initially looked fine, the shortcut was reported as successfully started.

On closer inspection, however, it turned out that not all parameters were passed along. And that was the crux: the application wasn’t receiving the full command line it needed to run.

The complete command ended up being 282 characters long, exceeding the standard Windows limit. It was the combination of the AppVolumes On Demand option with the lengthy parameters that pushed it past this boundary, making a traditional shortcut insufficient.

Workaround

I am aware that there are other options available, such as modifying the MAX_PATH registry settings to allow longer arguments.
```
[HKLM\Machine\System\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001 
```
However, in this situation we deliberately chose not to go down that path.

To work around this, I created a PowerShell script from which the application is launched.
```
# Path to svservice.exe and arguments
$svServicePath = "C:\Program Files\Omnissa\AppVolumes\Agent\svservice.exe"
$appArguments  = 'app run <AppVolumes Package GUID> "<Application.exe>" <Parameters>'

# Launch svservice.exe and wait until it completes
Start-Process -FilePath $svServicePath -ArgumentList $appArguments -NoNewWindow -Wait
```
And created a DEM shortcut that directly points to the PowerShell script.

Functionally this worked well, but there was one drawback: when executing the script, a PowerShell console window briefly appeared. Even though it was only visible for a moment, I didn’t consider this desirable for the end user.

From Script to .exe with PS2EXE

That’s when I took it a step further. With PS2EXE, you can convert a PowerShell script into an executable file (.exe), see the PS2EXE project on GitHub for more information: https://github.com/MScholtes/PS2EXE. The advantage is that the script is “packaged” as a program, so no PowerShell window appears when it runs. For the end user, it feels just like starting a regular application.

The script itself was fairly simple:
```
Invoke-PS2EXE -InputFile "<Path to Script.ps1>" -OutputFile "<Path to Exe.exe>" -NoConsole -NoOutput
```
By converting this script into an .exe with ps2exe, I can call it directly from DEM without the PowerShell window flashing up. The result: the application starts as intended, the parameters are correctly applied, and the end user notices no difference.

Conclusion

It may not be the most elegant solution, but it’s a pragmatic approach that removes friction for the end user. Sometimes these kinds of workarounds are exactly what’s needed to keep the environment stable and user-friendly. And it highlights how useful tools like ps2exe can be for eliminating small annoyances and improving the overall experience.
20/11/2025
The shortcut that broke the flow
At one of our hospital clients, we deployed a new digital workspace built on Omnissa products like Horizon, App Volumes, and DEM. Ivanti Automation Manager was already in use. The EHR system receives multiple updates each month, including hotfixes. Previously, every update required a new image, a time-consuming and error-prone process.

With App Volumes as our Application Layering solution, we gained flexibility. And we went a step further: we fully automated the packaging process.

What we automated

Using PowerShell scripts and an Ivanti Automation Runbook, we automated:
- Creation of Ivanti Automation resources and modules
- Creation of App Volumes Applications and Packages
- Booting the Package VM
- Installing the application into the App Volumes package
- Reverting the Package VM to snapshot
- Marking the package as ‘Current’
- Assigning the package to users
The only manual steps left are entering the HF number and providing the necessary credentials to execute tasks and link them to logging. Everything else runs automatically.

Smart versioning with DEM integration

To stay flexible, we place each application in a folder named after its version. This allows multiple versions to coexist across Test, Acceptance, and Production environments. The correct version is launched via a DEM shortcut using a variable:
```
C:\Program Files (x86)\Chipsoft\Hix\%HiXPrd%\Chipsoft.hix.exe
C:\Program Files (x86)\Chipsoft\Hix\%HiXAcc%\Chipsoft.hix.exe
C:\Program Files (x86)\Chipsoft\Hix\%HiXTst%\Chipsoft.hix.exe
```
In DEM, it’s easy to see which environment runs which version. Updating the variable is the only manual step, intentionally kept that way.

And then it broke…

Everything worked as expected. Until after an update, the service desk started receiving calls: the shortcut no longer worked.

Turns out some users had dragged the shortcut from the desktop to the taskbar. DEM translates variables into static paths. Once copied, the shortcut becomes fixed to a specific version. After an update, that path is no longer valid resulting in errors, frustration, and no access to the EHR.

The fix: Files and Folders

We solved this by no longer using DEM shortcuts. Instead, we use a Files and Folders action to place a file with the correct reference on the desktop and in the start menu. This preserves the variable and ensures the shortcut keeps working after updates.

Conclusion

Technical automation is incredibly valuable. It saves time and boosts reliability. But in the end, it’s all about the end-user experience. For them, it just has to work. That’s where the real value lies.

I’m curious to hear if others have found a more elegant solution to this. Have you tackled similar shortcut issues in a smarter way? I’d love to learn from your approach.
30/10/2025