Remote registry permissions

I would like to be able to access the remote registry of my Windows XP Pro clients.

If I set the Security permissions on each registry hive to allow domain admins full access, all is well until I reboot and the permissions go away and back to default.

So, I thought I could get around this by opening the control panel and adding domain admins to the local administrator group.  However, when I do that it takes, but when I open the control panel again to view this it's as if I never made any changes.

Is there a way that I can get these permissions to stick through group policy?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

is this what you want

How to Manage Remote Access to the Registry

Also check this

Specify Anonymous Remote Registry Access

mb2010Author Commented:
Yes.  The permissions are set correctly, but when I reboot the permissions I set go away.
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

You need to check the OU in which you have these computers that are giving you the trouble. Make sure there isn't a GPO linked to that OU that is preventing what you're trying to accomplish. This would make sense because the policy is going to get re-applied with each re-boot.
mb2010Author Commented:
Hmmm!  Everything checks out.  Funny thing... I can access the remote registry of my Windows 2000 Professional clients, but not my Windows XP Professional clients.  I am a domain admin and an enterprise admin.  One would think that I would be able to access anything over the network.  I thought it might be a GPO problem, but can that be specified by OS type?  I checked my GPO settings and they appear to be fine.

mb2010Author Commented:
Hello Experts!  Here is some updated information:

All is okay when I connect to a remote Windows 2000 registry.  

The problems are with connecting to a remote Windows XP Professional registry.  I get the same symptoms when trying to connect to a Windows XP registry regardless of what OS I try to connect from.  I have tried from Windows XP Professional machines, Windows 2000 Professional machines, and Windows 2000 Server machines.
When I try to open a remote key via Windows XP Professional using regedit or regedt32 I get this error:
Error Opening Key.  Cannot open HKEY_LOCAL_MACHINE: Error while opening key.
If I try from a Windows 2000 Server or Professional box using regedit,  I get the same error.  If I use regedt32 from a Windows 2000 Server or Professional box it shows me the key, but everything below is greyed out.

Please advise.
We had this exact same problem, along with Microsoft BaseLine security analyzer not working on Window XP machines and not being able to access the local users and groups snap-in for the computer managment console. We found the cause of all of these problems to be in one group policy. Under Computer Settings->Windows Settings->Security Settings Registry add or edit the following keys:
1. HKLM/software/Microsoft/windows nt/current version/perflib
Give permissions
      Interactive – Read
      Network Service – Read
2. HKLM/System/currentcontrolset/control/securepipeservers/winreg
Give permissions:
      Local Service – Read
3.HKLM/System/currentcontrolset/services/sysmonlog/log queries
Give permissions:
      Network Service – Full Control
4 HKLM/system/currentcontrolset/services/tcpip
Give permissions:
      Local Service – Full Control
      Network Configuration Operators – Read
      Network Service – Full Control

We think #4 is most important and hope to narrow it down to just the tcpip key, but as of now everything is working for us. Make sure the permissions propagate down through the tcpip subkeys.
Hope this helps
mb2010Author Commented:
Sorry for the delay.  Are you talking about a domain group policy or a local machine group policy?  The reason I ask is because Network Service, Local Service, and Network Configuration Operators are not domain accounts.  BTW... I have increased the points to 500.


Inability to access Windows XP client registries remotely



Default Domain Policy had several ambiguous registry entry changes and file structure changes.  Also, permission on a registry key was incorrectly set.



Reproduced default Domain Policy, then Added 'Local Service' with 'Read' control to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg



Getting the registry change to all Windows XP clients.

The LOCAL SERVICE account is a local machine account, and not a domain account.

Regardless of how the batch file is pushed out, even if you try to manually run it, it will not work unless the user who logs on is a member of the local administrators group.  Have tested demo of MultiReg from Aelita Software.  It works, but costs money to register. Tried Microsoft’s Regini program that comes with Windows Resource Kit Tools.  Cannot use Local Service account.
Sorry about the lack of details. All of these are local accounts. We did not give Network Configuration Operators the read permissions on the tcpip registry value because we were not able to find this group.

I am sort of confused but hopefully the next two paragraphs will help.

The default domain policy should be able to push out this security change because it runs( with its elevated rights) before the user logs onto the machine. Try creating a very trimmed down GPO that only changes the few keys mentioned and link that to some test computers.
Windows XP will sometimes take more than one reboot to get the GPO to the local machine because of the way it starts the operating system. I believe this is called asynchronous mode(correct if wrong). We have had to reboot some XP machines up to 4 times before they received group policies.
If you are using a batch file I am guessing that you are pushing the batch file out via a domain logon on script from the NETLOGON directory. We use kixtart for all of our logon scripts. You can use the runas command in a script to let it push out the registry value as a user with elevated rights. The problem with this is that the users password is in clear text in the script file. IT IS NOT SECURE! Another program called kixcrypt can encrypt kixtart scripts so that the password is not in plain text. BETTER SECURITY! You could also write a short vbscript to do this and then run that script as a user that has local admin rights from any machine in the office.

I hope this helps you with your problem. I would keep hammering on the GPO that changes this registry value because it is by far the easiest way to go. I can also give you some vb script templates to help.
mb2010Author Commented:
Hmm!  Thanks for the information.  It's ironic that I first consulted Microsoft with this and they told me all I need to do is make a registry permission change.  After that they closed the case and did not tell me how to push that change to my clients.  You have been a big help so far.

All I am looking to do at the moment is push permission changes to the following registry key on my XP clients.  According to MS, this is the only registry permission that needs to change.


I need to add the 'Local Service' account to this key with read only permissions.  (Local Service is not a domain account.  It can only be found on local machines).

What do you think would be the best way to push that change?  I cannot use domain GPO because the Local Service account is not on the domain and is only a local machine account.  Do you have a VB script that would do this or should I look into KiXtart?  I would rather try what I have first, and then think about 3rd party if possible.
I think I see the problem you are having with adding local user to the GPO. When you are adding users for permissions to the registry make sure that you are searching the local computer and not the domain. Under the "From this location:" box make sure you highlight the local machine you are working from not the domain.  Now, when you search the local computer you should be able to pick up that LOCAL SERVICE account. Give it the read permissions.

The Alternative
With the scripting, Kixtart is awsome(look into it for logon scripts)  but for this problem i would use vbs. the vb script can run with the permissions of the user running it and then you can remotely modify the registry of all machines in active directory or machines listed in a custom text file. A script to this would not be very long at all. Here is a simple script to list the sizes of all subdirectories in a directory. We use it to see the size of all the users redirected "My Documents" directory and then bitch at them when those directories get to big. Nah, jk we don't bitch. run it at the command prompt by typing "cscript filename.vbs". I hope this can get you started. We actually need a script to modify remote registries on the fly so I will write one and post it.

'January 2004 Joshua Keys
'global variables that can be used by all functions and subroutines
Set FSO = CreateObject("Scripting.FileSystemObject")
Dim logArg
Dim logName

'Calls the Main subroutine

Sub logging
      For Each arg In Wscript.Arguments
            If arg = "-l" Then
                  logArg = True
            End If
End Sub

Function findFileInArgs(ByRef argm)
      count = 0
      For Each arg in Wscript.Arguments
            If arg = argm Then
                  findFileInArgs = count + 1
            End If
            count = count + 1
End Function

Function nameLog()
      If findFileInArgs("-l") = (Wscript.Arguments.Count) Then
            logName = "subsize.log"
            logName = Wscript.Arguments.Item(findFileInArgs("-l"))
      End If
End Function

'Creates a text file with the name given by function parameter fileName
Sub createLog(ByRef fileName)
      Set logFile = FSO.CreateTextFile(fileName)
      logFile.WriteLine(" Log File from subsize.vbs                        ")
      logFile.WriteLine(" Date: " & Date & " " & Time & "                    ")                
End Sub

Sub Main
      If WScript.Arguments.Count = 0 Then
                Wscript.Echo "Usage: dirsize.vbs [path] [-l] [custom.log]"
                Wscript.Echo "Use -l parameter to write results to a text file. The default file name is"
                Wscript.Echo "subsize.log. Specify a custom name after the -l parameter."
            Wscript.Echo "The created log file is delimited by tab."
      End If
      If logArg Then      
      End If

      Set target = FSO.GetFolder(WScript.Arguments.Item(0))      
      For Each Subfolder in target.subFolders
            Set objSubFolder = FSO.GetFolder(subfolder.path)
            Set AllFiles = objSubFolder.Files
            GetFolderSize = objSubFolder.size / 1048576
            Wscript.Echo subfolder & " SIZE: " & CInt(GetFolderSize) & "MB"
            If logArg Then
                  Set logFile = FSO.OpenTextFile(logName, 8)
                  logFile.WriteLine( subfolder & vbtab &  CInt(GetFolderSize) & "MB")
            End If
End Sub
mb2010Author Commented:
Thanks.  Yes.  I have no problem doing it to the local machine via the local machine.  In this situation, you are allowed to choose the local computer where it says "From this location:".

However, walking to each computer is not an option.  I am trying to set a domain wide policy and on a Windows 2000 domain controller, it will not let you choose a local computer.  It says "Look in:" and only lists the domains.

I think you are headed in the right direction regarding the VB script.  I wish I had more knowledge of scripting.  I would very much appreciate you writing up a script for what I am trying to do.  Thanks much!
You must be using a windows server 2003 machine or a windows xp pro machine to edit the domain policies in a domain where windows xp or windows server 2003 machines are.

Lets try this first. Make sure that you are editing this group policy from some sort of administrative windows XP machine. Install the server utilities on this computer so that you can get to Active Directory users and computers. Again Make sure you are using XP to do this.
You should now have the "From this location:" box even if you are editing the domain policy.

If that does not work try below.
Are you using the Group Policy Management Snap-in?
If not
this makes group policies much more pleasent
You must use windows xp or 2003 to manage the group policies with this snap-in.
It is designed for 2003 but works on 2000.
When you get this plugin installed you will then be able from and XP machine to us the "From this location:" box for your default domain policiy.

I know how much of a pain in the ass this is, but we should have it fixed by tomorrow.
Just on a side note. I was thinking and writing a script for this may not work because initially we do not have remote access to the windows xp remote registry. Hopefully the previous post will alleviate the problem.
mb2010Author Commented:
It let me set everything up, but no change yet.  I have a sub policy under the default domain policy called "WinReg".  I am making the changes on the PDC emulator.  I'll give it some time to replicate accross the network.  PDC emulator is east coast, and I'm on west coast.

BTW... I like the new GPM Snap-in.  Thanks for the tip.
If you look I made mention way back to make sure you weren't having an issue with Group Policy. Could have saved some time by starting with looking at this eh?
mb2010Author Commented:

On the segment that has the PCD emulator where I created the policy, it looks like some machines have the update and others do not .  The PCs that I cannot connect to on the  PDC emulator segment must not have been rebooted yet.

On other segments, such as mine, the policy has not taken place yet.  You would think that the policy would have been pushed out by now.  Even if I do a "gpupdate /force" command from one of my workstations on my segment, it does not take the changes.
I've been really busy today, but will put in as much time as possible as this is something I would like to help with.
This does look wierd. The PDC emulator is probably on a fast and stable connection so I would rule that out. Remember that some of the XP machines may take multiple reboots before ever getting the policy. Even with the gpupdate /force the XP machines may miss the GP because of the way they start up. If  that is the case though I would think they would have pulled the policy by now. Has anything changed yet today?
Is your domain in mixed mode?
mb2010Author Commented:
Nope.   Native mode.
PAQed, with points refunded (500)

Community Support Moderator

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Just an FYI.  Had a similar issue when trying to connect using remote registry.  The fix was to disable "Use Simple File Sharing" under folder options.  I was then able to scan the box and pull the info I needed.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.