Folder Redirection (also known as FR or Feploy) is used to map folders in the user profile to other locations.
Folder Redirection is often used to reduce the size of a user roaming profile, or to facilitate backing up important user data and exclude noncritical parts. Sometimes, Folder Redirection is combined with Client-Side Caching (CSC) to make the files available locally on a mobile device when the user is traveling.
Folder Redirection currently implements the following Windows .ini files to store the settings:
- fdeploy.ini - Settings for Windows XP and earlier versions
- fdeploy1.ini - Settings for Windows Vista and later versions
When you usethe FDeploy Policy Editor, you may experience the following issues:
- Symptom 1: Opening policies and saving changes is slower than you expect.
Symptom 2: When you save a setting, you intermittently experience error 0x20 (32 decimal) and receive the following error message:
The process cannot access the file because it is being used by another process.
The change that you just made is lost. It is possible that the file is inconsistent. If you can't load the policy correctly, you may have to restore it from a backup.
Symptom 3: When you open the policy, you receive the following error message:
An unknown error occurred while data was gathered for this extension. Details: FRSettingRead failed with -2147467259
The file was written successfully on the last edit, but is now too big to be read into the editor. You need to restore it from backup to recover it.
Folder Redirection calls the following APIs to write the .ini file contents:
These APIs use a file name as a parameter. This implementation opens the file, makes the required modifications, and then closes the file. To swap out file contents, Folder Redirection must read significant parts of the file, and write more data than the actual change involves.
When a policy is added, the Folder Redirection Policy editor makes multiple calls to these APIs. The more settings that there are in the policy, the more data and sections the editor writes.
This causes the following problems:
- Each call to the Private Profile API causes multiple round trips to access, read, and write the file on the DCs SYSVOL share.
The latency and throughput of the network link may cause significant delays when you work with the policy editor. This is especially true if you access the .ini file remotely from a member computer by using the Remote Server Administration Tools (RSAT).
You should be able to see the delays in a network trace. Message Analyzer does a good job showing the overall delay of an SMB transaction. You may also see the operation execution time in a Process Monitor log.
- Each call to Write Private Profile API opens and closes the file. The system often contains components that process changes to a file when it is closed. Examples are file-based virus scanners, quota solutions. You might encounter this activity with DFS-R. Also, clients may access the files while the FDeploy Editor is saving the file.
If this secondary component opens the file in a sharing mode that is incompatible with the Private Profile API, you may receive a sharing violation error.
When you create a Process Monitor log entry of the behavior on the domain controller and filter for the Policy Folder GUID or "fdeploy1.ini" file name, you see the effective transactions. You should then see the Policy Editor write and close the file. Finally, before the editor reopens the file to make the next change, the secondary components open the file.
- The .ini file APIs have a built-in limitation of 32,767 characters per section on reads. For more information, see GetPrivateProfileSection. When you have many settings, you will reach this limitation in both file formats.
For more information, see the following Knowledge Base article:
2390986 Folder redirection fails in Windows 7 and in Windows Server 2008 R2 when you use a large Fdeploy1.ini file to configure the Folder Redirection policy
Also, Security Group Policy Editor (SCECLI, SCESRV) and the Scripts Policy both have very similar storage behavior and should also be affected by this problem. Both store their settings in a Domain Group Policy policy in GPTTMPL.INF or SCRIPTS.INI. This policy is read and written by using the same APIs.
To work around symptom 1, follow these steps:
- Use a workstation to run the Group Policy (GP) editing tools that are in the same site that you are targeting.
Note This should provide LAN-equivalent network speeds.
- Consider making this preferred domain controller the PDC.
To work around symptom 2, you can use the following methods:
- Designate a certain DC for GP editing. The Primary Domain Controller Emulator (PDC) is a good candidate.
- Move the domain controller to an AD site that has no clients. After you do this, concurrent client GP processing is unlikely.
- If you are using virus scanner or quota solutions, consider configuring it to ignore the "fdeploy*.ini" file pattern.
- Configure GPMC to use the PDC for editing.
- Use the existing GP policy that controls how GP Editor Extensions select a domain controller. Configure the policy to select the PDC.
- Be aware that AGPM will have its own DC selection. Generally, the AGPM client and server should be in the same site as the PDC.
To work around symptom 3, follow these steps:
Although this issue is addressed by hotfix 2390986, and this fix is included in Windows 8 and later Windows versions, you may still experience this limit when you define a redirection for many accounts in the advanced settings.
To work around this issue, reduce the number of account entries in policy, or the split the folder redirection policy settings into multiple group policies. Make sure that the total size of each policy file is smaller than 32,767 characters if the advanced settings for a certain folder are made for many groups or users.