Workaround for suppressing version updates in Remarkable Windows client software:

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 frequently interrupted by update popups and needing IT support to install updates, which disrupts workflow.

Analyzing the exact Issue

After doing some analyzing I found out that the Remarkable application's installer is created using the free Qt installer framework, and the installed program uses the WinSparkle software update library to manage its updates. WinSparkle checks for updates via a user registry key: HKCU\SOFTWARE\Remarkable\Winsparkle\CheckForUpdates=1 (reg_sz type).

Attempting to hit the “Skip this version” button doesn’t work, and changing the registry value from "1" to "0" to suppress updates is futile, as the application resets all values with each launch. Similarly, I tried removing write access to this registry key which leads to error messages about missing internet connections, which also isn't a viable workaround.

My solution: Create a PowerShell Script to autoclose the updater:

The correct approach is always contacting the vendor and convince them to fix their own software, so I contacted Remarkable's support, but they only responded with: 'As per consultation with our technical support specialists, any workaround to bypass the desktop app's update prompt is not feasible, as every time the app opens, it prompts for updates.'

In response, I developed a PowerShell script, "Remarkable Update Closer," which automatically dismisses the update dialog, thus maintaining user workflow without interruptions. I recommend compiling it as an .EXE file to remove all PowerShell windows.

Remarkable Update Closer

• Core Functionality: The script identifies and closes dialog windows with specific titles generated by the Remarkable application.
• API Usage: Uses Windows API (User32.dll) to handle and manipulate windows.

Script Variants

• Remarkable-Update-Closer.ps1: Latest version have some more CPU optimization, process-aware monitoring, logging for behavior tracking, and error handling.

Installation and Use

• Prerequisites: PowerShell must be installed, and for compiling to .exe, PS2EXE is recommended.

Compiling to .exe:

• Install PS2EXE with Install-Module -Name PS2EXE -Scope CurrentUser.
• Compile with Invoke-PS2EXE -InputFile "Remarkable-Update-Closer.ps1" -OutputFile "Remarkable-Update-Closer.exe".
• To run without showing a console window and add an icon, use: Invoke-PS2EXE .\Remarkable-Update-Closer.ps1 -NoConsole -IconFile "C:\Temp\Icon.ico"

Usage:

• The script can be launched at system startup via a scheduled task or integrated into an App-V or MSIX package. My version of the script also checks if remarkable.exe is running; if not, it terminates itself to avoid unnecessary CPU usage. Therefore, if using a scheduled task that runs continuously, you might need to modify the script to remove this check. A startup script is a script that runs automatically each time a user logs in or a system starts, designed to execute specific tasks or configurations. An alternative to scheduled tasks or App-V userscript is to use such a startup script. With an App-V startup process script, you ensure the script only runs when Remarkable is launched, conserving CPU resources. Without App-V, you can create a startup script that first starts Remarkable and then this script, then update the shortcut to point to this new script instead of remarkable.exe.
• Winget and Automatic Updates While Winget could theoretically manage updates automatically, we do not allow Winget traffic through our proxy, and we only trust repositories owned by the software manufacturer. This stance might change with upcoming adjustments by Microsoft to how Winget operates, especially concerning security in Virtual Desktop Infrastructures (VDI).

 

You can find the complete PowerShell script I've developed here: Remarkable Update Closer on GitHub.

For more on configuring WinSparkle's behavior, particularly regarding updates, please refer directly to the WinSparkle Registry Settings. By implementing this solution, you can ensure that update dialogs no longer disrupt your user’s workflow, allowing them to use Remarkable seamlessly in an enterprise environment. 

But beware there will always be a slight delay (1-3s on my test machine) from the update window shows until it closes because of scheduling to conserve CPU cycles and also PowerShell is not the most effective scripting language.

 

 

How we ended up making our own APP-V automation & workflow tool

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 SEV. Repackaging, testing and upgrading all your major applications into a new package format is for sure one of the most time-consuming workloads in larger IT organizations, so we didn't want to do that again anytime soon.

Coming from another advanced virtualization technology, the first thing I noticed was all that things it was different and missing compared to SEV, mostly in terms of functionality, compatibility and flexibility. SEV was behaving much more like a normal MSI install on computers, so we could capture all services, printer drivers and we could even patch up applications like Ms Office directly into the writable virtual layer using Windows update.
A lot of the things I think APP-V is missing compared to SEV is obvious a result of the overly strict isolation design and the restrictions it has that's blocking updates of executable file types through copy on write (COW), so I wanted to get some of that back from fully understanding the technology, and try to fix it during the process from Sequencing too deployment through scripting and/or workarounds.
Another issue for us was the very time-consuming and less than user-friendly implementation when adding many scripts on each Add/Publish/Remove /Unpublish event through Scriptrunner.

So I booked myself  and a colleague an advanced APP-V training class in the Netherlands early 2017 with the godfather of APP-V, Timothy Mangan.
I learned a lot but I also ended up with a lot of new questions I needed answers to after that training class.
First off all I wanted to integrate the installation of App-V packages better with Altiris, I tried reaching out through our Symantec contacts and even through forums, but nothing solid came back so I had to find my own answers.

What 3rd party tools are out there?

Looking at all the App-V tools I could find out there I built a list of pros and cons.

(Note, Tmedit was not available at first when we made our first tests and automations for detection rule scripts)

Ms Sequencer is not my first or even second choice as main APP-V editor, I think it's outdated and slow for that purpose. It's not giving me much more than being really good for capturing packages, after the first sequencing part you should close it up, and go on working using other tools. 

Ms Sequencer screenshot

 

That’s where AVE, Tmedit and Tweakappv comes in handy. They do all give you some extra functionality and possibilities the other programs lack.

Also, you can buy bigger and more expensive solutions like Flexera Admin Studio, RayPack Studio and Advanced Installer, but they are overly expensive and complex for repacking installs into APP-V format IMO.

AVE is not free but well worth the price tag since it will save you a lot of time on small edits, it has by far the nicest GUI and overview, and is the fastest overall editor. It’s really good for editing small stuff like shortcuts, extracting and importing files and folders, plus registry values and turning functions on and off.

But I really can't get used to the script part, and the automation part is not to good IMO, then you have to buy the not free Lib-V, but which is a fantastic product if you want to build your own tools, and Auto Sequencer fixups.

My favourite tool for quick edits and looking into packages.

 

AVE screenshot

 

Tmedit is also not free, but it has an amazing “Analysis & Fixes” toolkit, and it will help clean-up junk files and optimize stuff most of us don’t even know about. It will also give you a lot of good tooltip information about every App-V function, and the automation framework is really good. And Timothy Mangan update this tool very often, sometimes he even solves Sequencer bugs before Ms does.

My favourite tool for clean-ups and fixups.

But not my favourite file and registry editor, but it will do its stuff, also not very fast when opening and saving large App-V files compared to AVE.

 

Tmedit screenshot

 

Tweakappv Using this small and free command line tool from Advanced Installer we have finally found a working command line interface for modifying files and properties inside our App-V packages without using manual editing and without triggering the internal App-V CRC check.

This way we can automate the creation of scripts, we use it for Altiris detection rules with App-V packages, but Broadcom (formerly Symantec) has later updated CMS to support and can now detect App-V and App-X packages.
If you search the rest of my blog and google you will see a lot of examples of free tools and examples we have created with it, and things it can do for you.
The CLI interface can do most things directly, but some more advanced edits must be done through Xslt transforms, but if you do master this you have a winner :)

My favourite tool for automation.

Use case: We have used it in scripts that treat reading and extracting internal manifest files from App-V files with 7zip command line version).

When we have the AppxManifest file on our computer we create a script/program that read from the xml file.

Find things like "Identity Name",'Version="', 'appv:PackageId="' and 'appv:VersionId="'.

Using string split or an xml parser to get the values and store as variables in your script.
Then update them in our own tool and send them back through Tweakappv.

Tweakappv screenshot

Choosing delivery system:

Based on our own experience I wanted to have the possibility of a streaming solution for both users and machines since we’re using the same package format, but still avoid having to maintain another complex solution with databases if that could be avoided. Less things to maintain and patch. So full infrastructure was out of the question for us.

Today we can do both through the paid version of AppVentiX (formerly known as AppvScheduler), but we still install most our Global published programs through Altiris because we already automated all the scripts, commands and documentation needed for that scenario through our own tool, and we have a better possibilities too maintain pre. req. checks on our computers, and also inventory data.
We also created a little compiled PowerShell program that we use too deploy our App-V packages and CG's, it's checking the state of all active virtual processes on package publishing. It's giving our end users the option to save and close down active applications when needed. It's also giving us the option too auto close certain applications, and presenting it too end users with a friendly name in the message box from our own INI file.

We have now finished developing our own custom GUI version of Psappdeploy toolkit. Making use of all its functions will enable us to deploy pre. req. with App-V scripts during Add and Remove phase. But it will come with the cost of a larger start-up block making streaming slower.

On a pure Citrix/VDI solution AppVentiX is the “only” way to go IMO. Giving you lots and lots of tweaks for that scenario, and no need for any extra infrastructure.

Why we ended up creating our own tool?

Most of my readers would probably think that our journey was over by now, we had bought ourself several good 3rd party tools, and we could now : Change most package settings, and also sending scripts automatically into all our packages using Tweakappv.

The main reason was eliminating manual labour, that will both make you more efficient while avoiding human errors.

But to be honest, I am pretty lazy when it comes to doing routine jobs, and so are a lot of my co-workers. And that's actually a good thing if you have some spare time and programming skill set at your disposal, always try to automate as much as possible.

I tend to think I am pretty average when it comes to programming, but I think I have a pretty good eye for what could and should be automated due too years of experience, so when I see something is a good fit for automation I make up a small working script/program using google and my own ideas. Usually looking for CLIs and APIs to interact through.
During packaging that's often more than enough to make all the normal automations like I have explained here.

But if you are going to build bigger and better programs/scripts, you should be wise getting someone on-board having real programming skills.
Or you may use to much valuable time studying and doing trial and error before maybe getting the desired result.
I'm happy I have someone like that on my team, so for the last couple of years I have passed on my more complex request to him.

And that's how we ended up creating our own little tools: “HnAppvtool”.

At first it was supposed to be all about making automating scripting and documentation already having paid for AVE.
But we also wanted to change back GUID’s, versions and naming on the package so we didn't have to change previously command lines and scripts created with our own tool during testing.
But as time passed on we saw the potential for more automation.
Especial I wanted to see a log of all the major changes done from AVE and TMEDIT compared to the first package from the Sequencer tool.
So we integrated those programs into the tool, so all COM integration settings and file and registry changes would be written into our documentation file.
That comes in handy when you have to check up old packages without having to open them up.

Also, we would take new package revisions from other tools directly into the tools and finish all the job in there.
The end result we are working on today is made using pure PowerShell code and GUI. 

UPDATE (20.05.21): We still use this program for first time installations, but if the program is being Sequenced more than one time we try use the AutoSequencer.
My programmer has rewriten this program from scratch using C# and Lib-V.

Mostly because of speed, but also because he thinks the codebase was not that great, he has learned a lot since the first version.

Our tool:

Should have done a video showing how we use the tool. But I don’t really like hearing my own voice trying to speak “Norwenglish” (English with Norwegian accent), so you have to settle for just some screenshot.
There may also come a time when we can release our complete codebase on Git like we have done before with other tools and concepts, but we need some internal discussions with my bosses about that first….

Also, some of the text is in Norwegian so we need to translate it all.

Main window:

In this window you can load your APP-V file, or your complete project using the “Kilde” button. It's translated to source in English.

“Kilde” file will contain all the files and versions used from your first App-V file was imported.

Loading App-V file:

As you can see here, all information about GUIDS and advanced package settings is on the first page. Giving you easy control over that part.

Also, there is a console view, showing the complete log of our program.

How to update all isolation settings:

Just check the wanted settings and then hit the Compile button.

After a while it will be finished, and the new settings will be updated in the GUI.

This box shows us what has happened during the compile phase.

And the new settings will be updated in the GUI.

How to work with AVE and TMEDIT:

If we want to work with AVE and TMEDIT, the following save settings has to be configured within those tools.
It will be available as a tooltip if you hit the button marked with yellow on the screenshot.

Then you just have to press the TmEdit and AVE buttons. And those tools will start up. Do your stuff there, save package, and close the tool.

Our tool will then ask if you want to accept the changes from those tools into the current project.

Accept changes buttons

“Ja”, is the same as Yes, and” Nei“ is the same as No.

You can always go back too before those edits if you have ticked the box “Lagrer app-v før AVE o.l. sine blir lagret.

Meaning “Save app-v before AVE and other edits gets saved”

“TmEditAutooUpdate” button:

This button will let you set and read all tooltips related too what can be changed using that tool.

Machine Scripts:

Coming from SEV I missed having the possibility of creating several separate scripts per event, and how easy it was too change running behaviour by moving them up and down using arrows in the Composer.

So, we tried to mimic that behaviour as best as possible.

Adding script number 1 by pressing “New Script”.
The way we did it was making a simple but effective CMD script parser, so each subscript would be added into the main script. We are just using notepad as our paste editor. That is something we are going to change when we have the time. But for now, we make all our scripts in another editor and paste them over.

You can now see there is one script in the Machine Add main script.

Here we have added another script

Here we have moved our 2nd script up, and it will be auto renamed “0001_” in the first part of the name, but the last part of the name will show us the original script name.

Since it’s based purely on CMD (batch) it will let you run PowerShell scripts, Vbscripts and everything else as long as the command lines are correct.

Adding files into script directory:

Using the buttons “Add” and “Remove” you can also add and remove script files into your App-V script folder.
You can also see I have created test scripts on all 4 Script events.

Then we just hit the button “Lagre og Fortsett”. Same as Save and continue in English J

One Easter egg is that you can edit and put scripts directly into the working event folder for the project on the disk, and it will be added during compile!

 

Scripts folder

This is how our finished CMD script will look when deployed on your machine.

@echo off set hh=%time:~0,2% if "%time:~0,1%"==" " set hh=0%hh:~1,1% set dt=%date:/=.% %hh%%time:~2,6% if not exist "C:\company\Appv\Scriptlog\" (mkdir "C:\company\Appv\Scriptlog\") :Script_1 cd c:\temp Dir If not %ERRORLEVEL% == 0 ( Set ErrorKode=%ERRORLEVEL% set Scriptnr=1 Set Info=AVSLUTTER!!! Set Go=Ende Goto ErrorHandler ) rem --------------------------------- :Script_2 mkdir "C:\temp" If not %ERRORLEVEL% == 0 ( Set ErrorKode=%ERRORLEVEL% set Scriptnr=2 Set Info=AVSLUTTER!!! Set Go=Ende Goto ErrorHandler ) rem --------------------------------- :Script_3 Rem --- AltirisMachineAddPackage Roule --- reg add "hklm\software\wow6432node\company\Appv\test_123" /v AddPackage /t reg_sz /d 0.0.0.2/0759fa5e-74a1-4012-9f61-6babefff6cf3/4f1943d9-c43a-40b0-b411-cc0151c873f7 /f If not %ERRORLEVEL% == 0 ( Set ErrorKode=%ERRORLEVEL% set Scriptnr=3 Set Go=Ende Goto ErrorHandler ) rem --------------------------------- Goto ende :ErrorHandler Echo %dt% >>"C:\company\Appv\Scriptlog\test_123.log" Echo %Info% >>"C:\company\Appv\Scriptlog\test_123.log" Echo PakkeID:0759fa5e-74a1-4012-9f61-6babefff6cf3 Versjonsid:4f1943d9-c43a-40b0-b411-cc0151c873f7 Versjon:0.0.0.2 >>"C:\company\Appv\Scriptlog\test_123.log" Echo MachineAddPackage.cmd: Feiler i script nr %Scriptnr% Errorkode: %Errorkode% >>"C:\company\Appv\Scriptlog\test_123.log" Goto %Go% rem --------------------------------- :Ende

As you can see, most of the stuff is logging, Altiris scripts and error handling.

The reason it wasn’t made in PowerShell is simple, we had a lot of different PowerShell versions back when this was developed, and it was also faster developing and deploying this.

Userscripts:

Almost the same as MachineScript, but with the extra options you only need for userscripts.

One complains we hear about is that there will be blinking CMD windows when userscripts is running. So, we need to wrap them into and exe or vbs too supress them. That’s is one thing for a future revision.

Userscripts screenshot

Registry viewer:

I found a great free registry tool some time ago and wrote a blogpost about it. We have been modifying it a lot too suit our purpose.
It will now fully understand all special App-V related registry keys, and is also modified too run as a command line tool during compile so it can write all changes into or Description file.

If there is more than 40 lines of reg changes it will only show how many changes we have done, and put a reference to the complete changelog file for you to see all changes.
You can also fire it up in the GUI mode from the tool if you want to view them directly. But big registry trees will often take some time to create.

Registry viewer screenshot

There are also two different buttons giving us different GUI views for folders and files in the tool.
But after we integrated AVE and TMEDIT into the program we haven’t updated and perfected this.

But it makes it possible to add, view and delete files and folders directly from the tool.

Documentation:

One of the most important parts of our tool is too create our documentation after we are done with the package.

That way you don’t miss up logging small last-minute changes… (who hasn’t done that? )

Our program has 3 buttons for Documentation, called “Description for the complete doc” and “Pre.txt” for the steps you do before Sequencing.

And the last button “Sequence.txt” for what you do during Sequencing.

It’s just txt files so you fill out everything and it will be created like this.

Screenshot of our documentation file

And the last part containing file and registry settings and COM settings:

Also, some Altiris stuff and all deployment PowerShell command lines, not on the screenshot.

Another screenshot of our documentation file

End credit:

This tool was developed in between other tasks over a period of 2 years, and most of my small team have been active in bug testing and the development of new functions.
Would not have been possible if we did not work together as a team!

Hope this blogpost will inspire someone else to create your own tools when there are no perfect alternatives out there.

"HNMatchAppvConnectionGroups” tool on Github, change and match multiple APP-V package settings for use with a Connectiongroup the easy way!

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 read the included license files from thoose tools in the install folder after install.
Tweakappv files is included with the permission from Caphyon, the Advanced Installer company.

Hope this will help you, feel free to use it as you want, and please report any bugs!

DISCLAIMER: And as always, use it at your own risk!
For complete documentation on how to use, see the docx file included with the msi file in the program install directory.
This tool only modify the internal AppxManifest.xml file, not external files.
May not work correct with older App-V v 5.0 files, only tested with 5.1 or newer.

If you disable browser plugins, you will sadly not be able to activate them again with the tool, we didn't get that XML transform to work.
But they are only commented out in the Appxmanifest.xml file, so you can use Ace editor on the manifestfile again, and then import it back to the package using AVE or MS sequencer after you removed the comment, and it will be enabled again after you save the package again.

How to compare changes in two REGISTRY.DAT files the easy way:

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 published for free called “Registry Comparator (GUI)”. It can be downloaded from that site once you registered an account there.

We are going to modify the source code so it will just pipe out the changes directly to our documentation log file with a commandline J

 

Here is his own words:

Introduction

In order to see how some software manipulate the Windows Registry, I needed a tool that could take two hive files, load them, and then compare them to show the differences between the two. I did find some code on the net that would compare files but not two registry hives in a nice graphical way. So I thought of coding one myself in C#. (Registry Hives are binary files, I don't mean here the .reg text based files made by regedit.exe.)

 

Background

Windows stores the Registry in binary files. The format of this Registry hive is not publicly available. The way data is stored in the Registry is simple. It begins with a Registry header of size 4096 bytes. It then starts off with Logical Data blocks - aka Cells. Based on the type of Logical Data blocks, it will have a list of pointers (called offsets = file offset from 4096th byte). These pointers point to another logical cell which has more information or data in them. Broadly speaking, there are two types of cells:

 

·         Node Key Cell

·         Value Key Cell

Node keys - as the name suggests - are nodes of a tree. It's like the directory in the Windows file system. A directory can have in it more directories and files. This node cell has four important pieces of information.

 

·         Number of Subkeys in this Node (or Key)

·         Pointer to a Cell that stores the address of these Subkeys.

·         Number of Value Key Cells in this node.

·         Pointer to a Cell that stores addresses of Value Keys.

A value key cell stores data. Value keys behave like files which have different types of formats and information. Values keys are broadly categorized into having text based information or binary information.

 

HIVE starts off with the ROOT node at (4096+32) address. Information is read by reading this first Node Key type cell. The subkey node information provides us link to the sub keys present in this node. We have to iterate through all the nodes to read the entire Registry hive. We also read the Value Keys as we iterate deeper into levels.

I have got some very good information (and coding help too) from these articles:

 

http://www.codeproject.com/Articles/24415/How-to-read-dump-compare-registry-hives

http://www.sentinelchicken.com/data/TheWindowsNTRegistryFileFormat.pdf

We then read these node information into a WinForms TreeNode and then plot them in a TreeView.

 

Once we have two hives loaded in two separate TreeViews, we then compare them using a simple iteration method. We assign color to TreeNodes based on the search status: Green is an unchanged reg key type, red is a key that was deleted (or not present) in the second file, blue is a key that was added into the second file (not present in the first), and pink means a Value Key that was changed in its data.

 

Hope this information will help you as much as it did for us.