User Display Name Changes and New Attribute for Work Item Type Definitions in TFS 2010

If you’ve had the responsibility of administering a TFS 2005 or TFS 2008 server you may have run in the “Display Name” problem before.  In March 2007, the TFS Work Item Tracking team put a great post together about what’s exactly going on and it’s available here:

Basically, in TFS work item types, you can specify a field to hold the name of a user like in the Assigned To field.  The value that gets stored is basically just a string value of the person’s Display Name in Active Directory.  Not so bad except it’s not a strongly-typed object of a user but is just a string.  The problem comes when the user’s display name gets changed in Active Directory like when an employee gets married and take’s their spouse’s last name.  This causes a problem because all of the work items are still assigned to “Jane Doe” instead of “Jane NewLastName".  Even worse, “Jane Doe” is not even a valid user any longer so the work item becomes in an invalid state.  It’s kind of a maintenance nightmare.

Background:  Every hour an Active Directory synchronization job gets queued up and processes changes to Active Directory like new users, group membership changes, etc.  TFS keeps a cache of AD locally to help with operations across several subsystems.  For users, it caches certain information like the primary e-mail address, display name, domain/user name, SID, distinguished name, etc.

Thankfully there was something that helped us out available in the TFS Power Tools release called “TFS Users.”  You had to know about the display name change so working closely with your IT department was important.  Thankfully, it looks like TFS 2010 has added some abilities to notice those display name changes and proactively help you out within your system.  One of those changes is a new attribute in your work item type definitions that tells TFS which fields to automatically update.  I’ve bolded and underlined all of the changes from the previous default definition of the MSF Agile Bug.

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
  <HELPTEXT>The person currently working on this bug</HELPTEXT>
<FIELD name="Activated By" refname="Microsoft.VSTS.Common.ActivatedBy" type="String" syncnamechanges="true" reportable="dimension">
  <WHENNOTCHANGED field="System.State">
    <READONLY />
<FIELD name="Changed By" refname="System.ChangedBy" type="String" syncnamechanges="true" reportable="dimension">
<FIELD name="Closed By" refname="Microsoft.VSTS.Common.ClosedBy" type="String" syncnamechanges="true" reportable="dimension">
  <WHENNOTCHANGED field="System.State">
    <READONLY />
<FIELD name="Created By" refname="System.CreatedBy" type="String" syncnamechanges="true" reportable="dimension" />
<FIELD name="Authorized As" refname="System.AuthorizedAs" type="String" syncnamechanges="true" />
<FIELD name="Resolved By" refname="Microsoft.VSTS.Common.ResolvedBy" type="String" syncnamechanges="true" reportable="dimension"> <WHENNOTCHANGED field="System.State"> <ALLOWEXISTINGVALUE /> <READONLY /> </WHENNOTCHANGED> </FIELD>

If you have custom process templates or you have modified the out of the box process templates, you’ll have to do some maintenance to your existing team projects to light up the new TFS 2010 features available including the ability to automatically sync the name changes from Active Directory.  If you are using the MSF Agile template you will want to update the following fields:

  • Assigned To
  • Activated By
  • Changed By
  • Closed By
  • Created By
  • Authorized As
  • Resolved By

For all other process templates, you’ll want to update the work item types that have fields that hold display name values.  There is actually some great information already available about this particular topic available in the MSDN Library:

One of the other things we notice from the changes are the addition of the ALLOWEXISTINGVALUE rule to some of the fields.  This rule allows a previously entered value to still be valid even if that value is no longer a valid value.  In addition, there are also some state/transition rule changes for allowing the existing value.  Be sure to do a diff against your current work item type definition and the new MSF Agile work item type definitions to find all of the new changes.

For more information about managing work item type fields in TFS, see this MSDN Library Article:


Ed Blankenship

Tuesday, 08 June 2010 07:22:23 (Pacific Daylight Time, UTC-07:00)
This is very interesting but the old tfusers tool would still be useful. In our case, we coupled the TFS 2010 migration with a domain change. This means that all the old users have to be mapped in the migrated projects. Is there no tool for this?
Tuesday, 08 June 2010 07:28:29 (Pacific Daylight Time, UTC-07:00)

If you want to do both a domain move and an upgrade to TFS 2010, you'll want to follow Vasu's guidance available at his blog about this exact topic.

There isn't a standalone TFSUSERS utility any longer. The TFSConfig.exe Identities command has a lot of what used to be available. However, sequence of when you perform the steps is incredibly important. From what it sounds like, you are probably already too late. If you want to use the automated identities tool you may have to attempt the upgrade again using a TFS 2008 backup from before your upgrade to TFS 2010.
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

[Captcha]Enter the code shown (prevents robots):

Live Comment Preview