I want to map default location of ALLUSERPROFILE to some other folder.
I am following below link but no luck so far
https://www.pcreview.co.uk/threads/changing-userprofile-and-allusersprofile.4047094/
I believe what you want is the registry key
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList.
The easiest way to do this is:
When installing Windows, create a temporary user account with admin rights.
Log in with the temporary account, change the default user profile directory, and restart (I believe the registry change doesn't take effect until you restart);
Log in with the temporary account and create the "real" / permanent user accounts. Make sure at least one of these has admin rights.
Log in with the "real" admin account and delete the temporary / dummy account you created during install.
If you have existing profiles you want to move, it becomes much more difficult, because
The registry change will not affect existing user profiles.
IIRC you cannot move existing profiles while Windows is running. You have to boot into a recovery mode console and use RoboCopy to move the user profile folder(s).
I think I remember seeing a detailed write-up on this somewhere. I'll try and find it later this evening.
But I would caution you that relocating user profiles after the fact is problematic.
For one thing, the public and default user profiles are set up on C: (or more precisely, your system drive) during installation. If you move the entire profiles folder, there are a bunch more registry entries related to those two profiles that will need to be changed.
Further, I've encountered a number of programs that assume the user profile folder is C:\Users. That is a stupid assumption, but it is likely to cause you problems.
You can mitigate some of these issues by creating a symlink or junction from C:\Users to D:\Users (or wherever you move the user profiles to). Then anything looking in C:\Users should be transparently redirected to D:\Users. That gets you out of messing with the per-user folder settings in the registry.
It should also be possible to move selected user profiles to another partition. That is, you would leave C:\Users in place, create a D:\Users folder, and then move selected user profiles -- i.e. move C:\Users\jane to D:\Users\jane. You'd still want to use RoboCopy to do the actual move ... and in this case you would need to alter the profile folder registry settings for any user being moved ... and I would also recommend creating a symlink from C:\Users\jane to D:\Users\jane. This is more work, but it's less invasive.
But I can tell you I tried one of the above approaches on a Windows 7 machine -- it's been a few years, so I don't remember which -- and ended up being unable to update to Windows 10 until I moved the/my user profile folder back to C:.
And I'm pretty sure while researching the problem I found that moving the Users folder is officially not supported by Microsoft. (I'm not clear on whether they still support setting an alternate folder at installation time by tweaking the Windows setup scripts.)
<update>
There is a similar question with several good answers on SuperUser. One of the answers links to this post on LifeHacker which describes the RoboCopy procedure in detail ... I believe that's the longer write-up I looked at a few years ago.
</update>
Yes, you can, in Windows, change the default user profile for all new users to another path. For example: d:\users
I explain it in detail in this post (in Castilian -Spanish-):
https://www.sysadmit.com/2021/01/windows-perfiles-de-usuario-en-d.html
Of the three ways that I explain in the aforementioned post, the simplest is done during the installation of windows. Is this:
create in the root directory of the windows installation media the file:
Autounattend.xml
With this content:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FolderLocations>
<ProfilesDirectory>D:\Users</ProfilesDirectory>
</FolderLocations>
</component>
</settings>
</unattend>
Perform a new installation with that installation medium and you will get as a result that ALL user profiles and directories will be in
d:\users
instead of the usual
c:\users
Related
Is it possible for someone with Administrator access to easily create arbitrary files (e.g. text documents) within the C:\Inetpub\wwwroot folder under Windows 8.1?
Normally right-click presents me with many file types I can create; here, I'm only given the option to create a new sub-folder, even though I can (i) edit existing files there or (ii) create files elsewhere and move them there. (Also, gvim running with administrator access can't create a (new) swap file there).
I created a subfolder ("test"), and took ownership of it, but it made no difference. One of my colleagues thought that this was a "special case" overridden by IIS and could be configured by the Group Policy Editor somehow?
I've heard that disabling UAC solves the problem, but I don't want to do that!
Any ways round this? (Reference to an existing discussion I missed would be fine if it covers the same problem). Thanks!
Smychi
Solved this; I added the specific administrative user account I was logged in under ("User") to the list of permissions and granted myself "Full Control".
Not sure why this didn't already work with the existing groups settings, though I'll admit my knowledge of Windows permissions isn't as good as it should be.
Feel free to say whether this is a good or bad way to do it, or add any comment to this anyway, for my benefit or for others who might stumble across this.
Smychi
I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.
I want my installer to create a folder in C:\Users\Public\Documents that will be readable and writable to all local users. This includes the right to create files/dirs there, and to modify and delete all existing ones. The installer is being ran as Administrator.
I don't have to programatically set the permissions for my dir, right? Just by creating the dir, it will have the correct permissions I think.
I'm interested in the behavior under XP, Vista and 7.
Note: I'm not hardcoding the path C:\Users\Public\Documents, I'm querying CSIDL_COMMON_DOCUMENTS from the Win API, which can return different values depending on machine and OS. For example on XP it returns a different path.
Edit: here's a relevant discussion. It points to MS docs about the question, but it also looks like those docs may be wrong.
Yes, it inherits rights from the parent folder. Which has write permission for anybody in the INTERACTIVE group. Which includes any logged-in user account.
Use the Security tab in the shell's Properties dialog to review these settings.
I am working on a WinForm application, that allows working to work with "projects" (think about the application as Visual Studio, and projects as VS Solutions).
My question is - where should the application keep its logging files?
Some requirements include:
the application might not be running as an administrator (so saving in the %ProgramFiles% installation folder is not a good option)
The logs should be accessible to end-users (either for review, or for sending to the support team). (This means that hard to find folders, like %AppData%\Company\Application\Version\ProjectName... are not a good solution either)
The application might generate logs even when there are no open projects (so saving the logs in the project's folder is good only when there's a project, but not a final solution).
I was thinking of creating a "working folder" when the application is installed - something along the lines of C:\Application\, and then save the logs in a subfolder, like %WorkingFolder%\Logs\ProjectName
Thanks for the input.
Somewhere in the user's directory is actually the correct place to store them if they are specific to the current running user.
Some programs create folders at the top level of the User's directory, next to Documents and Desktop, others do it in Documents.
Creating it in C:\ might cause issues if the user doesn't have write access to the root directory. You can pretty much guarantee the user will have write access to the Home directory.
The other option is to look for an environment variable, and if its set use the value as the location, if not default to the User's home directory.
If the logs are user only you should store them at %AppData%\Company\Application Name.
If the logs are shared (any user can see any log) you should store them at:
%ProgramData%\Company\Application Name (for Vista+)
or
%AllUsersProfile%\Application Data\Company\Application Name (for XP-)
As for user access, you can add a shortcut to the start menu to the appropriate location or have a link within the program.
Another option in Vista+ is the Public folder (%Public%) which has links throughout Explorer for easy access to.
Where should I write program data instead of Program Files is a good blog entry by Chris Jackson from Microsoft. While it isn't an "official stance" it holds some excellent information.
You can always ask the user to configure this. Set a default path, maybe the application directory. During installation or while setting up the application you may prompt the user to input the path they want to use for logs. That's fair, right. If they're advanced enough to use logs they're good enough to configure a path too.
What do you plan to do with the logs. Are they technical, of for financial/security audits?
The EventLog is a nice place for technical logs, because you can access it remotely (within the Domain) and it is cleaned up automatically.
The %AppData% is also a good place for technical logs, specially if you are unable to connect to the eventlog. You can find the log files, and you can direct the end-user to them, but they are not "in the face" of the end-user. You can include a "send log to the maker" button to receive them.
For logs that needs be accessed by end-users, the My Documents (or a subfolder) looks good.
You can just to add button / menu item to easy open folder with logs.
Best place fo logs are %AppData%\AppName or %temp%\AppName.
Never use %MyDocs% or %Program Files%.
I'd suggest adding that question to the installer so that the user that installs the software can decide where best to put the logs. Though C:\[AppName\ sounds like a reasonable default for your requirements.
Edit: Just thought off, it would probably be worth warning the user if the select a bad location (in Program Files or in the root of the system drive etc) and if they choose to create a new directory, automatically give that directory correct permissions during the installation.
I think %APPDATA%\YourCompanyName\YourAppName is the preferred location. To overcome your stated objection of this location being hard to find, you could pretty easily and quickly implement a simple support screen in your app to allow the end user the ability to access and email these logs without too much trouble, so that the user will not have to remember or manually navigate to the long path name to get to the logs.
I don't really like the idea of the user being able to set this location via the installer because of possible naming and permission issues.
If the app needs to maintain the log only for the users current logged in timespan, then you could keep it in c:/temp.
Most of my winapps, i leave it there, so automatically it gets deleted once the user logs off..
Ofcourse, this primarily depends on your requirement.
First, some background:
Our product needs to integrate with the Lotus Notes client by adding or updating a line in the NOTES.INI file.
We don't have a problem if we're dealing with a single-user installation of Notes (i.e. if there are multiple Windows users on the machine, they'll all use the same Notes configuration). In this case, there's a single NOTES.INI file in the Notes installation directory.
However, under a multi-user installation of Notes (where each Windows user has their own Notes configuration), each user has their own NOTES.INI file stored in the user's LocalAppData directory - e.g. C:\Documents and Settings\Username\Local Settings\Application Data\Lotus\Notes.
So here's the problem:
If our product is being installed on a machine with a multi-user installation of the Notes client, we need to be able to update the NOTES.INI file in the profile of each user on that machine.
We can do this by having a program run when users log in, which checks whether that user's NOTES.INI file has been updated yet and if not, updates it. However, the uninstall process for our application needs to be able to reverse these modifications for all users on the machine.
Hence the question: assuming our code is running with local admin rights, is there some way that we can iterate through each user's profile and find their LocalAppData directory so we can make the necessary changes?
Any suggestions greatly appreciated :-)
EDIT 2009-03-25 16:52 GMT:
Looks like I have a possible approach (thanks Martin C):
For each subkey of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList:
If it's a "real" user (determined somehow):
Remember the subkey name - that's the user's SID
Read the ProfileImagePath value
If the user's Registry hive is not already loaded (i.e. there is no subkey of HKEY_USERS with the appropriate SID):
Enable the SE_BACKUP_NAME and SE_RESTORE_NAME privileges
Load the hive from ProfileImagePath\NtUser.dat using RegLoadKey
Try to find the user's LocalAppData folder using each of the following Registry keys in turn:
HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Expand environment variables in the resulting path if necessary (presumably just expanding %USERPROFILE% to the ProfileImagePath we got earlier)
Use the path to find the user's NOTES.INI file and make the appropriate changes
If we had to load the hive:
Unload the hive using RegUnLoadKey
I can probably get that coded up, but it seems a tiny bit fragile and there's potentially a number of ways it can go wrong.
Anyone have a more "official" approach?
You can enumerate the sub-keys of
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Each subkey contains the "ProfileImagePath", which will point to the base-path of the profile. Dependent on the OS-version and the language setting you can then determine the location of LocalAppData (beware, it is language-dependent!).
Edit: A possible starting point for going further could be
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Unfortunately this could vary from user to user and HKEY_USERS only contains the keys of users which have loaded profiles. You could try if you could load profiles somehow (maybe one can attach a user's registry somehow if it is not already loaded to HKEY_USERS?).