There are many improvements in TFS 2010 when it comes to synchronization of groups and users with identity providers. They fall into 2 categories -

(i) implementing an extensible identity provider model which will be exploited in furture releases to support identity types such as Passport, and
(ii) robustness and scalability.

Identity sync runs as a core plug-in of the TFS Job Agent. The frequency of identity sync is determined by the schedule of this job. By default this is once an hour, on the hour. This is the recommended value and should be adequate in most cases. During every periodic sync run:

(i) membership of groups is brought up to date, and
(ii) detailed properties of a fraction of identities is refreshed.

With regard to the second aspect, the refresh cycle duration is 24 hours. That is, detailed properties of all identities will be refreshed once during that interval.

The default frequency can be changed either by modifying the job schedule in the TFS Configuration database (Interval column of tbl_JobSchedule), or by using the Job Service object model. The job id of the sync job is 544DD581-F72A-45A9-8DE0-8CD3A5F29DFE. It is not recommended that this frequency be increased drastically, as it will increase the burden on the server as well as on Active Directory. The refresh cycle duration is set in the TFS Registry in the Configuration database with the registry path \Service\Integration\Settings\IdentitySyncCycleDuration\. A related registry setting is \Service\Integration\Settings\IdentitySyncFull\. Setting this to the value True will cause the next sync to be a "full" sync, i.e. refresh detailed properties of all identities.

If an immediate refresh of a specific group or user is required, Identity Management Service provides the RefreshIdentity method. For a group, executing this method will force synchronization of the group and its direct members. For a user, properties will be refreshed.

Troubleshooting Identity synchronization issues

"User has been added to a group, but they do not have access to TFS".

In TFS there is an external identity sync process with the provider such as Active Directory, and an internal sync to Workitem Tracking (WIT). When troubleshooting user access problems which appear to be caused by identity synchronization, the first step is to determine which of the two sync processes seems broken. First of all, note that when a user is added directly to a TFS group, there is no further external sync required. It is only when the user is picked up by nested membership in a Windows group that external sync comes into play.

1. Verify that the Team Foundation job service is running.
2. Confirm the hourly event log entry for identity sync, and check for any errors logged.
3. Using the Group Membership UI, check drilling down to the affected user.

If the user is not found in the expected group, the following command can be used to directly query AD for that group's membership. It should be run from the TFS application tier from a command prompt that is running as the TFS service account.

dsquery group -samid <group> -d <domain> | dsget group -members

If dsquery returns the user, but TFS does not, then the external sync must be investigated. If the user appears in the Group Membership dialog, but not in the WIT Assigned To list, that would point to the internal sync.