I’ve been working on a fixlet to identify PCs whose users have their default web browser set to IE and set it to Edge. I know this can be accomplished with GPO but I don’t want to enforce it permanently so I think this is a better user case for fixlets if I can get it work.
I have no issues with relevance, but my action script fails upon the first regset command. I’m also running this on my own PC and it’s executing while I’m logged in, so I know it’s not failing because no one is logged in. Here’s the action script followed by the results from the logs:
Here’s the relevance for reference if anyone needs it:
exist value "ProgID" whose (it contains "IE.HTTPS") of keys (user key of logged on user as string & "\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice") of native registries
Try this: Q: exist value "ProgID" whose (it **as string** contains "IE.HTTPS") of keys (user key of logged on user as string & "\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice") of native registries
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.
Your relevance did not work on my test machine due to the string so I started there, but @JasonWalker got his teeth sunk into this one. Way ahead of me.
Oh, one more thing - if you use the ‘wait’ method, you’ll need to re-apply your ‘override wait’ settings for each execution of ‘wait’. So if you run ‘wait reg.exe’ twice, you need to list out the overrides twice.
I just checked and you’re right; if I manually changes those values Windows changes it right back; Windows must be using those hash values in the same key for checksum mismatches. While that does protect these keys from drive-by downloads, unfortunately it also makes this fixlet useless regardless of how it’s implimented.
Regardless, thanks for your detailed explanation as it makes sense that wait implies a windows command will follow which regset is not, and that regset ignores override. I’ll just move forward with the GPO method.
This is my first post but I’ve been lurking for years and you always provide great answers - thanks again!
