User folders are associated with a sync share, and there are times you will need to move a user to different sync shares. For example, maybe the user changed jobs from HR to Finance, which has its own sync share. The process is pretty straightforward, by changing the user’s security memberships.

This blog post goes into the detail on how this works, as well as how to assign security groups to sync shares.

How users are given access to sync shares

Access to sync shares is managed by the assignment of users to a specific sync share. Typically, you assign one or more security groups to a sync share. As a result, the users that belong to the assigned security groups are allowed to sync to that particular share.

To assign security groups to a sync share, use the following cmdlet:

Set-SyncShare –name <sharename> -user <domain\SecurityGroupName>

You can also do so in the Work Folders page in Server Manager, by right-clicking the sync share, and then clicking Properties:

When you select a sync share in Server Manager, the Users tile shows all the users who belong to the assigned security group for that sync share. This provides an easy way to see all the users syncing to the share. You can right-click a user and then click Properties to find detailed information about a particular user.

Note We don’t recommend using built-in groups, such as “Domain Users”, for assigning users to sync shares due to the complexity it can create later if you want to move users to other sync shares. Additionally, the Server Manager Users tile won’t show users from built-in groups. You can do the assignment through Windows PowerShell, though once again, we don’t recommend it.

Moving users to a different sync share by assigning them to a different security group

When you need to move a user from one sync share to another (on the same server or on different servers), you can simply move the user to a different security group.

For example, let’s say that there are two sync shares on the server: Finance Share and HR Share. Each share is associated with a security group: Finance Users, and HR Users. A user (Amy) changes jobs from HR to Finance. You then update the group membership for Amy, moving her from HR Users to Finance Users.

Amy has already Work Folders configured on her devices. Without her doing anything, the next time any of her device syncs, the old sync share (HR Share) will reject the sync request because she’s no longer a member of the allowed security group. After the sync request is rejected, the client will go through the discovery process to find the new sync share – which is what we talk about next…

Discovery process

There are two main phases in discovery: Active Directory (AD) discovery, and local discovery.

AD discovery

AD discovery refers to the process of a sync server querying Active Directory to discover the sync server for a given user. The user attribute that stores the sync server for a user is called ms-ds-syncServerUrl. This blog post discusses the user attribute in details. If AD discovery fails, the local discovery will be performed on the server that handled the sync request. If AD discovery is successful, the local discovery will be performed on the server that is listed for the user in the ms-ds-syncServerUrl attribute.

Local discovery

Local discovery is about finding the correct sync share for a given user by checking to see on which sync share they have sync permissions. Here are the possible results:

• No match: There aren’t any sync shares on this server that user can sync. Local discovery will fail, and the user will be notified that they aren’t set up on the server to use Work Folders.
• One match: If one sync share is found for the given user, sync will be performed between the user’s devices and this sync share on the server.
• Multiple matches: This is an unsupported scenario, in which an administrator has mistakenly set up overlapping security groups for a given user. If this happens, Works Folders does its best to find a match. The goal is to find the existing user folder if possible:

• If there is already a user folder created for the user on a single sync share, Work Folders uses the sync share that contains the user folder.
• If there are no user folders for the user on any sync share, Work Folders picks one, and sticks with it for all future syncing.
• If there are user folders for the user on more than one sync share, there is no way for Work Folders to figure out which one is correct. In this case, it displays an error on the device, which administrator must correct.

Things that can delay discovery

Ideally, discovery happens as soon as group membership changes. In reality, there are some cases when discovery doesn’t happen immediately:

• Because of the AD discovery rely on the attribute stored in the AD, if the sync servers are communicating with different domain controllers, there could be delays because of the AD replication.
• If the authentication method is configured using ADFS, rediscovery will wait till the access token becomes invalid. The delay can be up to 15 minutes.
• If the device is a domain-joined machine, and the user logs on the device using their domain credentials, Work Folders will use a Kerberos token for authentication. The Kerberos token lifetime is configurable by domain admins, by default, it can be set to several hours. This page explains the details of how to configure Kerberos token polices.

Conclusion

AD discovery is useful when you have multiple sync servers - it makes it easy to move users to different sync shares on different sync servers without requiring them to do anything. The move occurs when the user’s device connects to the sync server. In Amy’s case, her device finds the new sync share seamlessly through discovery, letting her continue to sync her files without any hassles.