Set-PTA - Error Thrown - Write Reg Protocol UserChoice FAILED

[itoc-dw]

Downloaded script. Imported functions into powershell session. Tried to set chrome as default browser using "Set-PTA ChromeHTML http". Error is thrown "Write Reg Protocol UserChoice FAILED". Chrome is not the default.

OS: Windows 10 22h2 (19045.4123) Powershell: 5.1.19041.4123

Chrome can be selected by Windows Default Apps control panel.

Any assistance would be greatly appreciated. Thank you.

[maxon-de-alvares]

The same problem Win10 Pro 22h2 19045.4123

Before that, I used SetDefaultBrowser.exe https://kolbi.cz/blog/2017/11/10/setdefaultbrowser-set-the-default-browser-per-user-on-windows-10-and-server-2016-build-1607/ After the last update, everything broke down :(

[maxon-de-alvares]

By the way, it works if you run it through Windows Powershell ISE

[Danyfirex]

I will try to emulate the problem. I'm not using this script too much so that's the reason I'm not looking at it frequently.

[maxon-de-alvares]

The feeling that the problem is in the recording rights

[itoc-dw]

Testing back and forth I may be a bit jumbled here as had to deal with some powershell constrained language in the mix as well.

If you don't throw the error, does it set for you? I've changed it to Edge, then it appears to now set it as Chrome.

try {
  $keyPath = "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\$Extension\UserChoice"
  [Microsoft.Win32.Registry]::SetValue($keyPath, "Hash", $ProgHash)
  [Microsoft.Win32.Registry]::SetValue($keyPath, "ProgId", $ProgId)
  Write-Verbose "Write Reg Extension UserChoice OK"
}
catch {
   Write-Error "Write Reg Extension UserChoice FAIL"
   #throw "Write Reg Extension UserChoice FAIL"
}

Stumbled across it as Set-PTA has been exiting our login scripts half way through due to the throw.

[itoc-dw]

Powershell Error: at local:Write-ProtocolKeys

Write Reg Protocol UserChoice FAIL - Exception calling "SetValue" with "3" argument(s): "Attempted to perform an unauthorized operation." Attempted to perform an unauthorized operation. Write Reg Protocol UserChoice FAIL - Exception calling "SetValue" with "3" argument(s): "Attempted to perform an unauthorized operation." Attempted to perform an unauthorized operation.[0] Exception calling "SetValue" with "3" argument(s): "Attempted to perform an unauthorized operation." Attempted to perform an unauthorized operation.

[itoc-dw]

Looks like the issue is only occurring on that preview build of windows. We have another up to date windows 10 machine on build 19045.4046 without this preview CU and the issue does not occur. I hope this doesn't go through to the main CU in March.

[maxon-de-alvares]

Alas, there is a problem in the March update (OS Builds 19044.4170 and 19045.4170) . https://support.microsoft.com/en-us/topic/march-12-2024-kb5035845-os-builds-19044-4170-and-19045-4170-24e9864f-0756-457e-bce9-3f681020d591

The main reason is that changing the parameters in the registry hive is blocked. HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice

And this is not related to the rights to the registry hive (I tried to change the owner and rights from under the system user (not the administrator, directly the system user). It looks more like read only of these settings, protected by Windows Defender or something.

It looks very much like this is not a bug, but a feature. :(

[Topowopelop]

Alas, there is a problem in the March update (OS Builds 19044.4170 and 19045.4170) . https://support.microsoft.com/en-us/topic/march-12-2024-kb5035845-os-builds-19044-4170-and-19045-4170-24e9864f-0756-457e-bce9-3f681020d591

The main reason is that changing the parameters in the registry hive is blocked. HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice

And this is not related to the rights to the registry hive (I tried to change the owner and rights from under the system user (not the administrator, directly the system user). It looks more like read only of these settings, protected by Windows Defender or something.

It looks very much like this is not a bug, but a feature. :(

I had the same issue on my end; it was working fine until the March update - I managed to get it working again by tweaking the code so that it runs when the machine is first booted up, before any user has logged in - it loads the intended user's registry into a HKEY_USERS\temp hive, makes all the changes there, and unloads the registry. No warnings/errors about modifying the registry during this process, and once the user logs in, all the default file associations/protocols (I'm using it for htm, html, http, https, mailto, and pdf) are correct. I assume that Windows is preventing changes to HKCU only, so by "side-loading" the registry to make the changes, I'm bypassing that check.

EDIT: Never mind, looks like KB5035853 wasn't actually installed yet on that test machine after all - once Windows was properly updated, I'm still getting the same permissions error. Currently looking to see if there's any decent way to modify the NTUSER.DAT file without loading it into registry first; that's about the only idea I've got left.

[gunnarhaslinger]

This behaviour is caused by UCPD Kernel Filter Driver Service - UserChoice Protection Driver. If you reconfigure UCPD to be "disabled" and reboot the Machine everything works fine again. But be aware, there is a Scheduled Task named "UCPD velocity" which calls "UCPDMgr.exe" which re-Enables the Service after each LogOn Of a user and 10min Idle-Time.

See my Blog-Post: https://hitco.at/blog/windows-userchoice-protection-driver-ucpd/

[Topowopelop]

thanks @gunnarhaslinger , that pointed me where I needed to go. Even though an sc query shows ucpd as stoppable, it definitely isn't, so I've got my script disabling startup of ucpd, rebooting, making the necessary registry changes, then reenabling ucpd and rebooting again (probably unnecessary due to UCPDMgr, but better safe than sorry). That's a lot of hoops to jump through for something that seems so trivial, but I'm using this as part of a script to prepare hundreds of machines, so every little bit helps crank down the total man-hours dedicated to setting up new PCs. Unless we can find a way to modify the applicable parts of ntuser.dat while it's not in use, I'm not sure there's an easier way to do this anymore, with how Windows is trying to lock all that down.

[Yomark1]

Is there a reason ( except for the security issue this driver "solves" = not being able to control FTA's using script) not to leave UCPD disabled?
So basically, run this:

schtasks.exe /change /Disable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
sc.exe config "UCPD" start= disabled

(+reboot)

Disabling UCPD is like going back to how windows was a month ago, right?

[gunnarhaslinger]

That's exactly what I currently suggest in my Blog-Post: https://hitco.at/blog/windows-userchoice-protection-driver-ucpd/

For the moment I cannot see any other "Functionality" this Driver provides and could cause side-effects. But of course this could change with the next Update - we don't know.

[farag2]

I use another approach, and it works perfectly. Please check, folks.

https://github.com/farag2/Sophia-Script-for-Windows/blob/bef76df7a7d3a027c7dbf3c79931cf4e328726fb/src/Sophia_Script_for_Windows_11/Module/Sophia.psm1#L6998

[gunnarhaslinger]

@farag2 in your referenced Line 6998 there is no UserChoice handling And in Lines 9017 ongoing there are just "Remove-Item" and "New-Item" Commands regarding the UserChoice Registry Keys which are blocked for PowerShell.exe when the UCPD Driver is running.

Of course for the moment this works if you don't use Powershell.exe but use PowerShell-ISE.exe or pwsh.exe (because Microsoft currently forgot to block them). But I guess this will be solved with one of the next Updates.

[farag2]

@gunnarhaslinger

Sorry, sent a wrong link: https://github.com/farag2/Sophia-Script-for-Windows/blob/bef76df7a7d3a027c7dbf3c79931cf4e328726fb/src/Sophia_Script_for_Windows_11/Module/Sophia.psm1#L8663

is no UserChoice handling

I just pointed to the whole function to show that everything works with another approach: hash is generated, icon is changed, no pop-up while opening a new extension.

which are blocked for PowerShell.exe when the UCPD Driver is running.

They aren't blocked if we use another method.

https://github.com/farag2/Sophia-Script-for-Windows/blob/bef76df7a7d3a027c7dbf3c79931cf4e328726fb/src/Sophia_Script_for_Windows_11/Module/Sophia.psm1#L8759

this works if you don't use Powershell.exe

It works without any issue in powershell.exe too.

Check the video I recorded on a VM.

https://github.com/DanysysTeam/PS-SFTA/assets/10544660/9804dad6-c8b9-4812-84cc-adf4361feeaa

But I admit that MS has changed something under the hood.

[gunnarhaslinger]

Your demonstration shows FileExtension .json, but .json is not protected by UCPD. Only those particular Registry-Keys are protected: Protocol-Handlers for http and https and File Extension .pdf

# SetProtectRuleOnStart Filter
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoiceLatest
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoicePrevious
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoiceLatest
Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoicePrevious
Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice
Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoiceLatest
Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoicePrevious

[farag2]

You're right. 😭

[mrmattipants]

The UCPD Driver can also be Disabled using the VIVETOOL Utility.

VIVETOOL Releases: https://github.com/thebookisclosed/ViVe/releases

vivetool /disable /id:44860385

NOTE: ucpdmgr.exe will Disable the UCPD Driver, when it Runs, via the "UCPD velocity" Scheduled Task.

[itoc-dw]

We have been trying to avoid disabling the driver as it could have important security features introduce at a later date without us being aware. A workaround that we are trialing is using Fslogix (already installed for us) and using a redirection rule to redirect the registry location to another spot which the user has access rights to. It does solve the problem and the set-fta works again but the first time the fslogix rules apply, windows detects the change and resets the defaults back system defaults. So the first logon can be a bit messy for existing profiles.

[luimen6]

Same here.