TFS

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!

Ich habe lange überlegt, ob ich den Team Foundation Server auf die neue Version aktualisiere. Aufgrund meines vorläufigen Verbleibs bei Visual Studio 2008 R2 ist das Upgrade eigentlich nicht notwendig. Allerdings versprühen die geringeren Softwareanforderungen einen gewissen Charme. Für die Installation von TFS 2008 war eine Windows-Serverversion notwendig, dazu kamen noch ein SQL-Server mit Berichts- und Analysefunktion sowie SharePoint. Das SP1 ließ sich nur einspielen, wenn der TFS-Server an einen Domänencontroller angemeldet war, allerdings durfte er selbst nicht auf einem solchen installiert werden. Ich musste also temporär einen Domänencontroller in einer VM installieren und vor dem SP1-Update den Server in die Domäne einklinken. Nach dem Update konnte die Verbindung wieder gelöst werden. Einfach sieht anders aus.

TFS 2010 ist hier deutlich anspruchsloser. Er lässt sich auch auf einem Client-Betriebssystem installieren und begnügt sich mit der Express-Variante vom SQL Server. Diese wird auf Wunsch auch während der Einrichtung des TFS installiert, einfacher geht es nicht. Zudem reizte mich auch eine Aktualisierung des Betriebssystems auf Windows 7 oder Windows Server 2008 R2, die eine bessere Zusammenarbeit mit Windows 7-Clients versprechen. TFS 2008 läuft bei mir noch auf einem Windows Server 2003 R2.

Die Festplatte meines Servers enthält bereits zwei primäre Partitionen mit jeweils 30 GB, einer testweisen Aktualisierung stand also nichts im Weg. Nach der Sicherung der aktuellen TFS-Datenbanken mit DBSave wurde auf der freien Partition Windows Server 2008 R2 eingespielt, anschließend folgte noch der gerade veröffentlichte SQL Server 2008 R2 sowie der TFS 2010. Nach der Rücksicherung der Datenbanken wurde TFS 2010 mit Hilfe der Team Foundation-Administratorkonsole über die Upgradefunktion eingerichtet:

Berichtsfunktion und SharePoint habe ich deaktiviert, da die beiden Sachen in den letzten zwei Jahren kaum bzw. gar nicht benötigt wurden. Wer mag, der kann im achten Schritt noch den vorgegebenen Namen für die Standardkollektion ändern, dies ist später nicht mehr möglich.

Auf dem letzten Screenshot ist zu sehen, dass bei der Installation auch gleich der Webzugriff eingerichtet wurde. Dafür musste im TFS 2008 noch eine zusätzliche Software eingespielt werden.

Anwender von Visual Studio 2008 müssen nun noch das Update für die Aufwärtskompatibilität von Visual Studio Team System 2008 Service Pack 1 mit Team Foundation Server 2010 installieren. Beim Verbinden mit einem TFS 2010-Server muss im Verbindungsdialog die vollständige Adresse http://server:8080/tfs angegeben werden.

Ein kleines Problem hatte ich mit dem alten Arbeitsbereich, der zwar übernommen aber in Visual Studio 2008 nicht erkannt wurde. Löschen und Neuanlegen schafften Abhilfe. An dieser Stelle noch der Hinweis, dass man zur Sicherheit vor der Aktualisierung möglichst alle Dateien einchecken sollte.

Die Aktualisierung auf TFS 2008 SP1 wurde kurz vor Fertigstellung mit dem Fehler 1603 beendet. Beim Durchstöbern der Log-Dateien entdeckte ich folgende Zeilen:

Using workflow file from location exe.
Executing workflow ‚Unquiesce AT’…
Stopping Windows Service ‚W3SVC’…
Starting Windows Service ‚W3SVC’…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
System.InvalidOperationException: Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden. —> System.ComponentModel.Win32Exception: Der angegebene Dienst kann nicht gestartet werden. Er ist deaktiviert oder nicht mit aktivierten Ger„ten verbunden
   — Ende der internen Ausnahmestapelberwachung —

Nach diesen Zeilen startete dann das Rollback. 

Die Startprobleme mit TFSServerScheduler kenne ich schon seit der Installation des TFS. Dieser Dienst ist dafür verantwortlich, die Warehouse-Datenbanken zu aktualisieren, auf denen die verschiedenen generierten Reporte aufbauen. TFSServerScheduler ist abhängig vom Windows-Anmeldedienst (Netlogon), der sich nach dem Start auf normalen Servern und Arbeitsplatzrechnern aber gleich wieder beendet. Er ist der Meinung, dass seine Dienste nur beim Arbeiten in einer Domäne nötig sind. Um auf die Berichte nicht verzichten zu müssen, habe ich mir ein kleines Hilfsprogramm geschrieben. Dazu demnächst mehr.

Dummerweise lässt sich der TFS aber nicht direkt auf einem Domänencontroller (DC) installieren. Bis kurz vor der finalen Version von TFS 2005 war das wohl noch möglich, laut Berichten in diversen Foren soll das mit der nächsten Version (Rosario) auch wieder möglich sein. Allerdings habe ich keine Lust, mir bis dahin noch einen zweiten Server als DC einzurichten.

Das halb eingespielte Update hatte den TFS 2008 aber in einen undefinierten Status gebracht, Verbindungsversuche wurden mit folgendem Fehler abgelehnt:

TF31001: Team Foundation kann die Liste von Teamprojekten aus Team Foundation Server nicht abrufen. Team Foundation Server gab folgenden Fehler zurück: Fehler bei der Anforderung mit HTTP-Status 503: TF30059: Schwerwiegender Fehler beim Initialisieren des Webdiensts.

Was tun? Die Lösung bestand darin, auf meinem Entwicklungsrechner in einer VM einen Windows Server 2003 zu installieren und diesen als DC einzurichten. Nach dem Beitritt des Server zu dieser Domäne ließ sich auch der Windows-Anmeldedienst samt TFSServerScheduler starten und das Update lief fehlerfrei durch. Anschließend hat der Server die Domäne wieder verlassen und läuft nun wieder eigenständig.

Bin ich denn etwa der Einzige, der den TFS 2008 ohne Domäne betreibt?

Beim Versuch, eine Abfrage aus dem Team Explorer heraus mit Excel zu öffnen, erhielt ich anfangs die Fehlermeldung

—————————
Microsoft Visual Studio
—————————
TF80042: Das Dokument kann nicht geöffnet werden, weil Microsoft Excel 2003 oder höher oder eine der zugehörigen Komponenten nicht installiert ist. Weitere Informationen finden Sie im Team Foundation-Installationshandbuch.
—————————
OK  
—————————

Google brachte mich dann dazu, mit Hilfe des Office-Setupprogramms die Excel-Funktionalität .NET-Programmierunterstützung nachzuinstallieren. Diese Einstellung ist standardmäßig deaktiviert. Nun lassen sich die Abfragen auch in Excel anzeigen.

Beim Erstellen eines neuen Teamprojekts in TFS unter Verwendung von ‚MSF for Agile Software Development‘ werden automatisch 15 Arbeitsaufgaben (Work Items) erstellt, welche die grundlegenden Schritte auflisten (Zuordnung der Benutzer, Erstellung von Bereichen und Iterationen, …). Leider besteht im Team Explorer keine Möglichkeit, diese Aufgaben nach dem Schließen auch zu löschen. Löschen deshalb, weil sie für das eigentliche Projekt keine Relevanz mehr haben. Bei drei Teamprojekten sind es schon 45 überflüssige Aufgaben.

Abhilfe schaffen hier die Team Foundation Server Power Tools. Nach der Installation startet man die Eingabeaufforderung und wechselt in das Verzeichnis, in welches man die Power Tools installiert hat. Das Löschen von Arbeitsaufgaben geschieht mit dem Befehl

tfpt destroywi /server:SERVERNAME /workitemid:id1[,id2,...]

Beim ersten Projekt erhalten die automatisch erstellten Arbeitsaufgaben die IDs 1 bis 15, so dass der Löschbefehl

tfpt destroywi /server:SERVERNAME /workitemid:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

lautet. Aber Vorsicht, dass man nicht die falschen Aufgaben erwischt. Das Löschen ist nämlich nicht wieder rückgängig zu machen!

Nach der Installation von Team Explorer auf meinem Entwicklungsrechner tauchten plötzlich Anmeldeprobleme mit dem TFS auf. Die ersten Tests hatte ich aus einer VM heraus gemacht, diese liefen fehlerfrei ab. Obwohl das Benutzerkonto auf dem Server vorhanden und auch im TFS eingetragen war, bekam ich beim Anmelden den Fehler TF31003. Dieser besagt, dass mein Benutzerkonto nicht über die Berechtigung zum Verbindungsaufbau mit dem TFS verfügt. Zudem hatte ich Probleme, auf die SharePoint-Seite zuzugreifen. Der Internet Explorer zeigte folgende Fehlermeldung:

Sie haben nicht die erforderliche Berechtigung, um die Seite anzuzeigen
Sie verfügen nicht über die Berechtigung, dieses Verzeichnis oder diese Seite unter Verwendung der von Ihnen bereitgestellten Anmeldeinformationen anzuzeigen, weil Ihr Webbrowser ein WWW-Authenticate-Headerfeld sendet, das die Konfiguration des Webservers nicht akzeptieren kann.
——————————————————————————–

Versuchen Sie Folgendes:

Wenn Sie Ihrer Meinung nach in der Lage sein sollten, dieses Verzeichnis bzw. diese Seite anzuzeigen, wenden Sie sich an den Websiteadministrator.
Klicken Sie auf die Schaltfläche Aktualisieren, um es mit anderen Anmeldeinformationen erneut zu versuchen.
HTTP Error 401.2 – Unauthorized: Access is denied due to server configuration favoring an alternate authentication method. (HTTP-Fehler 401.2 – Nicht autorisiert: Der Zugriff wurde verweigert, weil die Serverkonfiguration eine andere Authentifizierungsmethode verlangt.)
Internetinformationsdienste (Internet Information Services oder IIS)

——————————————————————————–

Die Google-Empfehlungen bestanden darin, im IIS die anonyme Anmeldung zu deaktivieren. Aber das half leider auch nicht. Nach langem Hin- und Herprobieren fand ich dann heraus, dass der auf „Konfigurationsfrei“ eingestellte WebWasher die authorisierte Anmeldung stört bzw. nicht unterstützt. Nach der Umschaltung auf eine manuelle Konfiguration klappte dann sowohl die Anmeldung beim TFS als auch die Anzeige der SharePoint-Seiten.

Die Umstellung im WebWasher behob zudem noch ein anderes Problem. Seit dem Umstieg auf Vista hatte ich beim Download von Dateien per FTP immer beschädigte Dateien, was ich mir nie erklären konnte. Plötzlich klappt der Download wieder fehlerfrei. Irgendetwas scheint bei der konfigurationsfreien Einbindung von WebWasher unter Vista zu klemmen.