Hello everyone,

From time to time we receive support inquiries about Offline File related problems. The symptoms range from clients which do not come online anymore, which cannot sync, which throw plenty of sync-errors or sync-conflicts up to paths that cannot be reached in SlowLink mode although there should be no offline files active on these paths.

These problems have one thing in common: the root cause can be found in the employed Offline File concepts and can only be solved through a new and sustainable concept for the deployment of Offline Files in that environment.

The migration from an old concept to a new concept often implies the usage of the FormatDatabase Registry Keys (http://support.microsoft.com/kb/942974/en-us) to clean up the faulty client configuration. Obviously this brings up questions regarding backup of the offline available data on the clients (that might not have synced for months), which usually lead to months long migration projects.

To avoid the lengthy migration, I want to help the Administrators to build sound Offline Files concepts, to enable them develop flexible plans.

The following are some key concepts in Offline Files.

The 5 ways of offline availability

There are 5 ways files/folders can get into the Offline Cache of the Client and a related scope and partnership will be created within Offline Files. We need to get administrative control over all of them and maintain them.

• Files made offline available automatically by Folder Redirection.

When configuring a Folder Redirection policy, an Offline Partnership will be automatically created for each redirected folder.

Through configuration of “Do not automatically make Redirected Folders available Offline“, this automatism can be disabled. See http://gpsearch.azurewebsites.net/#293

• Administrative assigned Offline Files

The admin can configure paths in a group policy that will be made available offline by the client. See http://gpsearch.azurewebsites.net/#2056

• User making content ‘always available’ by selecting this option in the context menu of a file/ folder

By default the user can decide what paths he/she wants to make offline available.

This can and should be disabled by the Policy “Remove Make Available Offline Command” in order to not get unforeseen partnerships e.g. on group drives. See: http://gpsearch.azurewebsites.net/#7857

• Caching settings of a share on a file server

For each CIFS share these settings are available:
“Only the files and programs that users specify are available offline” (basically: The Client can cache if it wants to) which is the default in Windows,
“No files and programs from the shared folder are available offline” (basically: No caching allowed here), and “All files and programs that users open from the shared folder are automatically available offline” (basically: The Client has to cache).

When the Client access a share that is configured to “The Client has to cache” the Client will create a sync partnership and will start to sync the files that have been opened to the client.

In that Regards the settings on the respective shares have to be checked / corrected.

•  LinkTargetCaching behavior when creating an .lnk file on an offline available path

Per default the target of .Ink Shortcuts will be made offline available if the .Ink file itself is made offline available.

A user could therefore unintentional create an Offline partnership against a group share if this target is on a share that isn’t yet offline available. This option is by default enabled to make sure that users have the expected files available when working with shortcuts. The drawback is that slow link policies will also apply to this new share and data that isn’t cached will not be available any more when the share transitions to slow connection.

This can be controlled by the LinkTargetCaching Registry Key:
http://support.microsoft.com/kb/817275/en-us

Permission on the file server structure

Because Offline Files also need to sync data from other (not currently logged on) users on the computer, the Offline File sync does not exclusively take place in the rights context of the logged on user. Thus, Offline Files require a set of minimum permissions to be able to sync (and in fact work) correctly. Not setting the permissions correctly on the file server will cause sync problems, can prevent the client from switching to online mode and a host of other problems (files created offline won’t sync back to the server).

The required minimum permissions for the share, the NTFS permissions of the shared folder and the permissions for each folder in the path are documented in: http://support.microsoft.com/kb/2512089/en-us.

Scopes andcachedfiles

Offline Files considers each share (\\Server\Share) as a scope. Each access to a network path will be checked against the list of scopes which Offline Files has partly or fully cached.

Note here that \\Server\Share is treated completely independently from \\Server.contoso.com\Share. As a result administrators must ensure that only the FQDN paths are used for drive mappings, redirections and DFSN paths.

If a match is found Offline files will be handling the request and among other things decide if the request should be satisfied from the Server (Online Mode) or from the local Cache (Offline mode).
Thus the Scope is the instance that decides if a paths is online or offline and it is always the complete share that is taken offline. That said, there are situations where only specific files are treated as offline for example when they are in a synchronization conflict. You can also configure a subset of a scope to be always offline and only synced during logon and logoff (this is called suspending and can be configured through http://gpsearch.azurewebsites.net/#2584).

If Offline Files treats a scope as offline, you can only use what is locally cached.
In Case you only made a subset of \\Server\Share available offline, you can only reach this subset of data in offline mode and you lose access to other branches that are not in the cache until you switch back to online mode. While offline greyed out icons identify data that is NOT cached but available as name in the Offline Files database only for consistency.

What part of a scope is offline available is very important to understand especially in case of DFS Namespaces in order to make meaningful decisions about how to design the directory structures on the server site.

It makes sense to host data that should be offline available in a different scope than the data that should not be offline available. Here it is common practice to host users offline available home shares in a separate DFS Namespace than not offline available Group shares.

Slowlink Mode and Background Sync.

With the policy “Configure slow-link mode” threshold values for latency and/or bandwidth can be defined. Those values can be applied to all (indicated by an ‘*’) or individual paths.

If for example the latency on the connection raises above the threshold value offline files will switch into offline state. See http://gpsearch.azurewebsites.net/#2093

When deploying Offline Files on DFS paths, it might make sense to defined very high latency values for the DFS-root so the root itself cannot switch to offline mode due to a slow link, but the deeper paths can. This is because the DFSN root share is treated by offline files in the same way as any other share that can go offline (slow connection).
For all the details see the blog of my colleague Ned Pyle:

http://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx

When the Client switches to offline (slow link) mode, the policy “configure background sync” governs if and how often the client will try to sync with the server which is important to still sync the data back to the server for backup and consistency:
See http://gpsearch.azurewebsites.net/#2095

It is not recommended to configure the background sync frequency to a very low value (minimum should be 30 minutes).

Migration of offline available data to other paths

Avoid this Scenario at all cost!

In http://support.microsoft.com/kb/977229/en-us two supported ways to migrate offline available data without reset of the client cache (and therefore resync) are described.
One way applies only to Offline Availability via Folder Redirection (automatic move done by the folder redirection service), the other to all other ways of Offline availability (manual by script).

Both ways have in common that you have to follow the KB Article to the letter if you want to have success and you must be up to date with all binaries on the client (see http://support.microsoft.com/kb/2820927).

As you can see from the first KB you have to follow a sequence of steps including Changes in AD/Fileserver/Infrastructure and on the Client.
From my experience this is seldom possible to do for a larger number of clients and it is very hard to automate.

Therefore the use of DFS for abstraction of logical paths and physical paths is strongly recommended.
In case you want to migrate offline available data on a DFS paths you just need to logoff the client, and change the paths the DFS Link is pointing to.

As the path used by offline files does not change, offline files won’t realize the migration as long as you preserved the filestate for example by using robocopy.

However when using Offline Files on DFS (or Roaming Profiles or DFSR) make sure you stay within the supported limits:

http://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx

Also note here that the path change from NetBios name to FQDN name is also a full blown move as Offline Files treats these 2 although ending up at the same data as different paths. Here the ‘Verify Old and New folder redirection targets‘ policy mentioned in 2820927 has to be set.

Configurations & scenarios that should be avoided

• Firstly the same set of data should not be made available offline in different ways!
  For example: Folder Redirection with offline availability on the path \\Server\Share\Username\MyDocuments, in addition administrative assigned Offline Files on the path \\Server\Share\Username Here the subfolder MyDocuments has been made available offline in two different ways. This nested offline availability is something offline files doesn’t cope well with in my experience.
   

• Another scenario is the use of several machines simultaneously by the same user.

  For example, a laptop with offline availability and a desktop machine without offline availability.
  In this scenario you have to ensure that the client using offline availability does not fall into offline mode for example due to SlowLink Mode. If it does, the user can inadvertently change a file on the server and in the local cache of the offline client, thus resulting in a sync conflict, the next time the laptop switches to online mode. The same is valid for data that is used by several users. These data are unfit to be used with Offline Files.

• Also, avoid redirecting the appdata directory. This can cause severe delays (depending on network performance) for applications on the client that expect that their data to be stored on a local disk!

I think it should be self-explanatory that before Offline Files are deployed to the clients, they should get the latest hotfixes for Offline Files (2820927), Fileservices (client and server 2899011) as well as the latest Security Updates installed. Furthermore a patch management is required to keep those components up to date.

On a related note, if you are planning for new client deployment, and exploring new solutions for user data offline access, I highly recommend you to look into the new feature “Work Folders” introduced in Windows Server 2012 R2 and Windows 8.1. To find more about the topic, see here https://technet.microsoft.com/en-us/library/dn265974.aspx.

I hope this helped you understanding offline files a bit better and enables you to build sound and solid concepts.

With best Regards
Hubert