You’ve correctly surmised that updating HKEY_CURRENT_USER is fraught with issues, given that HKEY_CURRENT_USER is a virtual hive loaded differently for each logged-on user.
I think one of the issues is combining ‘wait’ with ‘regset’. ‘regset’ is a built-in ActionScript command, while ‘wait’ is trying to spawn an external OS process - and ‘regset’ is not a valid command in Windows.
To approaches you might…
- Use ‘wait’
- using ‘wait’ with the ‘RunAs=currentuser’ option helps avoid the “which profile should be updated” problem. But instead of ‘wait regset’ you’ll need to use something like ‘wait reg.exe’ with the reg.exe command-line parameters for your update.
- Use ‘regset’ without ‘wait’
- regset doesn’t respect the ‘override’ commands, so rather than [HKEY_CURRENT_USER…] you’d need to use Relevance to find that key beneath HKEY_USERS.
For the second method, we can find the “current” user in two different ways:
q: pathnames of user keys of current users
A: HKEY_USERS\S-1-5-21-1537867535-1137331447-1871363362-500
T: 0.026 ms
q: pathnames of user keys of logged on users
A: HKEY_USERS\S-1-5-21-1537867535-1137331447-1871363362-500
T: 0.026 ms
The difference is that the first method requires a console logon to Windows. ‘current user’ will not return a user who is logged on with Remote Desktop; the second method will return the RDP user, but there are potentially more than one RDP users connected so take care about plurals there.
So for a console logged-on user the second method could be expressed as
regset "[{pathname of user key of current user}\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]" "ProgID"="MSEdgeHTML
Also, be aware, that at least for some components (and this may be one of them), Windows has blocked directly changing the associations via the Registry; and requires either user interaction or a Group Policy to change the options. This is an anti-malware measure Microsoft took as drive-by downloads were changing file or browser associations.