I'm using .net to take ownership of some keys to clear a scan across several hundred machines. I really don't want to do it by hand, and my script seems to work on most keys, but one key is being a pain. In testing I've even gone out and taken ownership and made sure I had permissions on the key, still no luck. I've tried it on several servers with the same results. I can move to an adjacent key, or even one key up and it works, but the defaultproductkey comes back as a method on a null-value expression every time. So, after banging my head on the keyboard for a week, a not finding results in google, I'm breaking down and asking for help - any direction / instruction on this would be appreciated.
My function opens the remote HKLM like so:
$RemoteKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::'LocalMachine',$Server,[Microsoft.Win32.RegistryView]::Registry64)
Originally I had it open it without the Registry64 reflector, but somewhere along the way I started questioning if the key was in SYSWOW... the reflector seems to work fine no matter where a key is I'm looking at though.
My next step is to specify my key. This is the one that fails. $Key1 = $RemoteKey.OpenSubKey("SOFTWARE\Microsoft\Windows NT\CurrentVersion\DefaultProductKey\",$true) #this one failsThese on the other hand work fine:#$Key1 = $RemoteKey.OpenSubKey("SOFTWARE\Microsoft\Windows NT\CurrentVersion\",$true) #$Key1 = $RemoteKey.OpenSubKey("SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32\",$true) From here I grab the access control to check it $Key1.GetAccessControl() On the currtenversion, or on currentversion\drivers32 it spits out who owns it and who has permissions. But as soon as I choose currentversion\defaultproductkey it's dead. After this point I take ownership of the key, and want to put some logic around that to check before I do that part of the code but first I need to be able to access this one key that seems off limits to me.
Thanks for taking the time to read this, and if you have any thoughts or find a flaw I'd appreciate the pointer.
If I use your code against the local machine, I get the same result (but not on the adjacent "DefaultProductKey2" key). Also, Get-ACL can read the permissions from the key (I can't see anything weird) and I can use the registry provider and Get-ItemProperty to view the values under the key as well.
I then went back to the .NET SDK to look up the details of each step (since I know almost zero .NET). Your line that fails is using $true to say you want write access to the registry key. If you change that to $false, then the failing command now works. Indeed, looking closer at that registry key's permissions, I see the Administrators group only has Read access. The "DefaultProductKey2" key gives Administrators full control. This then, I presume is the explanation of what you're seeing.