Kategorie: TFS

Rund um den Team Foundation Server

TFS: Alle Jobs des SQL Agents für den TFS laufen nicht

Nach der Installation des TFS war im Event Log alle 10 Minuten der folgende Fehler zu lesen:

Ereignistyp:       Warnung
Ereignisquelle:    SQLSERVERAGENT
Ereigniskategorie: Job Engine
Ereigniskennung:   208
Datum:             12.09.2007
Zeit:              12:00:00
Benutzer:          Nicht zutreffend
Computer:          SVR-02
Beschreibung:
SQL Server Scheduled Job ‚TfsWorkItemTracking Process Identities Job‘ (0x152D401A0604DF4D984F5835301DA43F) – Status: Fehler – Invoked on: 2007-09-12 12:00:00 – Message: Auftragsfehler  Es kann nicht bestimmt werden, ob der Besitzer (‚Domäne\TFSSETUP‘) von Auftrag ‚TfsWorkItemTracking Process Identities Job‘ Serverzugriff aufweist. (Ursache: Die Informationen über Windows NT-Gruppe oder -Benutzer ‚Domäne\TFSSETUP‘ konnten nicht abgerufen werden, Fehlercode 0x5. [SQLSTATE 42000] (Fehler 15404)  Die Anweisung wurde beendet. [SQLSTATE 01000] (Fehler 3621)).

Der selbe Fehler wurde auch für alle anderen TFS Jobs angezeigt, die im SQL-Agent eingetragen wurden.
Ganz verstehen kann ich den Fehler bis heute noch nicht. Nicht wenige kämpfen mit diesem Problem, wenn man im Internet nach dem Fehler sucht. Direkte Lösungen dazu habe ich nicht gefunden.
Warum nicht korrekt geprüft werden kann, ob die entsprechenden Accounts in der Domäne sind oder nicht ist mir ein Rästel. Der Fehlercode 5 heißt: Zugriff verweigert.

Die Jobs wurden im SQL Server unter dem Benutzer Domäne\TFSSETUP eingetragen. Der entsprechende Benutzer TFSSETUP ist korrekt Mitglied der Domäne und auch Administrator auf der lokalen Maschine auf der sowohl TFS als auch MS-SQL Server 2005 läuft. Warum dieser Account genutzt wurde und nicht TFSSERVICE ist mir ein Rätsel.
OK, aber selbst wenn ich TFSSERVICE als Besitzer wähle funktionieren die Jobs nicht.

Nachdem ich die Jobs auf NT-AUTORITÄT\SYSTEM gesetzt habe ging es dann.
Verstehe wer will.

PS: Wer meint, dass es an dem Recht „Anmelden als Dienst“ liegt, der rät falsch. Der Account TFSSERVICE hat dieses Recht und damit hatte ich auch keinen Erfolg. 

PPS: Meine Installation ist gemischt und funktioniert aktuell ohne Probleme:
Windows 2003 R2 Deutsch
SQL Server 2005 Deutsch
TFS in Englisch
Nur als Anmerkung, da ich einem der letzten Kommentare noch die Absicht hatte, die Installation auf Englisch Pur umzustellen.

Meine erste produktive Team-Foundation-Server Installation

Bisher hatte ich mit dem Team Foundation Server (TFS) nur in Virtuellen Maschinen herumgespielt. Nun ging es daran einen eigenen produktiven TFS zu installieren. Wir entschieden uns für eine Single Server Installation.
Aus meinen bisherigen Erfahrungen aus der „Spielwiese“ und mit den Beta-Versionen wusste ich schon, dass man sich strengstens an die Installationsanweisungen halten sollte. Das ist auch schon in anderen Blogs und Artikeln beschrieben worden und ich kann das nur noch mal bestätigen.
Das sicherste ist, dass man sich die 12 Seiten für die Installationshinweise aus der TFSInst.chm komplett ausdruckt und wirklich Schritt für Schritt durchgeht.

Hier die Kurzfassung der Installationsfolge wie es bei mir (halbwegs) nahtlos klappte.

  • Neue Windows Server 2003 R2 Installation (Deutsch)
  • 1000mal Windows Update durchführen
  • In der Domäne wurden 4 neue User angelegt TFSSETUP, TFSSERVICE, TFSREPORTS, TFSPROXY. Die entsprechenden Accounts wurden der lokalen Administratoren Gruppe hinzugefügt. (Theoretisch gehen hier auch andere Namen).
  • Installation des IIS (ohne Frontpage Extensions, die der TFS nicht mag)
  • Microsoft SQL 2005 Setup durchführen. Hier habe ich den Weg der Answer-Datei gewählt, SQL2005ForATDT.ini.
    ❗ Achtung:  Diese Datei muss man jedoch ändern, wenn die Deutsche SQL 2005 Version installiert wird. Die Accountnamen „NT AUTHORITY\SYSTEM“ muss man ändern in „NT-AUTORITÄT\NETZWERKDIENST“ , da die INI Datei mal wieder nur für US-Versionen gebaut wurde. Zu finden ist diese Info hier: http://technet.microsoft.com/de-de/library/ms143504.aspx
    Unterlässt man diese Änderung erhält man bei der Installation des SQL-Servers diese kryptische Fehlermeldung:
    „Die Dienstkonten konnten vom SQL Server-Setup nicht überprüft werden. Entweder wurden nicht für alle installierten Dienste Dienstkonten angegeben, oder der angegebene Benutzername oder das angegebene Kennwort ist ungültig. Geben Sie für jeden Dienst einen gültigen Benutzernamen, ein gültiges Kennwort und eine gültige Domäne an, oder geben Sie ein integriertes Systemkonto an.“
  • Installation der Share Point Services 2.0. Aber nicht aus der Server Verwaltung, diese Version würde die MSDE mit installieren.
    Am Besten man lädt sich die neuste Version herunter und führt auch hier einen Silent-Install aus mit:
    stsv2.exe /C:“setupsts.exe /remoteSql=yes /provision=no /q“
    http://www.microsoft.com/downloads/details.aspx?familyid=B922B28D-806A-427B-A4C5-AB0F1AA0F7F9
  • Anschließend die englischen Sprachdateien für  die Sharepoint Services heruntrladen und installieren.
    http://www.microsoft.com/downloads/details.aspx?familyid=e7eec77d-4365-4b66-8e8d-9d079c509679
  • Noch mal nach aktuellen Updates bei Microsoft suchen.
    Allerdings war ich gezwungen das SP2 für den MS-SQL Server 2005 manuell zu installieren.

Puh… geschafft! 🙂
Jetzt geht es erst mit der eigentlichen Installation los und sie sollte durchlaufen…

Was man beim Umstieg von VSS auf TFS bedenken muss!

Ich plane in der nächsten Zeit Visual Source Safe (VSS) abzulösen. Da wir alle Hauptprojekte (bis auf einigen legacy Kram) auf VC++ 2005 bearbeiten und die entsprechenden Visual Studio Team System Lizenzen haben beabsichtigen wir auch den Team Foundation Server (TFS) einzusetzen.
Einen Team Foundation Server kaufen müssen wir auch nicht, denn wir haben nicht mehr als 5 Clients.

Vorteile:

  • Integration auch in ältere Systeme ist kein Problem! Für VC6, VB6, VS.NET 2003 gibt es entsprechende Plug-Ins! Das ist schon mal genial. Also können wir theoretisch sogar alle legacy Projekte konvertieren und mit den alten Tools weiterarbeiten.
  • Alles wird in einem SQL-Server gehalten. Endlich!
  • Die Projekt Dokumente sind gleich in dem entsprechenden Share Point mit gehalten (leider noch WSS 2.0)
  • Einchecken mehrere Dateien werden direkt zu einem Vorgang zusammengefasst.
  • Direktes Bug-Tracking und einfache Projektierung ist möglich ohne externe Hilfsmittel.

Beim evaluieren der Features habe ich mir schon die Hände gerieben. Allerdings gibt es da eine wirkliche fette Kröte die ich schlucken muss. Mein geliebtes „Sharing“ unter VSS gibt es unter dem Source Control System von TFS nicht ❗

Wir haben einiges an gemeinsamen Code, den wir nicht in Libraries oder DLLs zusammengefasst haben. Da sind einige nette Template Klassen etc., spezielle Header und andere nette Code-Snipplets. Alle diese Code Teile waren in einem kleinen Projekt zusammengefasst und jeder Entwickler konnte diese wahlfrei in sein Projekt sharen. Das ist und war extrem bequem. Mit dem Drawback, dass eine zentrale Code Änderung alle Projekte beeinflusst und evtl. bricht kann man leben.
Man muss einfach regelmäßig Ohrfeigen verteilen für Entwickler die nicht testen und Kerker bei Brot und Wasser androhen… 😉

Unter TFS ist es damit vorbei. Einziger Ausweg wie ich ihn aktuell sehe ist es, die entsprechenden Codeteile einzubranchen in die anderen Projkete. D.h. aber das man die aktuelle Version (und den evtl. gewünschten Fix) nur mit einem Merge bekommt, was wieder nicht unbedingt automatisch geht, man muss also Hand anlegen was man evtl. eben auch vergisst.

Mal sehen vielleicht fällt mir da noch was anderes ein. Anonsten sieht das ganze sehr vielversprechend aus.