Customer question came in today:

I am unable to add or remove accounts from the Service Accounts group after performing a domain move on TFS 2005 per the documentation.  One symptom is that the TFSSERVICE account from their old domain is still present in the Service Accounts group and we are unable to remove it or add in the new account.

When trying any commands against TFS using TfsSecurity we get the following error;

“Error: TF50605: There was an error looking up the SID for Service Accounts”

We have brought the old DCs for their old domain back online and we have confirmed that we can resolve the old accounts on the app tier by creating a new folder and trying to add the old TFSService account to ensure it would resolve properly and it did so. 

Sam Heald points out the The most fail-safe way to change TFS service accounts is through the TfsAdminUtil utility (ChangeAccount). The utility has a restriction that the new service account must not be known to the system (the settings from the old account transfer to the new account, they do not merge).

If you need to edit “Service Accounts” or any other TFS group through TfsSecurity.exe, it’s important that you scope the name appropriately, i.e. use “domain\user”, do not use “user”. If an account name is specified without scope, TFS will contact Active Directory first, then it’s own database second. In your example, when you specify “Service Accounts”, all domains in the forest will be contacted to determine if this name is known to them. If any domain controller is having problems processing that search criteria, the lookup will error  before the TFS database is examined. This problem can be easily avoided by specifying the domain scope, in this case “[SERVER]\Service Accounts”.

From the TfsSecurity help:

Identity Specifiers:

        n:<[domain\\]name> - the identity with the specified name.

            For Windows identities 'name' is the logon name. If 'domain' is

            omitted and GC is available the lookup operation will be performed

            by GC. If 'domain' is omitted and GC is not available the default

            domain context is assumed.

            Example:   n:ACME\\johndoe

                 or:   n:janedoe

            For application groups 'name' is the group display name and

            'domain' is the containing project's URI or name. If 'domain'

            is omitted and the 'name' cannot be resolved as a Windows

            identity, the global scope is used. If the name can be

            resolved as a Windows identity, you must specify a 'domain'

            of '[SERVER]' to resolve the naming conflict.

            Example:   n:"Full-time Employees"

                 or:   n:"[SERVER]\Full-time Employees"

                 or:   n:"[Team Project]\Vendors"

                 or:   n:"[vstfs:///Classification/TeamProject/00a10d23-7d45-4439-981b-d3b3e0b0b1ee]\Vendors"