To compile and run, add references to Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.Common assemblies.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Framework.Client;
using Microsoft.TeamFoundation.Framework.Common;

namespace TFSGroupMembersFast
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Enter TFS server or project collection Url");
            Console.Write("e.g. https://localhost:8080/tfs/defaultcollection: ");
            string address = Console.ReadLine();
            Console.WriteLine();

            Console.WriteLine("Enter Team Project Uri for project scope, else empty string");
            Console.Write("e.g. vstfs:///Classification/TeamProject/****: ");
            string projectUri = Console.ReadLine();
            Console.WriteLine();

            DateTime startTime = DateTime.Now;

            TfsTeamProjectCollection tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(TfsTeamProjectCollection.GetFullyQualifiedUriForName(address));
            _ims = tfs.GetService<IIdentityManagementService>();

            if (string.IsNullOrEmpty(projectUri))
            {
                TeamFoundationIdentity group = _ims.ReadIdentity(GroupWellKnownDescriptors.EveryoneGroup, MembershipQuery.Direct, ReadIdentityOptions.None);
                m_identities[group.Descriptor] = group;
                m_groups.Add(group);

                // Get expanded membership of the Valid Users group, which is all identities in this host            
                group = _ims.ReadIdentity(GroupWellKnownDescriptors.EveryoneGroup, MembershipQuery.Expanded, ReadIdentityOptions.None);
                FetchIdentities(group.Members);
            }
            else
            {
                // Get all groups in this project
                TeamFoundationIdentity[] projectGroups = _ims.ListApplicationGroups(projectUri, ReadIdentityOptions.None);

                Dictionary<IdentityDescriptor, object> descSet = new Dictionary<IdentityDescriptor, object>(IdentityDescriptorComparer.Instance);

                foreach (TeamFoundationIdentity projectGroup in projectGroups)
                {
                    descSet[projectGroup.Descriptor] = projectGroup.Descriptor;
                }

                // Expanded membership of project groups
                projectGroups = _ims.ReadIdentities(descSet.Keys.ToArray(), MembershipQuery.Expanded, ReadIdentityOptions.None);

                // Collect all descriptors
                foreach (TeamFoundationIdentity projectGroup in projectGroups)
                {
                    foreach (IdentityDescriptor mem in projectGroup.Members)
                    {
                        descSet[mem] = mem;
                    }
                }

                FetchIdentities(descSet.Keys.ToArray());
            }

            // Now output groups and their members.
            foreach (TeamFoundationIdentity identity in m_groups)
            {
                Write(identity);
            }

            Console.WriteLine(String.Format("======= Finished reading {0} identities in {1} minutes",
                m_identities.Count, (DateTime.Now - startTime).TotalMinutes));

            Console.ReadLine();
        }

        static void FetchIdentities(IdentityDescriptor[] descriptors)
        {
            TeamFoundationIdentity[] identities;

            // If total membership exceeds batch size limit for Read, break it up
            int batchSizeLimit = 100000;

            if (descriptors.Length > batchSizeLimit)
            {
                int batchNum = 0;
                int remainder = descriptors.Length;
                IdentityDescriptor[] batchDescriptors = new IdentityDescriptor[batchSizeLimit];

                while (remainder > 0)
                {
                    int startAt = batchNum * batchSizeLimit;
                    int length = batchSizeLimit;
                    if (length > remainder)
                    {
                        length = remainder;
                        batchDescriptors = new IdentityDescriptor[length];
                    }

                    Array.Copy(descriptors, startAt, batchDescriptors, 0, length);
                    identities = _ims.ReadIdentities(batchDescriptors, MembershipQuery.Direct, ReadIdentityOptions.None);
                    SortIdentities(identities);
                    remainder -= length;
                }
            }
            else
            {
                identities = _ims.ReadIdentities(descriptors, MembershipQuery.Direct, ReadIdentityOptions.None);
                SortIdentities(identities);
            }
        }

        static void SortIdentities(TeamFoundationIdentity[] identities)
        {
            foreach (TeamFoundationIdentity identity in identities)
            {
                m_identities[identity.Descriptor] = identity;

                if (identity.IsContainer)
                {
                    m_groups.Add(identity);
                }
            }
        }

        static void Write(TeamFoundationIdentity group)
        {
            // Output this group's membership
            Console.WriteLine("Members of group: {0}", group.DisplayName);
            Console.WriteLine("=================");

            foreach (IdentityDescriptor memDesc in group.Members)
            {
                Console.WriteLine(m_identities[memDesc].DisplayName);
            }

            Console.WriteLine();
        }

        static Dictionary<IdentityDescriptor, TeamFoundationIdentity> m_identities =
            new Dictionary<IdentityDescriptor, TeamFoundationIdentity>(IdentityDescriptorComparer.Instance);
        static List<TeamFoundationIdentity> m_groups = new List<TeamFoundationIdentity>();

        static IIdentityManagementService _ims;
    }
}

1. Target account restriction - the target account of the mapping should not already exist in TFS. This is a key restriction of TFSConfig Identities , as well as the older TFSAdminUtil Sid. If the target account is somehow introduced, either by being granted permissions or by group membership sync, it cannot be undone. Simply "removing" the user from group(s) will not work. Removing identities in TFS simply marks the record as logically deleted, and does not physically delete because the identity may own TFS artifacts such as changesets or work items.
2. Batch versus individual mode - if account names are the same in both domains, the command can be run in batch mode. Otherwise identities can changed individually, specifying a different target account name.
3. Identity source - if the identity was directly added to a TFS group, running the Identity Change command is sufficient. For accounts which were picked up by TFS by syncing AD groups, the source of the data should also reflect the change.
4. Sync update - after running the identity change command, the next hourly sync will update all properties.

One scenario to which identity change is applicable is domain migration of account(s) in Active Directory. For this scenario, we have made an improvement in 2010 which makes it unnecessary to run identity change when the migration is to another domain within the same forest. Every identity in AD has a Guid in addition to the SID. In TFS 2010, we sync this AD Guid, and use it as the internal identity reference in TFS (TeamFoundationId). When an identity is domain migrated within the same AD forest, its SID changes but Guid remains the same. Hence TFS can automatically detect the SID change. This improves user experience because users will no longer get into the irredeemable state in which identity change does not work because the target account is already in TFS. Instead when the domain migrated account is added to TFS, its SID will automatically be updated.

Revert Behavior

There is a flip side to this to be aware. If identity change command is used to map unrelated accounts in the same AD environment, and if the old account is ever picked up again by TFS, then the identity change will revert back! It is easiest to explain this revert behavior by getting a bit technical. As stated above, every domain account in AD has a Guid, which is preserved during intra-forest AD migration. So let us say the following account is first added to TFS:

DomainA\foo, G1

with G1 being the Guid. This account is then “migrated” to "DomainB", and TFSConfig Identities is run, so this identity record in TFS becomes:

DomainB\foo, G1

If this was a true domain migration in AD within the same forest, this change will persist, because DomainA\foo is gone. But let us say that all that was done was to create a new account in DomainB, and DomainA\foo still exists in AD. Then if TFS ever encounters this account (for example, by group membership sync), then it will revert the identity row back to:

DomainA\foo, G1

This is the auto-Sid migration logic, which keys off of the identity Guid. Note that legitimate identity change, such as workgroup to domain account, or intra-forest AD migration, will never get reverted.

Some aspects of this topic have been discussed in the context of TFS Upgrade in Guidance for upgrading to TFS 2010 along with domain move.

(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.

The tricky aspect of the procedure is the correct sequence for changing identities to mapped users in the new domain. The Identities Change command in TFS 2010, as well as its equivalent in TFS 2008, have a key restriction that the target account cannot already exist in TFS. That is if you wish to change domainA\foo to domainB\foo, then the latter account cannot already exist in TFS when running the command. If the target account is somehow introduced, either by being granted permissions or by group membership sync, it cannot be undone. Simply "removing" the user from group(s) will not work. Removing identities in TFS simply marks the record as logically deleted, and does not physically delete because the identity may own TFS artifacts such as changesets or work items.

There a few different options to accomplish the goal of upgrading to TFS 2010 along with domain move. Our general recommendation is to perform one operation at a time. Thus you can:

1. Upgrade TFS 2008 to TFS 2010 in the original domain, followed by migration to new domain. You may follow the instructions at https://msdn.microsoft.com/en-us/library/ms404883(v=VS.100).aspx for moving the TFS 2010 server.
2. Migrate TFS 2008 to the new domain first, then upgrade to TFS 2010. The instructions for this can be found at https://msdn.microsoft.com/en-us/library/ms404883(v=VS.80).aspx.

Option 1 above is to be preferred because the identity change command in 2010 is more robust and flexible.

If neither of these procedures will work, however, you can follow this combined procedure.

i. Upgrade TFS 2008 to TFS 2010 in the new domain, but do not add any new domain accounts or groups to TFS yet.
ii. Change identities - refer Identities Change command.
iii. Add any AD groups from the new domain.

This will ensure that the new domain accounts are not introduced before running identities change for mapped accounts. The only exception is that a service account from the new domain has to be added to TFS during the upgrade, namely step (i) above. If you wish to domain migrate the old service account also, you will have to use a temporary service account for this step to circumvent this.

When using the identities change command, there are a few points to keep in mind.

• If account names are the same in both domains, the command can be run in batch mode. Otherwise they can be changed individually, specifying a different target account name.
• For accounts which were added to TFS by syncing AD groups, the source of the data should also reflect the change.
• After running the identities change command, you have to wait for the next hourly sync to update all properties.

Error TF50374 "Project group XXXX cannot be added to global group YYYY."

If you do, please read on for instructions to resolve the problem.

We have had a long standing restriction in TFS that global TFS groups (a.k.a server groups) cannot contain team project groups. The error that is the subject of this post indicates that the server that you are upgrading contains data that precedes this restriction. This post explains how to remove these membership(s) and upgrade successfully.

There is nothing in the product that requires this membership, and they are custom ones created by the customer. As a result of the membership, the project group will acquire permission(s) granted the parent global group. The reason why we don't automatically remove them during upgrade is so that they can be examined. If necessary any permissions can be granted directly to the project group(s), and then the memberships removed.

The recommended method is to use the UI or tfssecurity command line tool against the old server (if available still).

1. Get global TFS groups from UI (Team Explorer server -> Settings -> Group Membership).
2. Record permissions on these groups from Security dialog.
3. Examine membership of these groups. 
4. Remove team project groups that they contain.
5. Directly grant required permissions to those team project groups.

There are 3 standard server groups in TFS 2005 / 2008: "Team Foundation Administrators", "Service Accounts" and "Team Foundation Valid Users", and perhaps additional custom groups. The Valid Users group is a system managed umbrella group which we don't have to worry about. After removing any member(s) which are project groups, take a fresh back up of the TFS Integration database, restore onto the new server and run upgrade again (be sure to uninstall TFS2010 on the new server to remove the configuration and then re-run setup again and select the Upgrade Wizard to start the upgrade again).

If the old TFS server is no longer available/running, as in the case of an in-place upgrade, then please contact Microsoft Customer Support Services for a SQL script for removing the membership(s), reference article 2266305 (you may be asked to provide a credit card number depending on the type of support contract you have, but ultimately the support case will be free). After successfully running the script you can go to the TFS 2010 Administration console on the Application Tier, navigate to the Team Project Collection node and select the "retry" button to resume the upgrade.