Relocation of the Users and the ProgramData directories to a drive other than the drive that has the Windows directory

This article describes the changes in policy for the relocation of the Users directory and the ProgramData directory to a drive other than the %systemdrive% drive in Windows operating systems.

Original product version: В Windows 10 — all editions, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 949977

Using the ProgramData setting to redirect folders to a drive other than the system volume will block your ability to upgrade to future versions of Windows.

By changing the default location of the user profile directories or program data folders to a volume other than the system volume, you cannot service your Windows installation. Any updates, fixes, or service packs cannot be applied to the installation. We recommend that you do not change the location of the user profile directories or program data folders.

Beginning with Windows 10, OS upgrades are supported even if user profiles are redirected to another drive. For example, if you are using Windows 8.1 with ProfilesDirectory set to D:\, you can upgrade to Windows 10.

More information

%systemdrive% is defined as the drive that contains the Windows directory. There are various reasons why you may want to relocate the Users directory or the ProgramData directory to other drives.

For Windows, the most common reasons are as follows:

• It is easier to back up data from a single drive and from a drive that contains only user files.
• It is easier to rebuild the operating system drive on a user’s computer if user data is located on a separate volume. In this case, the drive that contains the Windows directory can be formatted, and Windows can be reinstalled without having to worry about how to remove user data.

For Windows Server, the most common reason is as follows:

• There are performance improvements when you relocate the Users directory and the ProgramData directory to a drive other than the operating system drive.

For information about how to use the answer file setting, see Answer Files Overview.

If you use the FolderLocations unattend setting to move user data to a location other than the %systemdrive% drive, some servicing components may not be installed. These components may include critical updates, security updates, hotfixes, and service packs.

Information that is documented in the current release of the Windows AIK and the Windows OPK

The Windows Automated Installation Kit (AIK) and the Windows OEM Preinstallation Kit (OPK) for Windows and Windows Server contain documentation warnings that are related to the usage of the Profile Directory and ProgramData unattend settings. These are the settings that let you relocate the Users directory and the ProgramData directory to locations other than their default locations. This includes other drives.

These warnings were included before the servicing stack update (update 937287) was available. This update addresses the issue that is discussed in the warning text. Windows AIK and the Windows OPK documentation reads as follows. You cannot upgrade such installations to the next version of Windows.

Setting information from the Windows AIK and Windows OPK documentation:

The Profiles Directory setting

The Profiles Directory setting specifies the path of the user profile folder.

Use this setting to move the user profile folder (typically %SYSTEMDRIVE%\Users) to another location during Setup or Sysprep. The destination path can be on a volume other than the system drive, as long as it meets the following requirements:

• It must be on an NTFS volume.
• It must not be the path of another operating system user profile folder.
• It must not contain any serviceable components.

This setting can be used to keep system data separate from user data. If Windows is reinstalled on the system volume, a user who has administrative rights can manually recover data from this location.

Using ProfilesDirectory to redirect folders to a drive other than the system volume blocks upgrades. Using ProfilesDirectory to point to a directory that is not the system volume will block SKU upgrades and upgrades to future versions of Windows. For example, if you use Windows 8 together with ProfilesDirectory set to D:\, you cannot upgrade to Windows 8 Pro or to the next version of Windows. The servicing stack does not handle cross-volume transactions, and it blocks upgrades.

The ProgramData setting

The ProgramData setting specifies the path of the program data folder.

These settings should be used only in a test environment. By changing the default location of the user profile directories or program data folders to a volume other than the System volume, you cannot service your Windows installation. Any updates, fixes, or service packs cannot be applied to the installation. Microsoft recommends that you do not change the location of the user profile directories or program data folders. This is especially true for Microsoft Store apps. Changing the location of %programdata% will cause errors when you install, uninstall, or update these apps.

If you use the unattend settings to set up the operating systems that are listed in this article, we will provide commercially reasonable efforts to support your scenario.

Windows all users directory

Вопрос

Как получить доступ к desktop All Users на сервере Windows 2008 R2. Надо часто рваскидывать ярлыки для всех пользователей сразу на рабочий стол. Помогите плиз

Ответы

(не нужно «ломиться» туда, где закрыто :-)) не то что туда «нельзя», туда просто «не нужно!»)

Познакомьтесь с организацией личных папок в Win7 или WS2008R2. Там многие объекты представляют собой не папки, а junctions. (Поэтому в них пытаться «зайти» просто бессмысленно. )

Думаю, Вам нужна папка C:\Users\Default\Desktop — все новые пользователи будут «подхватывать» ярлыки оттуда.

Если нужно создавать ярлыки для уже существующих пользователей, то Ваш подход вообще неверный — нужно пользоваться Group Policy Preferences (очень удобно!)

(еще можно работать с папкой C:\Users\Public\Desktop. но это «чревато» — все добавления-удаления ярлыков будут сразу сказываться на всех локальных пользователях компьютера! легко удалить что-то нужное. )

What is the alternative for

I’m trying to use the command prompt to move some files, I am used to the linux terminal where I use

to specify the my home directory I’ve looked everywhere but I couldn’t seem to find it for windows command prompt ( Documents and Settings\[user] )

11 Answers 11

You’re going to be disappointed: %userprofile%

You can use other terminals, though. Powershell, which I believe you can get on XP and later (and comes preinstalled with Win7), allows you to use

for home directory.

You can %HOMEDRIVE%%HOMEPATH% for the drive + \docs settings\username or \users\username .

You can use %systemdrive%%homepath% environment variable to accomplish this.

The two command variables when concatenated gives you the desired user’s home directory path as below:

Running echo %systemdrive% on command prompt gives:

Running echo %homepath% on command prompt gives:

When used together it becomes:

Update — better version 18th July 2019.

Final summary, even though I’ve moved on to powershell for most windows console work anyway, but I decided to wrap this old cmd issue up, I had to get on a cmd console today, and the lack of this feature really struck me. This one finally works with spaces as well, where my previous answer would fail.

In addition, this one now is also able to use

as a prefix for other home sub-folders too, and it swaps forward-slashes to back-slashes as well. So here it is;

Step 1. Create these doskey macros, somewhere they get picked up every time cmd starts up.

Step 2. Create the cdtilde.bat file and put it somewhere in your PATH

Tested fine with;

Oh, also it allows lazy quoting, which I found useful, even when spaces are in the folder path names, since it wraps all of the arguments as if it was one long string. Which means just an initial quote also works, or completely without quotes also works.

All other stuff below may be ignored now, it is left for historical reasons — so I dont make the same mistakes again

old update 19th Oct 2018.
In case anyone else tried my approach, my original answer below didn’t handle spaces, eg, the following failed.

I think there must be a way to solve that. Will post again if I can improve my answer. (see above, I finally got it all working the way I wanted it to.)

My Original Answer, still needed work. 7th Oct 2018.
I was just trying to do it today, and I think I got it, this is what I think works well;

First, some doskey macros;

How to make a desktop shortcut available for all users in Windows 10

I windows 7 you create the shortcut in C:\Users\All Users\desktop

Well, that folder is not accessible.

So where should I put it in windows 10?

6 Answers 6

In Windows 10 Login as Administrator (Local Admin).

Go to Control Panel > File Explorer Options > click on the View tab > under Advanced settings: look for hidden files and folders > choose «Show hidden files, folders, and drives» and click «OK».

Go to C drive (C:) > Users > Public > Public Desktop

The «public desktop» folder is normally a hidden folder.

Now you can put your shortcuts in: C:\Users\Public\Desktop

Put it in this folder (exactly like below, with the % characters):

e.g. using this command:

This should be more reliable in case Users location is changed.

Bonus: other ways to open the public desktop in Explorer:

• you can paste %public%\Desktop in Explorer location bar
• or hit Win + R and enter %public%\Desktop

I don’t know if things have changed since the previous post, but.

I just checked my Windows 10 x64 Home (which I just did a clean install a couple of hours ago) and from an elevated («run as admin») command prompt, was able to copy a shortcut link from

and it did appear on my desktop! But, oddly enough, I cannot view a directory listing, or do any other type of function (like delete) in the «C:\Users\All users» directory.

Just thought I’d share that, in case there is some other reason/purpose behind it.

Active Directory Security Groups

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

This reference topic for the IT professional describes the default Active Directory security groups.

There are two forms of common security principals in ActiveВ Directory: user accounts and computer accounts. These accounts represent a physical entity (a person or a computer). User accounts can also be used as dedicated service accounts for some applications. Security groups are used to collect user accounts, computer accounts, and other groups into manageable units.

In the WindowsВ Server operating system, there are several built-in accounts and security groups that are preconfigured with the appropriate rights and permissions to perform specific tasks. For ActiveВ Directory, there are two types of administrative responsibilities:

Service administratorsВ В В Responsible for maintaining and delivering Active Directory Domain Services (ADВ DS), including managing domain controllers and configuring the ADВ DS.

Data administratorsВ В В Responsible for maintaining the data that is stored in ADВ DS and on domain member servers and workstations.

About Active Directory groups

Groups are used to collect user accounts, computer accounts, and other groups into manageable units. Working with groups instead of with individual users helps simplify network maintenance and administration.

There are two types of groups in ActiveВ Directory:

Distribution groups Used to create email distribution lists.

Security groups Used to assign permissions to shared resources.

Distribution groups

Distribution groups can be used only with email applications (such as Exchange Server) to send email to collections of users. Distribution groups are not security enabled, which means that they cannot be listed in discretionary access control lists (DACLs).

Security groups

Security groups can provide an efficient way to assign access to resources on your network. By using security groups, you can:

Assign user rights to security groups in ActiveВ Directory.

User rights are assigned to a security group to determine what members of that group can do within the scope of a domain or forest. User rights are automatically assigned to some security groups when Active Directory is installed to help administrators define a person’s administrative role in the domain.

For example, a user who is added to the Backup Operators group in ActiveВ Directory has the ability to back up and restore files and directories that are located on each domain controller in the domain. This is possible because, by default, the user rights Backup files and directories and Restore files and directories are automatically assigned to the Backup Operators group. Therefore, members of this group inherit the user rights that are assigned to that group.

You can use GroupВ Policy to assign user rights to security groups to delegate specific tasks. For more information about using Group Policy, see User Rights Assignment.

Assign permissions to security groups for resources.

Permissions are different than user rights. Permissions are assigned to the security group for the shared resource. Permissions determine who can access the resource and the level of access, such as Full Control. Some permissions that are set on domain objects are automatically assigned to allow various levels of access to default security groups, such as the Account Operators group or the Domain Admins group.

Security groups are listed in DACLs that define permissions on resources and objects. When assigning permissions for resources (file shares, printers, and so on), administrators should assign those permissions to a security group rather than to individual users. The permissions are assigned once to the group, instead of several times to each individual user. Each account that is added to a group receives the rights that are assigned to that group in ActiveВ Directory, and the user receives the permissions that are defined for that group.

Like distribution groups, security groups can be used as an email entity. Sending an email message to the group sends the message to all the members of the group.

Group scope

Groups are characterized by a scope that identifies the extent to which the group is applied in the domain tree or forest. The scope of the group defines where the group can be granted permissions. The following three group scopes are defined by ActiveВ Directory:

In addition to these three scopes, the default groups in the Builtin container have a group scope of Builtin Local. This group scope and group type cannot be changed.

The following table lists the three group scopes and more information about each scope for a security group.

Group scopes

Can Grant Permissions

Possible Member of

Accounts from any domain in the same forest

Global groups from any domain in the same forest

Other Universal groups from any domain in the same forest

Can be converted to Domain Local scope

Can be converted to Global scope if the group does not contain any other Universal groups

On any domain in the same forest or trusting forests

Other Universal groups in the same forest

Domain Local groups in the same forest or trusting forests

Local groups on computers in the same forest or trusting forests

Accounts from the same domain

Other Global groups from the same domain

Can be converted to Universal scope if the group is not a member of any other global group

On any domain in the same forest, or trusting domains or forests

Universal groups from any domain in the same forest

Other Global groups from the same domain

Domain Local groups from any domain in the same forest, or from any trusting domain

Accounts from any domain or any trusted domain

Global groups from any domain or any trusted domain

Universal groups from any domain in the same forest

Other Domain Local groups from the same domain

Accounts, Global groups, and Universal groups from other forests and from external domains

Can be converted to Universal scope if the group does not contain any other Domain Local groups

Within the same domain

Other Domain Local groups from the same domain

Local groups on computers in the same domain, excluding built-in groups that have well-known SIDs

Special identity groups

Special identities are generally referred to as groups. Special identity groups do not have specific memberships that can be modified, but they can represent different users at different times, depending on the circumstances. Some of these groups include Creator Owner, Batch, and Authenticated User.

For information about all the special identity groups, see Special Identities.

Default security groups

Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an ActiveВ Directory domain. You can use these predefined groups to help control access to shared resources and to delegate specific domain-wide administrative roles.

Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, such as logging on to a local system or backing up files and folders. For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers in the domain.

When you add a user to a group, the user receives all the user rights that are assigned to the group and all the permissions that are assigned to the group for any shared resources.

Default groups are located in the Builtin container and in the Users container in ActiveВ Directory Users and Computers. The Builtin container includes groups that are defined with the Domain Local scope. The Users includes contains groups that are defined with Global scope and groups that are defined with Domain Local scope. You can move groups that are located in these containers to other groups or organizational units (OU) within the domain, but you cannot move them to other domains.

Some of the administrative groups that are listed in this topic and all members of these groups are protected by a background process that periodically checks for and applies a specific security descriptor. This descriptor is a data structure that contains security information associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the administrative accounts or groups will be overwritten with the protected settings.

The security descriptor is present on the AdminSDHolder object. This means that if you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object so that it will be applied consistently. Be careful when you make these modifications because you are also changing the default settings that will be applied to all of your protected administrative accounts.

Active Directory default security groups by operating system version

The following tables provide descriptions of the default groups that are located in the Builtin and Users containers in each operating system.