Mit der Aktualisierung von Team Foundation Server (TFS) 2008 auf 2010 im letzten Jahr war bei mir auch ein Wechsel des Server-Betriebssystems verbunden. Eine direkte Aktualisierung von 32-bit auf 64-bit ist nicht möglich, so blieb nur eine Neuinstallation. Bei dieser habe ich auch den Servernamen geändert.

Leider war mir damals nicht bewusst, dass man in diesem Fall mit TFSConfig Identities sofort nach der Installation auch die Identitäten in der TFS-Datenbank anpassen muss. Unterlässt man dies, dann leben die alten Benutzerzuordnungen weiter und es werden für den neuen Servernamen neue Zuordnungen angelegt. Die Auswirkungen zeigten sich dann gleich in den Arbeitsaufgaben (Work Items), bei denen aus dem Benutzer Sven der Benutzer SERVER-ALT\Sven wurde. Ein Speichern ist nur noch möglich, wenn die Arbeitsaufgabe dem neuen Benutzer zugeordnet wird, da SERVER-ALT\Sven keinen gültigen Benutzernamen mehr darstellt.

Nun ist es etwas mühselig, die Änderung des zugewiesenen Benutzers bei mehreren 100 Arbeitsaufgaben für jede Arbeitsaufgabe einzeln zu machen. Ein guter Helfer ist hier der angebotene Webzugriff über http://tfs-server:8080/tfs/web/ auf die Arbeitsaufgaben, mit dem sich Massenänderungen in einem Rutsch durchführen lassen.

Damit waren die größten Probleme des unterlassenen Identitätswechsel behoben. Der verbleibende Eintrag von SERVER-ALT\Sven für den Ersteller der Arbeitsaufgabe war nur ein Schönheitsfehler, an den man sich gewöhnen konnte bzw. musste, da dieser Wert schreibgeschützt ist und nicht geändert werden kann. Zum Problem wurde der Schönheitsfehler erst bei der Bearbeitung von Fehlern, die vor der Serverumstellung angelegt wurden. Beim Einchecken mit gleichzeitigem Abhaken der Arbeitsaufgabe kam die Fehlermeldung, dass einige Daten nicht gültig waren. Den Grund sieht man, wenn man in der Arbeitsaufgabe den Status von Aktiv auf Gelöst setzt. Dabei wird automatisch der Wert von Erstellt von (Created By) auf Zugewiesen an (Assigned To) übertragen. Aus dem Benutzer Sven wurde wieder SERVER-ALT\Sven, welcher das Speichern der Arbeitsaufgabe bei der Gültigkeitsprüfung verhindert.

Eine endgültige Lösung der Identitätsprobleme führt nur über einen manuellen Eingriff an der TFS-Datenbank. Die Benutzerdaten in den Arbeitsaufgaben werden in den Tabellen dbo.WorkItemsAre, dbo.WorkItemsWere und dbo.WorkItemsLatest gespeichert. Die für Erstellt von (Created By) zuständige Spalte trägt den Namen Fld33_Normalized. Die in den Tabellen abgelegte Kennung für den Benutzer bezieht sich auf die Tabelle dbo.Constants und verweist dort auf den entsprechenden Eintrag in der Spalte ConstID.

Die Aktualisierung der Benutzerkennung für Erstellt von (Created By) lässt sich mit einer einfachen SQL-Abfrage erledigen:

UPDATE [Tfs_Collection].[dbo].[WorkItemsAre]
SET [Fld33_Normalized] = 337
WHERE [Fld33_Normalized] = 2

UPDATE [Tfs_Collection].[dbo].[WorkItemsLatest]
SET [Fld33_Normalized] = 337
WHERE [Fld33_Normalized] = 2

UPDATE [Tfs_Collection].[dbo].[WorkItemsWere]
SET [Fld33_Normalized] = 337
WHERE [Fld33_Normalized] = 2

337 steht für die neue Kennung und 2 für die alte. Diese unterscheiden sich natürlich von Datenbank zu Datenbank. Der Datenbankname Tfs_Collection muss ebenfalls an das jeweilige System angepasst werden.

Bei dieser Gelegenheit kann man auch die Einträge von Geändert von (Changed By), Zugewiesen an (Assigned To), Aktiviert von (Activated By), Gelöst von (Resolved By) und Geschlossen von (Closed By) anpassen. Die entsprechenden Felder sind Fld9_Normalized, Fld24_Normalized, Fld10004Normalized, Fld10006_Normalized und Fld10009_Normalized. Das Feld PersonId scheint ebenfalls für die jeweilige Person zu stehen, dann auch hier wechselten die Kennungen mit dem Zeitpunkt der Umstellung. Damit wäre der der Identitätswechsel für die Arbeitsaufgaben schon erledigt. Sind mehrere Entwickler vorhanden, dann müssen die obigen Abläufe natürlich für jeden Entwickler durchgeführt werden.

Bleibt noch die Aktualisierung der Kennungen für die Quellcodeverwaltung und für die Bezeichnungen. Die entsprechenden Tabellen heißen dbo.tbl_ChangeSet und dbo.tbl_Label. Die hier verwendete Kennung unterscheiden sich aber von denen in den Arbeitsaufgaben, da sie einen kleinen Umweg über die dbo.tbl_Identity nimmt. Der Eintrag für den jeweiligen Benutzer in der Tabelle dbo.Contants enthält ein Feld TeamFoundationId, welches in dbo.tbl_Identity zur verwendeten Kennung in den beiden Tabellen führt. Die entsprechenden Anweisungen lauten:

UPDATE [Tfs_Collection].[dbo].[tbl_ChangeSet]
SET [CommitterId] = 26
WHERE [CommitterId] = 1

UPDATE [Tfs_Collection].[dbo].[tbl_ChangeSet]
SET [OwnerId] = 26
WHERE [OwnerId] = 1

UPDATE [Tfs_Collection].[dbo].[tbl_Label]
SET [OwnerId] = 26
WHERE [OwnerId] = 1

Damit sind innerhalb der Quellcodeverwaltung und bei den Arbeitsaufgaben alle Verweise von SERVER-ALT\Sven auf Sven geändert. Zu möglichen Änderungen in anderen Bereichen (Reporting, Build-Server, SharePoint) kann ich leider nichts sagen, da diese bei mir nicht im Einsatz sind.

Abschließend sei natürlich noch erwähnt, dass Änderungen an der TFS-Datenbank an den Verwaltungswerkzeugen vorbei nicht ungefährlich sind und nur unter größten Vorsichtsmaßnahmen durchgeführt werden sollten. Ein vorheriges Backup der Datenbank ist Pflicht!