If you wait, TFS will pick up the change.

TFS does query the Windows Security system when starting up, but that is not the only time that it is done. There are two ways that a refresh is triggered. The first is whenever a change happens to group membership through the TFS Group Security Service (GSS) interfaces (add/delete users/groups). In this case, TFS has a direct signal that a refresh is required and so kicks off processing immediately. When users are added outside of TFS, as they are in Active Directory or local Windows groups, the change is picked up by a synchronization process that runs on a schedule. The default processing interval is 1 hour. The frequency of the update can be changed by adding a TimeSpan string to the TFS Services web.config to override the default IdentityUpdatePeriod of "1:0:0".

A cheap way of forcing an update if you do not want to wait for the default processing interval to expire would be to create a new TFS group and then delete it, or perform some other TFS-visible operation on groups.

Thanks, Bill.

Why did you choose this architecture? Why does TFS keep its own copy of the Windows Users/Groups? I suppose it's a performance decision not to delegate the authentication to Windows every time.

OK. Thanks for your replies.

I am having the same issue and the ONLY way to resolve this is to remove and re-add the AD group.

Can somebody please let me know how i can verify that the sync process is running every 1 hour and how i can update that do something like 15 minutes?

I think that entry should be in C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\web.config, but i am not seeing it. I am also seeing some exceptions in the eventlog that look like we are have sync issues.

HELP!

Geno

You can determine the last time that group membership information was changed as follows:

1. Open IE on the TFS AT and browse to http://<server>:8080/services/v1.0/serverstatus.asmx
2. Invoke the GetServerStatus method

The LastIdentityChanged timestamp will tell you the last time that a user was added to the system - either directly or through synchronization with AD.

You are right... the IdentityUpdatePeriod key needs to be added to the services\web.config file. It is not there by default so you will have to introduce the key into appSettings.

Are you sure of "IdentityUpdatePeriod" and its format? Google this keyword and "this thread" is the only place on the net were it is mentioned.

I have a sandbox TFS and added the following:

<appSettings>

<add key="IdentityUpdatePeriod" value="0:1:0"/>

By Checking http://localhost:8080/services/v1.0/serverstatus.asmx/GetServerStatus

My response shows:

<ArrayOfDataChanged ...>
- <DataChanged>
<DataType>LastAclChange</DataType>
<LastModified>2006-08-08T20:32:28.487</LastModified>
</DataChanged>
- <DataChanged>
<DataType>LastIdentityChange</DataType>
<LastModified>2006-08-08T19:04:25.7</LastModified>
</DataChanged>
</ArrayOfDataChanged>

It did not change after many minutes. After making a AD Group change and making sure it had replicated, I added a User to a TFS group. The GetServerStatus then showed:

<ArrayOfDataChanged ...>
- <DataChanged>
<DataType>LastAclChange</DataType>
<LastModified>2006-08-08T21:20:22.217</LastModified>
</DataChanged>
- <DataChanged>
<DataType>LastIdentityChange</DataType>
<LastModified>2006-08-08T19:04:25.7</LastModified>
</DataChanged>
</ArrayOfDataChanged>

NOTE! It's the LastAclChange value that changed. Examining the properties of the AD Group from within TFS showed that TFS had not updated the member list.

Removing THIS group and adding it back caused its membership to be updated. During all of this, LastIdentityChange remained the same.

I have no idea how long it takes to propagate a change on its own. If I get any more info I'll post it.

As of now, this means we must manually remove and add Groups in TFS as a part of our AD group management... I'd rather not.

Cash

I'm seeing similar behavior as cashfoley. If anyone can provide further information on whether this thread has solved the problem or not, I'd greatly appreciate it. Details would be even better.

Thx,

Ricky

It's strange to type, but the "IdentityUpdatePeriod" will not affect the 2nd sync with Active Directory. The 1st sync is triggered immediately after the application starts. The IdentityUpdatePeriod will affect when the timer wakes up, but not when it starts(which triggers the 2nd sync). You can set the timer start by setting the "IdentityUpdateInitial" app key.

<add key="IdentityUpdateInitial" value="0:1:0"/>

LastIdentityChange did not work in V1 and has subsequently been removed. It will only report when TFS Application groups are created, deleted, or renamed.

You can look up the last identity changes from the database directly as a workaround (this will return the top 10):

select top 10 last_update, display_name, domain, account_name

from TfsIntegration.dbo.tbl_security_identity_cache

order by last_update desc

Thanks Sam (and Bill),

I know I can figure it out by trial and error, but the value of "0:1:0" is one minute?

Seeing how if you Google "IdentityUpdateInitial", this thread is the only place it is mentioned on the net! We might as well have good documentation. ;)

Cash