Application Deployment & Virtualization

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...

Backstory: (If you don’t want to read all my mad ramblings, then go directly to the part “Our tool” = ) During our previous Windows Xp to Windows 7 migration (2013-2014) we upgraded approximately 13000 computers, then as now we were using Broadcom (formerly Symantec) CMS(Altiris) for deployment, and ended up repackaging over 400 different virtual packages with Symantec SEV (Symantec Endpoint Virtualization). That format was great for compatibility, and for the most parts it worked pretty well once you knew it's bugs and quirks, but we had to throw it away after Symantec made us aware in early 2017 they would EOL it from the summer of 2018. After a lot of research and testing, we decided that our Windows 7 to Windows 10 migration would be all about APP-V. That way we could also reuse most of our new App-V packages on our current Citrix environment, and in future VDI solutions. We were concluding it is the only virtualization tool big enough not going EOL on short notice like ...

Most of us that work with App-V will eventually need to put some of them inside a Connectiongroup (CG). That’s a pretty straightforward operation, until you deploy it for test, and it fails to install, giving you errors like: “The connection group {xxx} version {xxx} could not be published because the virtual COM settings of the individual packages conflict. Verify that the virtual COM settings are the same for all member packages and try again. Finally I had the time to put up our free tool from my previous article up on  github. Our powershell procjectfiles may not contain the latest changes, and some errors since my translation to English was done in a hurry using replace with in notepad++. But you will most likely get the drift, and the compiled working program is included in the msi . This tool is free, and based around the excellent work of the Tweakappv tool by Caphyon and 7 zip to extract files form the appv files. They are included in the msi file. So please r...

When we change registry information in an existing APPV package we usually do so manually in the Sequencer, Ave or TMEdit then save the new version. Afterwards we try to document that changed registry information and often forget some crucial information, making resequencing of the application later on harder than it should be. During the development of an internal APPV workflow application we have created around Tweakappv , TMEdit and AVE, we also wanted to document what has been done in each applications REGISTRY.DAT after the APPV file is saved in a new version automatically. The new and the old Registry.DAT file could be extracted automatically by 7zip command line version with this command: 7-Zip> 7z.exe x " filaname.appv " "registry.dat" –y (just ignore archive errors, the registryfile will work non the less=) But understanding the DAT files is not very easy. By coincidence I found a tool a clever guy have made in C# and pub...