Application Deployment & Virtualization

In connection with another blog post I’m writing in a series about App Volumes Direct Mode, I wanted to find out exactly how the MSI we create during capture works and what it contains. In this post I have chosen to use a couple of App Volumes MSI-wrapped packages I made myself using their capture tool. After capture, you get a wrapped MSI that contains the App Volumes package (VHD + JSON), either embedded directly or stored inside an internal CAB stream. This also explains why you encounter a CAB file when the package exceeds 2GB. To get the most out of what I'm writing, you should have some familiarity with how MSI files work. In short, an MSI is a database with tables and logic that specifies where and how things should end up on the system. Custom Actions are the logic that performs custom operations within an MSI. This may not be rocket science, but I believe you need the right tools and a decent understanding of MSI to follow the flow. This was previously a gap in my ...

Update March 2026: A better solution is now available. The WinSparkle updater can be disabled entirely by replacing WinSparkle.dll with a stub DLL — no scripts, no delays, no update dialogs. The legacy script described in this post is kept for reference only. See the new post: Disabling Auto-Updates in the reMarkable Companion App: WinSparkle DLL Stub Method When deploying the Remarkable desktop application within a Windows enterprise environment, it introduces challenges due to its update mechanism. The application automatically checks for new updates every time it starts from the internet using WinSparkle .dll, which we would like to control but cannot. The first launch gives us this screen if there is a newer version available. But “Skip this version” doesn’t work. Instead this process automatically downloads an .exe setup update file that attempts to execute, requiring administrative privileges typically unavailable to standard enterprise users. This results in users being freque...

After Sequencing of both version 28 and 29 of IBM Spss we found that we would get the following error when launching the program the second time: To fix this problem just create a small powershellscript that check if that folder is present, and if so delete the content. It will be recreated during the next launch. Run the script on UserStartProcess and UserExitProcess to make sure it will keep working in all scenarios. -------------------------- Powershellscript ---------------------- $Package = Get-AppvClientPackage -Name "IBM SPSS" -All $PackageID = $Package.PackageId.Guid $GetAppdataLocal = Get-Item env:localappdata $LocalAppdata = $GetAppdataLocal.Value $Path="$LocalAppdata\Microsoft\AppV\Client\VFS\$PackageID\ProgramFilesX64\IBM\SPSS Statistics" if( Test-Path "$Path\*"){     Remove-Item "$LocalAppdata\Microsoft\AppV\Client\VFS\$PackageID\ProgramFilesX64\IBM\SPSS Statistics" -Recurse...

Recently I did a big detective job in the organization I work for. I We wanted to find all the applications used today that utilize the old .NET Clickonce   deployment technology from Microsoft. For those who don’t know, Clickonce is a Windows-based appinstaller format that can be installed and run with minimal user interaction. See more information about them here . Locating all the ClickOnce applications is a pain since they are installed into a user profile when the app is started. So first I had to search through all our computers looking for content under the following folder structure: % localappdata %\Apps\2.0\<random folder>\<random app id>.   <random folder> is constructed from the first 11 characters from the following user registry key: HKCU\Software\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0\ComponentStore_RandomString   More details about ClickOnce: ClickOnce can be delivered ...