I have a program that requests performance counter information from a remote Vista machine. In its simplest form it is just a single line of Visual Basic code: PerformanceCounterCategory.Exists("Memory", remotemachinename) If I run as an admin (admin accounts on both machines) everything is fine. But if i run as a standard account (non-Admin on both machines) I get an access denied error on "openHKPD". That is the hidden registry hive HKEY_PERFORMANCE_DATA. Anyone have ideas about why a standard account would fail? It does not fail if I run the request locally on the machine so the standard account has sufficient permission. If I run from Vista to a remote XP machine I do not get this error so I am thinking it may have something to do with registry virtualization on Vista. Or it may have something to do with UAC except these are non-Admin accounts so UAC should not matter. FYI Remote registry service is running and the registry key ....\securepipeservers\winreg has granted permission to the non-Admin account. -- DreamU
"DreamU" wrote in message news:1a2541f33b42dd3948311e89643722e0@nntp-gateway.com... > > I have a program that requests performance counter information from a > remote Vista machine. In its simplest form it is just a single line of > Visual Basic code: > > PerformanceCounterCategory.Exists("Memory", remotemachinename) > > If I run as an admin (admin accounts on both machines) everything is > fine. But if i run as a standard account (non-Admin on both machines) I > get an access denied error on "openHKPD". That is the hidden registry > hive HKEY_PERFORMANCE_DATA. Anyone have ideas about why a standard > account would fail? It does not fail if I run the request locally on the > machine so the standard account has sufficient permission. > > If I run from Vista to a remote XP machine I do not get this error so I > am thinking it may have something to do with registry virtualization on > Vista. Or it may have something to do with UAC except these are > non-Admin accounts so UAC should not matter. > FYI Remote registry service is running and the registry key > ...\securepipeservers\winreg has granted permission to the non-Admin > account. > What it really comes down to is that the user-id for the Standard user account in not on the registry with proper access rights or it's not there period on the remote machine, as opposed to the Administrators group is on the registry entry when you are using an admin account. It's *access denied* for the Standard user and its user-id.
Let me elaborate on my earlier comment: when I say the command works when I run it locally that means I log in as that standard user with the exact same username and password (which exists on both the remote machine and the host). So, it does exist and because it runs fine locally there are no registry access issues with the standard user. Now, even though it runs fine locally I did something a little crazy to try and troubleshoot: I specifically gave the standard user full control permission on CurrentControlSet\Services which is where the performance pointers are stored. So that local user was basically made equivalent to an Admin even though it already ran fine locally. I think the issue is with remote HKPD access and becuase it is hidden I don't know how to grant permission. Secondly, there is something odd about Vista which is clearly applying a different rule/permission when run remotely as opposed to locally. -- DreamU
DreamU wrote: > Let me elaborate on my earlier comment: when I say the command works > when I run it locally that means I log in as that standard user with the > exact same username and password (which exists on both the remote > machine and the host). So, it does exist and because it runs fine > locally there are no registry access issues with the standard user. > > Now, even though it runs fine locally I did something a little crazy to > try and troubleshoot: I specifically gave the standard user full control > permission on CurrentControlSet\Services which is where the performance > pointers are stored. So that local user was basically made equivalent > to an Admin even though it already ran fine locally. > > I think the issue is with remote HKPD access and becuase it is hidden I > don't know how to grant permission. Secondly, there is something odd > about Vista which is clearly applying a different rule/permission when > run remotely as opposed to locally. > > It makes sense to me that a Standard user cannot access the registry of a remote machine, Vista is not XP. I guess that kind of access is denied on Vista. You can look-up more information about this. <http://www.vistax64.com/vista-account-administration/98216-when-standard-users-access-vista-registry-remotely-access-denied.html>
Thanks for the link but that information is just plain wrong. Specifically, it says "A standard user cannot connect to the registry of a remote PC." This is not true, as a standard user on XP I can connect to a remote Vista and read every key I have tried. Now, I can't modify the remote registry but I certainly can connect. (P.S. This is through Regedit/Connect Network Registry) -- DreamU
"DreamU" wrote in message news:b8aaab5665b9c7ab06c01fe17fd33931@nntp-gateway.com... > > Thanks for the link but that information is just plain wrong. > Specifically, it says "A standard user cannot connect to the registry of > a remote PC." This is not true, as a standard user on XP I can connect > to a remote Vista and read every key I have tried. Now, I can't modify > the remote registry but I certainly can connect. (P.S. This is through > Regedit/Connect Network Registry) > > Maybe your attempt to access as Standard user is being redirected to another area. http://technet.microsoft.com/en-us/magazine/cc160882.aspx
Thanks for the link on Registry Virtualization. Ironically, virtualization allows standard user writes to occur where they used to fail under XP. So, my standard user would have more capability! I know I questioned virtualization in my initial thread but it is really a long shot. No only becuase it provides more power but also becuase I don't write to any registry keys in my program so I don't need the extended capability. -- DreamU
"DreamU" wrote in message news:d04270a73bb9f6ca1fb3f662dae0a11b@nntp-gateway.com... > > Thanks for the link on Registry Virtualization. Ironically, > virtualization allows standard user writes to occur where they used to > fail under XP. So, my standard user would have more capability! I know I > questioned virtualization in my initial thread but it is really a long > shot. No only becuase it provides more power but also becuase I don't > write to any registry keys in my program so I don't need the extended > capability. > Well, you had better take a long look at what you're doing, because as it stands now, you have not found a solution that's going to allow you to come around *access denied*, unless you have admin privileges with that VB program. This is just some FYI. http://www.developer.com/net/net/article.php/3695651 <http://channel9.msdn.com/posts/jmazner/How-To-Tell-Vistas-UAC-What-Privelege-Level-Your-App-Requires/> good luck
"DreamU" wrote in message news:d04270a73bb9f6ca1fb3f662dae0a11b@nntp-gateway.com... > > Thanks for the link on Registry Virtualization. Ironically, > virtualization allows standard user writes to occur where they used to > fail under XP. So, my standard user would have more capability! I know I > questioned virtualization in my initial thread but it is really a long > shot. No only becuase it provides more power but also becuase I don't > write to any registry keys in my program so I don't need the extended > capability. > Here is one other thing for you about Vista and UAC. http://technet.microsoft.com/en-us/magazine/cc138019.aspx
