A number of folks have fallen foul of the issue of display names being changed in Active Directory, and, following that, folks being unable to edit work items at all. So I thought I’d write a short piece explaining the problem, as well as pointing to a “retroactive” tool that folks can use to fix their work items.
The major scenarios are where a user’s display name is changed in Active Directory, or a user has been deleted from the system – common examples being:
1. A company decides to change the display name for the entire
2. An administrator changes the name of one user who gets married.
3. A user is deleted from the system, and still has work items assigned to them.
Team Foundation Server (TFS), via the Group Security Service, synchronizes the identities on to the server, getting the new display names. This information percolates its way through the various TFS systems, including into the Work Item Tracking system. The Work Item Tracking meta-data store is updated, so that when the Team Explorer client connects, the new display names are visible in the person field drop down pick-lists of the work item forms (for example in the Assigned To field).
However, there are three areas that are not automatically updated on a user display name change:
1. Old display names still show up in work items. The user data for the work items for the latest and historical revisions are not updated. This has the following effects that may prevent users from editing work items:
a. When a user looks at a work item, the person fields such as Assigned To still display the old display name.
b. Running any stored queries that query on a person will not return expected results
c. In some work item types, fields may have rules that make them read-only unless the work item state is being changed (for example Resolved By is only set/editable when state goes from Active -> Resolved). This means that this particular type of work item cannot even be edited (in Team Explorer or Excel), because the Resolved By field has an invalid value that cannot be changed.
d. Even if you do not run into these issues, doing a bulk edit in Excel to fix the problem may be painful (if there are a large number of users, work items and projects on your server), and will not be able to fix the Created By field or any historical data.
2. Work item subscriptions are also broken. Work-item changed event subscriptions (Project Alerts) contain a filter expression that checks the Assigned To field of a work item against a Display Name. This display name is not automatically updated as part of a Display Name change. Each user that has had their display name changed would have to manually unsubscribe and re-subscribe to get their project alert email notifications again.
3. Reporting on person fields may contain old display name values: The Team Foundation Server Reporting system recognizes values in known Agile and CMMI person fields as “person” values and maps them to SIDs (and hence these fields and reports built on these fields are unaffected by the Display Name change). However for any new custom person fields that have person names in them reports will contain old display names (and new ones as field values are updated). A new custom person field is a field that holds person data that is not defined in the Agile or CMMI templates.
If you experience any of the issues described above, then we have developed a tool that will be available shortly to help you address the first 2 problems to retroactively fix the data. It will not address the third problem since this problem is unlikely.
The tool basically bypasses the rules that prevent users from being able to update the work items containing old display name data, and allows the user to define which fields should be updated, and how display names are mapped from the old name to the new name. The tool will go about bulk updating current and historical data for all affected work items. Issue 1c above may also affect the ability to change a work item that has person fields assigned to a now deleted user. The tool will also address this problem, where in this case only the current state of the work items will be updated. The history is not changed. A new revision of the work item will be created for each field that is updated. This is to preserve the actual history of the item.
A KB article is now available http://support.microsoft.com/kb/932717, also describing this problem. If you run into this problem please contact CSS by calling 800/936-5800 if from US (see http://support.microsoft.com/ for calling from other countries).
We also realize that the retroactive fix is far from perfect. For a future release, we are looking to make a fix on the server to automatically (proactively) handle any display name changes that are made through Active Directory.
Please let me know if this helps.