![]() ![]() I believe the reason is because not even SYSTEM has access rights to this particular Registry key remember that TrustedInstaller owns it. Unfortunately, I still get the same SecurityException message. I saved the Powershell commands posted above into a file on my desktop called chowner.ps1 and then ran the following command: PsExec64.exe -accepteula -d -i -s powershell -ExecutionPolicy Bypass -File C:\Users\User\Desktop\chowner.ps1 UPDATE: Per briantist's suggestion, I tried running these commands as SYSTEM using psexec. What is that regedit is doing differently from my script here? How can I accomplish this programmatically? If I manually edit the permissions of that key using regedit, I'm allowed to do that without problems. my guess is that I'm running into a bit of a chicken and egg problem here. I am already running Powershell with Administrative privileges but that obviously doesn't seem sufficient. Presently the owner of that Registry Key is NT SERVICE\TrustedInstaller, and I'm trying to change it to Administrators. $account = New-Object -TypeName -ArgumentList 'Administrators' However, at the last command (Set-Acl) I get a SecurityException saying "Requested registry access is not allowed." $path = "Registry::HKEY_CLASSES_ROOT\AppID\" My typical permissions for registry nodes in that sections are: Users > Read access Administrators > Full Control access SYSTEM > Full Control access CREATOR OWNER > Full Control access ALL APPLICATION PACKAGES > Full Control access And service specific permissions are lost. I'm trying to execute the following Powershell script, which should (in theory) do what I need to do. If your user account isn’t the current Owner, click the Change link. Click Advanced on the Permissions dialog box. I found a solution online that recommended changing permissions (first in the registry, then in DCOM configuration), and I'm trying to write a Powershell script to automate the process. Right-click on the key and select Permissions. I ran into a bizarre issue when I upgraded some machines to Windows 10 where incorrect permissions on RuntimeBroker caused problems. ![]()
0 Comments
Leave a Reply. |