1

I'm trying to retrieve the path of the profiles directory across various versions of Windows. In older versions that might be [drive]:\Documents and Settings, on newer ones it's [drive]:\Users. There are several ways to do this locally without a problem, however I need to find the path on a remote machine that I've connected to.

  • Remote Registry is enabled.
  • I have an impersonation token and can successfully gather information from the remote host via the Net API, etc.
  • I have access to the administrative share, and therefore all the files on the remote drive.

Here's a list of other important caveats.

  • It's a C++ project.
  • It doesn't seem to be possible for GetProfilesDirectory or GetUserProfileDirectory to operate in a remote context. If I'm wrong about this please let me know but in all my experiments the function has returned something from the local machine.
  • I can't use WMI, we tried many times to integrate WMI functionality into our project and it just didn't work.
  • I would prefer to do as little "screen scraping" as possible. If you have an idea that doesn't involve reading from some text file and parsing the result, I'd love to hear it. But I'd appreciate any useful answer really.
  • The profile directory information in the registry don't seem to be useful because it contains environment variables, and like GetProfilesDirectory, the environment variable expansion function does not seem designed for work with remote hosts. This means that the solution wouldn't work if I was making the call from a newer Windows machine to an older Windows machine or vice versa.
  • The solution should be general enough to work between hosts that might be running any version of Windows from Windows Server 2003 to Windows 7.

Thanks in advance for whatever ideas you might have. Ideally I'd just like to be able to force GetProfilesDirectory to operate on the remote host so if you know how to do that I'll love you forever.

ShiggityShiggityShwa
  • 194
  • 9
  • Please define "a remote machine", and "I've connected to". Is "remote machine" on your local intranet, or somewhere else? In what way are you "connected" to that machine? You've provided a lot of detail, but seem to have omitted the most important ones. Thanks. :) – Ken White Mar 09 '12 at 03:13
  • Can you access: HKEY_USERS/*/Software/Microsoft/Windows/CurrentVersion/Explorer/Shell Folders? It's not recommended to use this key but I've seen it being used. – akhisp Mar 09 '12 at 03:17
  • A "remote machine" in this context is a machine on the local network that I can identify by specifying its address as part of credential information that would be accepted by LogonUser. The actual calls used to set up the connection are: WNetAddConnection2, LogonUser, ImpersonateLoggedOnUser, RegConnectRegistry – ShiggityShiggityShwa Mar 09 '12 at 03:45
  • @akhisp These keys appear to contain information I'm interested in, although I would have to do some parsing to whittle them down. But why is it not recommended to use them? I'm writing code for a commercial product here so I'd prefer not to do something that will break under X number of conditions. – ShiggityShiggityShwa Mar 09 '12 at 03:53
  • Ok, after reading a bit about Shell Folders I can understand why it would not be recommended. Unfortunately it seems that there isn't really any consistency when it comes to what you will find in that location. But I'll keep the whole thing in mind just in case. – ShiggityShiggityShwa Mar 09 '12 at 04:01
  • I have written commercial products that use this key, the only thing that we found not to work is that these are blank for some users. This was when our programs were run under a Windows Service. In those registry keys there's one entry put in my Windows itself telling you to use the API and not the key itself. – akhisp Mar 09 '12 at 04:03
  • Haha, I've seen Microsoft warning keys. You can find them in hidden areas of the registry as well. It was sort of amusing running into that. alexisdm's SystemDrive idea might make for a more robust solution. I'll need some time to toy with it. If anyone has a more elegant solution, please let me know! – ShiggityShiggityShwa Mar 09 '12 at 04:17
  • @ken-white Sorry, I guess I need to specifically mention someone by name in order for them to know that I've replied to them... so, see my first reply above, haha. Thanks. – ShiggityShiggityShwa Mar 09 '12 at 04:27
  • Or @Ken maybe. Long time lurker, first time poster. – ShiggityShiggityShwa Mar 09 '12 at 04:36

1 Answers1

1

If you have access to the remote registry, you should be able to look at the key where the profile directory and the profile list is kept:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
alexisdm
  • 29,448
  • 6
  • 64
  • 99
  • I believe those keys contain environment variables. The values look like %SystemDrive%\Users and so on. Technically I could grab this information and use it to construct what I want but then I would also need a solid way to determine what the correct drive is. – ShiggityShiggityShwa Mar 09 '12 at 03:43
  • According to [this](https://groups.google.com/d/msg/microsoft.public.win2000.registry/hP7RAuNMfZ8/xwK2BfLbsUwJ) you could get %SystemDrive% from the value of SystemRoot in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\. – alexisdm Mar 09 '12 at 04:00
  • Ah, yes, my Windows Server 2003 and Windows 7 test installs both have this key, in the same location, with the same information. I will do some more research on this to see how much variation there might be. It wouldn't be the cleanest solution but it's helpful, thanks. – ShiggityShiggityShwa Mar 09 '12 at 04:08
  • I'm going to mark this as my accepted answer, given the %SystemDrive% follow-up post. I really wish there was a better way to do it but while this solution doesn't provide any guarantees it should still get the job done. I'll make a new question if there end up being further issues. Thanks again. – ShiggityShiggityShwa Mar 09 '12 at 20:17
  • So %SystemRoot% is what we need to work with, as alluded to above. I'm going to parse the drive out of %SystemRoot% and hopefully %SystemRoot% will always contain %SystemDrive%. They aren't set up that way in the system for whatever reason but it makes sense that their values would be that way in all cases. – ShiggityShiggityShwa Mar 09 '12 at 20:19