Don't ignore HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI.

[tschoening]

I upgraded from version 2.3.13 to 2.4 and wondered about the new defaults for user specific configuration files and such. My former system wide defaults where not used anymore, so I used Process Monitor to see what happens...

It seems that the former HKLM-settings are completely ignored now? Is there any reason for that or something like a migration guide documenting that?

I already manually adopted the former HKLM settings to be able to work without any admin permissions for all users of a system and that worked perfectly well. The only thing I needed to do was to copy my config_dir and log_dir to HKCU, with exactly the same values as before, but I couldn't find where this is documented.

Additionally, reading from HKLM as a fallback always made sense to me for environments in which multiple users user the GUI and shoudl all store their logs and configs in the same dir structure. This can easily be done by using %APPDATA% int he registry:

"config_dir"="%APPDATA%
OpenVPN
config"
"log_dir"="%APPDATA%
OpenVPN
log"

So, I suggest to either write some migration guide or keep reading from HKLM as a fallback.

This is in reference to #837:

​https://community.openvpn.net/openvpn/ticket/837

[tschoening]

HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI

[Selva Nair]

GUI bundled with 2.4.0 doesn't read the HKLM key as now all settings are user specific and defaults are created on the fly when the user runs the program the first time. To customize the settings, use the settings menu in the GUI.

[tschoening]

Replying to selvanair:

GUI bundled with 2.4.0 doesn't read the HKLM key as now all settings are user specific and defaults are created on the fly when the user runs the program the first time.

The point is that system wide defaults for all users keep each individual user from the need to configure their account. Why should they be forced to do so manually? You already were able to take HKLM into account, using that as an additional fallback instead of your hard coded defaults makes perfect sense. While you are introducing a system level service and consider group membership of users to allow them being able to use VPNs, because admins should decide and what not, you are actively putting stones in the way of admins in this case without any benefit.

You don't even seem to provide any documentation or migration guide, things just stop working for no reason. I had the impression of a bug at first, because I used the GUI "more correct" than it was used to be.