Meine Kunden fangen so langsam an von alten SQL Server Versionen (2005, 2008, 2008R2) auf SQL Server 2014 zu migrieren.
Bisher habe ich keinerlei Probleme oder Auffälligkeiten bei der Installation bzw Migration gehabt, was wahrscheinlich daran liegt, dass wir (unsere Kunden) zu 99% neue Server bestellen und wir dort so zusagen “auf der grünen Wiese” installieren können.
Einer meiner Kunden wollte jetzt aber ein Inplace-Upgrade von SQL Server 2008R2 auf SQL Server 2014 durchgeführt haben…
das Handicap an diesem Inplace-Upgrade… der Kunde hat die komplette Projektleitung und Planung alleine durchgeführt und uns nur mit der Durchführung beauftragt:
- Inplace Upgrade des Betriebssystemes auf Windows 2012 R2 mit letztem Patch-Level
- Inplace Upgrade aller Komponenten des SQL Servers von 2008R2 auf SQL Server 2014 mit letztem Patch-Level
Mehr Angaben gab es nicht, keine Hinweise, keine weitere Dokumentation, keine weiteren Anforderungen.
Also gehen wir bei und machen genau das womit wir beauftragt wurden… schließlich erhalten wir auch nur dafür Geld bzw der Kunde wird sich schon was dabei gedacht haben.
Wir haben die Anforderung erfolgreich umgesetzt und dem Kunden mitgeteilt, dass wir sowohl OS als SQL-Migration erfolgreich durchgeführt haben. Der Kunde hat sich das System angesehen und getestet, dabei fielen dem Kunden auf, dass z.B. jetzt 2 SSIS-Services auf dem Server laufen (1x SSIS Version 10, 1x SSIS Version 12) und das er mit seinem bisher funktionierendem Account nicht mehr auf den SSIS Service zugreifen kann.
Da ich derjenige war, der das System Upgrade durchgeführt hatte, kam die Beschwerde auch bei mir an…
Da der Kunde keine weiteren Vorgaben gemacht hatte und die komplette Projekt-Dokumentation bei ihm lag, musste ich erst einmal meine Upgrade-Logs zu Rate ziehen. Während des Upgrade-Prozesses waren meine keine (relevanten) gelben oder roten Kreuze aufgefallen, alle Einzelschritte und Komponenten hatten einen grünen Haken, diese Aussage wurde durch die Analyse der Logs bestätigt.
Also musste es einen Grund geben, warum der Kunde keinen Zugriff auf den neuen (zweiten) SSIS Service hatte und warum gab es plötzlich zwei SSIS Services???
Dokumentation des Upgrade-Pfad für SQL Server 2014
Also habe ich einmal selber gelesen und siehe da… alles works as designed… kein Fehler sondern ein Feature 😉
Gemäß Microsoft Produkt Dokumentation ist dieses Verhalten gewollt und war zu erwarten.
Zum Upgrade von Integration Services schreibt Microsoft folgendes:
Wenn SQL Server 2005 Integration Services (SSIS) oder SQL Server 2008 Integration Services (SSIS) derzeit auf Ihrem Computer installiert ist, können Sie auf SQL Server 2014 Integration Services (SSIS) aktualisieren.
Wenn Sie einen Computer, auf dem eine dieser früheren Versionen von Integration Services installiert ist, auf SQL Server 2014 Integration Services (SSIS) aktualisieren, wird SQL Server 2014 Integration Services (SSIS) parallel zur früheren Version installiert.
Durch diese parallele Installation werden mehrere Versionen des Hilfsprogramms dtexec installiert.Um sicherzustellen, dass Sie die korrekte Version des Hilfsprogramms ausführen, führen Sie das Hilfsprogramm an der Eingabeaufforderung aus, indem Sie den vollständigen Pfad (:\Programme\Microsoft SQL Server\DTS\Binn) eingeben.Weitere Informationen zu dtexec finden Sie unter dtexec (Hilfsprogramm).
Hinweis:
In vorherigen Versionen von SQL Server hatten alle Benutzer in der Gruppe Benutzer standardmäßig Zugriff auf den Integration Services-Dienst, wenn SQL Server installiert wurde.Wenn Sie SQL Server 2014 installieren, haben Benutzer keinen Zugriff auf den Dienst Integration Services.Der Dienst ist standardmäßig sicher.Nach der Installation von SQL Server 2014 muss der SQL Server-Administrator das DCOM-Konfigurationstool (Dcomcnfg.exe) ausführen, um einzelnen Benutzern den Zugriff auf den Dienst Integration Services zu gewähren.Weitere Informationen finden Sie unter Gewähren von Berechtigungen an Integration Services-Dienst.
Es gehört also etwas mehr dazu, einen “alten” Integration Service upzugraden… das Lesen der Dokumentation lohnt sich auf jeden Fall.
Auch ich bin jetzt wieder ein wenig schlauer und werde beim nächsten Mal noch mehr nachfragen, ob der Inhalt der Beauftragung so wirklich gewollt ist, um solche “Kuriositäten” zu vermeiden.
Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.
