How to redirect Documents and Desktop via GPO

Redirecting Documents and Desktop with Group Policy is one of those Windows administration tasks that looks simple on the surface but has several moving parts underneath. The visible action is just a GPO setting under Folder Redirection. The real system, however, includes user-scope policy processing, SMB share design, NTFS permissions, Offline Files behavior, policy removal behavior, and client logon timing. That is why a Folder Redirection deployment can either feel invisible to users or turn into a source of slow logons, access issues, and messy rollback work. Microsoft still documents Folder Redirection as a supported feature across current Windows Server and Windows client versions, and the policy path remains under User Configuration > Policies > Windows Settings > Folder Redirection in the Group Policy Management Editor.

At a first-principles level, the purpose of Folder Redirection is to change where Windows treats certain profile folders as living. Instead of C:\Users\<username>\Documents or C:\Users\<username>\Desktop being the effective storage location, the shell folder path points to another location, commonly a per-user folder on a file server. The goal is usually central storage, simpler backup, roaming user experience, or separation of user data from the local endpoint. Microsoft’s current guidance also ties Folder Redirection closely to deployment planning for Offline Files, share permissions, and policy scope, which tells you something important: Folder Redirection is not just a UI path change. It is a coordinated storage and policy design decision.

For this topic, the most practical shape is an implementation guide. A sysadmin using this on a second monitor usually needs four things fast: where the GPO setting lives, how to build the share correctly, which settings to choose, and how to change or undo it later without surprising users.

What Folder Redirection does and why the common explanation is incomplete

The common explanation is: “Folder Redirection moves Documents or Desktop to a network share.” That is directionally true, but incomplete.

What actually happens is that Windows applies a user policy that changes the location associated with known profile folders. If you also choose Move the contents to the new location, Windows tries to migrate existing data. If Offline Files is enabled or left at default behavior for clients, local caching enters the picture too. If the policy later changes or is removed, behavior depends on the Policy Removal option you selected earlier. Microsoft explicitly documents those settings because they change how predictable the user experience will be during rollout, changes, and rollback.

That matters operationally because admins often treat Folder Redirection like a single checkbox. In reality, it is a chain:

1. User falls into GPO scope.
2. User can read the GPO.
3. Client processes user policy at logon or refresh.
4. Client can reach the target UNC path.
5. Share and NTFS permissions allow folder creation and access.
6. Optional data move completes.
7. Offline Files and any other profile-management technology do not interfere.

When one of those breaks, “the GPO is applied” is not enough. The redirection can still fail, partially apply, or reverse.

Prerequisites before you redirect Documents and Desktop

Microsoft’s current documentation lists the core prerequisites clearly: you need an AD DS domain, domain-joined client computers, permissions to create and link GPOs, and a management system with Group Policy Management installed. There are no forest functional level or schema requirements just to configure basic Folder Redirection.

For a clean deployment, you also want these practical prerequisites in place:

• A dedicated file server or at least a dedicated share for redirected data.
• Stable name resolution and SMB connectivity from client computers to that file server.
• A security group for users who should receive the redirection policy.
• A decision on whether you want Offline Files behavior, especially for mobile users.
• A test OU or pilot group before broad rollout.

Microsoft’s deployment guidance adds several important field-reality caveats. If you use DFS Namespaces, Microsoft recommends a single target for the DFS folder to avoid conflicting edits. If you use DFS Replication, users should access only the source server to avoid conflicting edits. If the share is clustered, Microsoft recommends disabling continuous availability on the share because it can delay Offline Files transitioning to offline mode after connectivity loss. Those are not cosmetic details. They are the difference between a smooth deployment and a confusing user complaint about missing or stale files.

Where is the GPO Folder Redirection setting located?

This is one of the most common admin questions because people often search under Administrative Templates first.

The Folder Redirection policy itself is located here in the Group Policy Management Editor:

<GPO Name> > User Configuration > Policies > Windows Settings > Folder Redirection

That is the actual policy node where you right-click Desktop or Documents and configure redirection properties.

Some related Folder Redirection settings live elsewhere. For example, Microsoft documents policies such as Do not automatically make redirected folders available offline under:

User Configuration > Policies > Administrative Templates > System > Folder Redirection

So the clean mental model is:

• The redirection target is configured under Windows Settings > Folder Redirection
• Some supporting behavior is configured under Administrative Templates > System > Folder Redirection

Deployment steps for Documents and Desktop

This is the part that matters most in practice.

Step 1: create a security group for scope

Create a group such as Folder Redirection Users and add only the users you want to pilot or deploy to. Microsoft’s deployment guidance uses exactly this pattern and recommends removing broad application from Authenticated Users in the GPO security filter.

This gives you controlled rollout and easier rollback.

Step 2: create the file share correctly

Create a dedicated SMB share, for example:

\\fs1\Users$

Microsoft recommends hiding the share with a trailing dollar sign to reduce casual browsing. More importantly, Microsoft provides specific share/NTFS permission guidance for Folder Redirection. On a file server without Remote Desktop Services, the root should generally allow:

• SYSTEM: Full Control on this folder, subfolders, and files
• Administrators: Full Control on this folder only
• Creator/Owner: Full Control on subfolders and files only
• The Folder Redirection user group: permission to list, create folders, read attributes, read permissions, and traverse the root folder only

That design lets each user create their own folder beneath the root without granting broad access to other users’ data.

This is one of the most important underlying principles of Folder Redirection. You do not usually point every user directly at a common shared folder path with full rights. You point them at a root path and let Windows create a per-user folder underneath it.

Step 3: create and link the GPO

In Group Policy Management:

• Right-click the target domain or OU.
• Create a new GPO, for example Folder Redirection – Documents and Desktop.
• Link it to the OU containing the target users.
• Disable the link initially while you configure it, which Microsoft explicitly recommends in its deployment flow.

Step 4: set security filtering and delegated read correctly

A subtle but critical detail from Microsoft’s deployment guidance is that after removing Authenticated Users from Security Filtering and scoping the GPO to your Folder Redirection user group, you should still grant Authenticated Users delegated Read permission on the GPO because of the MS16-072 security changes. Microsoft notes that without this, the GPO may not apply to users, or previously applied settings may be removed and the folder can redirect back to the local PC.

That is the kind of implementation detail shallow summaries usually miss.

Step 5: configure Documents redirection

Edit the GPO and go to:

User Configuration > Policies > Windows Settings > Folder Redirection

Right-click Documents and open Properties.

Use these settings for the most common design:

• Setting: Basic – Redirect everyone’s folder to the same location
• Target folder location: Create a folder for each user under the root path
• Root Path: your share, for example \\fs1.corp.contoso.com\Users$

Microsoft’s documented example uses that same pattern. It is usually the safest and cleanest starting point because it gives each user a unique path rather than forcing multiple users into a shared explicit folder.

On the Settings tab, review these options carefully:

• Grant the user exclusive rights
• Move the contents of Documents to the new location
• Policy Removal

The right choices depend on your environment, but they should be deliberate.

Step 6: configure Desktop redirection

Repeat the same process for Desktop.

In most environments, Desktop and Documents are redirected the same way: same root path, same “create a folder for each user” model, same pilot scope, same validation process. Microsoft documents Desktop as one of the supported redirectable folders in current releases.

Step 7: enable the GPO and test with a pilot user

After configuration, enable the GPO link and test with one or two pilot accounts first. Microsoft’s documented validation step is simple and still the right one:

• Sign in as a pilot user
• Run gpupdate /force if needed
• Open File Explorer
• Right-click the redirected folder
• Check the Location tab and confirm the path is now the file share path rather than a local path

You should also validate that:

• the user can create and save files
• another user cannot browse that user’s redirected folder
• logon time is acceptable
• offline behavior is understood if laptops are involved

How do I redirect a folder?

In direct terms, you redirect a folder in GPO by opening the folder’s properties under User Configuration > Policies > Windows Settings > Folder Redirection, selecting either Basic or Advanced, and then defining the target location. Microsoft documents three common target approaches:

• Create a folder for each user under the root path
• Redirect to the following location
• Redirect to the local user profile location

For Documents and Desktop, the best default for domain users is usually:

• Basic – Redirect everyone’s folder to the same location
• Create a folder for each user under the root path

That keeps administration straightforward and avoids accidental multi-user sharing of one explicit path.

Basic vs Advanced redirection

Microsoft supports both Basic and Advanced folder redirection. Basic means all targeted users get the same root redirection model. Advanced lets you assign different locations based on security group membership.

Use Basic when:

• the storage design is the same for all users
• you want the least moving parts
• you are redirecting Documents and Desktop for a normal office population

Use Advanced when:

• different departments or user classes need different back-end storage
• you are segmenting data by security boundary or business unit
• you have a very deliberate design and can document it well

In practice, Basic is usually the better reference pattern unless there is a real business reason to split targets.

Settings that deserve extra caution

A Folder Redirection deployment often succeeds or fails on a few checkboxes.

Grant the user exclusive rights

Microsoft’s current troubleshooting guidance documents a case where Folder Redirection can fail with Event ID 101/1000 and a security-owner error when Grant the user exclusive rights is selected in a Basic configuration. Microsoft’s published resolution in that scenario is to clear that checkbox.

That does not mean the setting is always wrong. It means you should not treat it as harmless. In environments with delegated admin workflows, backup agents, file server management requirements, or inherited permission assumptions, exclusive rights can become the source of access or ownership problems.

Move the contents to the new location

This setting sounds convenient, and often it is. But Microsoft explicitly warns that moving all data can take significant time depending on data volume, connection speed, and whether both old and new locations are remote.

For users with large Desktops full of PSTs, ISOs, installers, or years of clutter, this can turn a simple first logon into a long wait. Pilot first.

Policy Removal

This setting determines what happens if the GPO no longer applies. Microsoft documents that you can choose behavior such as redirecting the folder back to the local profile location when policy is removed.

This is the answer behind another common question: How do I change Folder Redirection? You do not just edit the path and hope for the best. You must think through what should happen to existing files, where the user should land after the change, and whether you are migrating, reverting, or simply repointing.

How do I change Folder Redirection?

There are really three kinds of changes.

1. Change the target path but keep Folder Redirection

Example: move users from \\oldfs\users$ to \\newfs\users$.

In that case:

• update the target path in the folder properties
• decide whether to move contents
• pilot the change with a few users
• confirm SMB access and permissions on the new target before broad rollout
• validate after user logon that the Location tab shows the new path

This is not just a configuration change. It is a storage migration.

2. Change scope

Example: move from all users to a pilot group or exclude a department.

In that case:

• change security filtering or OU link scope
• keep Read delegation requirements in mind
• check GPO results for affected users
• be explicit about Policy Removal behavior for users who fall out of scope

3. Revert redirection back to local profile

This is the most sensitive case.

Microsoft supports setting the target back to Redirect to the local user profile location or using policy removal behavior that returns the folder locally. The important point is to plan the data path, not just the policy state. If users have years of documents on the server, “changing Folder Redirection” is also a data placement decision. Microsoft’s own policy removal options reflect this because reverting location and moving data are separate concerns.

Operationally, treat rollback like a migration:

• test with a pilot user
• verify where the live data is
• decide whether data should be copied back locally
• confirm the final shell path after policy update
• watch logon/logoff behavior and event logs

Common pitfalls and why they happen

The GPO looks applied but the folder does not redirect

Possible causes include:

• the user cannot read the GPO
• the user is not in the filtered group
• the file share path is unreachable
• the user can reach the share but cannot create their own folder
• another profile-management tool is interfering
• loopback processing or another GPO changes effective behavior

Microsoft also documents a loopback interaction where Folder Redirection settings can still be applied from Group Policy unless explicitly configured, which is a reminder that “not configured” and “disabled” do not always behave the way rushed troubleshooting assumes.

Folder creation fails with security or ownership errors

Microsoft has a current troubleshooting article for this exact pattern and points to the Grant the user exclusive rights option as the cause in that scenario.

Users complain about slow logons or delayed file access

This is usually not “because GPO is slow.” It is because the system is doing real work:

• creating redirected folders
• moving existing contents
• building Offline Files state
• waiting for network reachability to the target path

The causal mechanism matters. Once you understand that Folder Redirection is logon-sensitive storage redirection rather than a static registry tweak, the slow-logon symptom makes more sense.

A practical validation checklist

For a sysadmin reference, these are the validation points worth checking every time:

• User is in the intended security group
• GPO is linked to the correct OU containing the user
• User can read the GPO
• UNC path resolves and is reachable
• Share permissions allow folder creation beneath the root
• NTFS permissions match the intended Microsoft model
• Documents Location tab points to the share
• Desktop Location tab points to the share
• User can create a test file in both folders
• Another normal user cannot browse that user’s redirected folder
• Event Viewer shows no Folder Redirection errors
• gpupdate /force completes cleanly
• gpresult /h confirms the GPO scope and user-side processing

Final perspective

Folder Redirection exists to separate user data location from the local machine while keeping the shell experience intact. That is its purpose. But the reason experienced admins treat it carefully is that it sits at the intersection of Group Policy, SMB storage, profile behavior, and data migration. Microsoft’s current documentation still supports and documents it clearly, but the success of the deployment depends less on finding the policy node and more on designing the target share, permissions, scope, and removal behavior correctly.

For most environments, the durable pattern is straightforward:

• target Documents and Desktop first
• use a dedicated per-user share root
• use Basic redirection unless you truly need group-specific targets
• pilot before broad rollout
• choose Move contents and Policy Removal consciously
• validate with real user logons, not only GPMC screenshots