This is actually more difficult that it would initially appear. While most of the time the folder name of the profile will equal the username, that is not always the case. When dealing with domains and local accounts that have the same name or corrupted profiles, there can be any number of variations in the folder name. To get around this you can retrieve the SID of the current user and then check against a registry key that stores the folder names. For some reason there is a trailing %00 when you pull the value, so there is some relevance included to handle that.
not exists file (preceding text of last “%00” of (value “ProfileImagePath” of key (“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList” & (component string of sid of security account (name of current user))) of registry as string) & “\Desktop\read.txt”)
Let me know if you have any questions, but that should do the trick no matter what the folder is named.
Well, I just noticed that my relevance does not appear to work on Windows XP, but it does on Windows 7. Scroll to the bottom for the update and a caveat. Ben, while your relevance will work on some occasions, there are multiple factors that will throw it off. This is what I came up with mine to make it work cross operating system:
One of those would be what I referred to earlier-- the username does not always equal the profile name. As an example, the name of my profile folder on my computer is actually “username.DOMAIN”. This happened because when I logged onto the domain for the first time, there was already a profile folder name of “username” from an account of the same name on the local computer. There are other instances when the profile becomes corrupted and you end up with a folder name of “username.001” and so forth.
The other thing that checking the registry solves is the name of the folders the profiles are stored under. The default location is in varies for different operating systems:
WindowsNT: %systemroot%\Profiles
Win2k\XP\2003: %systemdrive%\Documents and Settings
Vista\2k8\7: %systemdrive%\Users
Using the code below should handle all of these situations:
not exist file (value of variable “SystemDrive” of environment & “” & (following text of first “” of it) of (preceding text of last “%00” of it) of (value “ProfileImagePath” of key (“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList” & (component string of sid of security account (name of current user))) of registry as string) & “\Desktop\read.txt”)
The mistake I had before was that Windows XP stores this registry value as “%SystemDrive%\Documents and Settings” and Windows 7 stores it as “C:\Users”. So I had to lob all everything before the first “” and insert the “SystemDrive” environment variable. The one caveat with this is that if an administrator changed the profile to be on a drive other than the “SystemDrive”, it will fail. I think that is pretty rare though and I have only done it on servers-- in particular Terminal Servers that end up having very large profile folders.
Any questions, let me know, but that should work across the board with Windows operating systems.
Well, I just noticed that my relevance does not appear to work on Windows XP, but it does on Windows 7. Scroll to the bottom for the update and a caveat. Ben, while your relevance will work on some occasions, there are multiple factors that will throw it off. This is what I came up with mine to make it work cross operating system:
One of those would be what I referred to earlier-- the username does not always equal the profile name. As an example, the name of my profile folder on my computer is actually “username.DOMAIN”. This happened because when I logged onto the domain for the first time, there was already a profile folder name of “username” from an account of the same name on the local computer. There are other instances when the profile becomes corrupted and you end up with a folder name of “username.001” and so forth.
The other thing that checking the registry solves is the name of the folders the profiles are stored under. The default location is in varies for different operating systems:
WindowsNT: %systemroot%\Profiles
Win2k\XP\2003: %systemdrive%\Documents and Settings
Vista\2k8\7: %systemdrive%\Users
Using the code below should handle all of these situations:
not exist file (value of variable “SystemDrive” of environment & “” & (following text of first “” of it) of (preceding text of last “%00” of it) of (value “ProfileImagePath” of key (“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList” & (component string of sid of security account (name of current user))) of registry as string) & “\Desktop\read.txt”)
The mistake I had before was that Windows XP stores this registry value as “%SystemDrive%\Documents and Settings” and Windows 7 stores it as “C:\Users”. So I had to lob all everything before the first “” and insert the “SystemDrive” environment variable. The one caveat with this is that if an administrator changed the profile to be on a drive other than the “SystemDrive”, it will fail. I think that is pretty rare though and I have only done it on servers-- in particular Terminal Servers that end up having very large profile folders.
Any questions, let me know, but that should work across the board with Windows operating systems.
Hi BrianK
it seem like it only works on windows 7, is there anyway to get it work on windows XP?