How to build a Syncthing MSI package for distribution #syncthing-msi

Exactly that work not for me. I dont know why, the difference is, that I use after the installation my old dataset from the “normal” installation, it means done without MSI.

I guess your “non msi driven old config” has updates disabled or the web ui just displays updates as disabled because the firewall blocks outgoing requests to “”.

After you import your old settings you have those settings in place - no matter what the MSI got as properties. The MSI fires a one-shot batch script which updates the config and the script will not run again when you for example stop the service, copy over your old config and start the service. Just one thing: If the MSI script set STNOUPGRADE env, it will block upgrades because it’s still there - no matter what you have in your old config.xml .

I’d advice you do this:

  • Uninstall MSI
  • Delete all files in c:/server/syncthing/appdata to start over from scratch (I expect you have backuped your files already!)
  • Copy your “old” config to …/appdata
  • Edit the MSI to say “STNOUPGRADE”=0
  • Install MSI.

It should modify your config to enable auto upgrades (Windows env vars, config.xml).

off topic: I think it a little bit misleading if Syncthing is configured to allow upgrades and it displays “upgrades disabled by admin/packager” when the update url returns http 403. noticed this in my tests a while ago. Better would be to read “Upgrade server unreachable”

1 Like

In the config.xml was standard parameters and in that way also automatic updates enabled.

Regarding your advice, I doe also that way. Finally I imagine, that also in the database maybe are informations about parameters.

that also in the database maybe are informations about parameters.

I don’t think Syncthing records the upgrades enabled/disabled in the database from what I’ve read so far.

@Andy I’ve created a new Syncthing instance for testing purposes without the MSI. It shows this DB content “as raw”.

So the upgrade info is somehow present in the DB, but I think that is for coordinating schema upgrades and not relevant to your problem described above.

It could at least explain the behavior as observed. Nevertheless, it would not be entirely plausible because after the installation I exchanged the complete settings directory together with the database for the previous version in which the automatic upgrade was activated.

That’s why I came across the registry, as it was independent of it. But it also seems to me that there are other entries of STNOUPGRADE besides

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\The Syncthing Authors\Syncthing

I found e.g.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\ Environment

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

I don’t know if they have any influence. However, it appears to be typically backup entries from Windows.

Maybe you could do it differently. By definition, an MSI is an installer package with no optional features. Wouldn’t it make more sense to make an EXE in which various installation options can be selected?

This is your Windows environment. E.g. run “systempropertiesadvanced.exe” from the start menu, you can click the last button “environment variables” on the dialog to edit them manually without requiring REGEDIT. Remove STNOUPGRADE “plus” a config.xml where upgrades are enabled and you’re good to go.


The database records the schema version and minimum version required to open it, as Catfriend1 guessed. It does not store anything at all related to enabling or disabling upgrades.

1 Like