Warum das Leben nicht einfacher gestalten..? Nehmen wir doch mal folgende Fälle an:
- Man möchte die Datenbanken des Sharepoint Servern auf einen anderen Server umziehen ohne den aktuellen Server herunterzufahren.
oder
- Aus Gründen der “Hochverfügbarkeit” entschiedet man sich Datenbanken auf einen Server redundant (per Logshipping bspw) mitlaufen zu lassen. Fällt nun SQL Server 1 aus, soll SQL Server 2 rangehen.
Im Falle von Sharepoint würde man nun versuchen, vermutlich in der ZA, die Datenbankserver zu ändern. Oder man ändert im DNS Server die IP Adresse des SQL Servers, so dass nun der gleiche Name, aber eine andere IP Adresse, die des neuen SQL Servers, rangeht. Allerdings bringt diese zweite Lösung nichts, wenn man mit benannten Instanzen arbeitet und sich mehr oder weniger per Zufall der Port des SQL Servers geändert hat. DNS macht keine Port Aliase 
Aber warum auch so umständlich, wenn es auch leichter geht: mit SQL Alias.
SQL Allias
Ein SQL Alias ist die sehr sehr einfache Methode auf dem jeweiligen Betriebssystem speziell für SQL Server andere (virtuelle) Namen und Ports für SQL Instanzen bekannt zu geben. Die SQL Aliase gelten sofort .. ab Eintrag!
Beispiel: Man hat einen SQL Server SQL1 und zieht die Datenbanken auf SQL2 um. Als SQL Alias legt man einen SQL1 (Port 1433) ein und definiert aber , dass die tatsächliche Instanz der SQL2 auf 1433 ist. Sharepoint oder auch jede andere Software wird diese Settings auf der Stelle verwenden. Wie gehts?
SQL Alias mit SQL Konfigurationsmanager
Mit dem SQL Server wird auch der SQL Konfigurationsmanager mitgeliefert. In diesem kann man so wichtige Dinge wie Protokolle, Ports, Servicekonten usw einstellen… und eben auch SQL Alias:
Es gilt nur ein wenig aufzupassen. Je nach Clientsoftware (32 oder 64-bit) kann man die Aliase vergeben. Im besten Falle vergibt man halt Alias Bezeichnungen für beiden Bereichen. Dazu legt man per rechter Maus einen neuen Alias an, vergibt den
Aliasname: Name wie der SQL Server aufgerufen werden soll
Portnummer: Port der SQL Server Instanz (Std = 1433)
Server: Name des tatsächlichen Servers, auf dem die Instanz zu finden ist.
Ergebnis:
Problem
Sofern SQL Server oder die Tools dazu nicht auf dem Server installiert sind, haben wir kein SQL Server Konfigurationsmanager.!
Noch was.. der SQL Server Konfigurationsmanager macht das trennen von 32 und 64-bit vorbildlich. Wird später nochmal wichtig werden … Was aber, wenn man den SSCM nicht hat?
Für den Fall haben wir Cliconf.exe 
CLIFONFG.EXE
Cliconfg macht exakt dasselbe. Nur wo ist das..? Guggste für 32-bit unter c:Windowssystem32 und für 64-bit Clients unter c:WindowsSysWoW64.
Effektiv geben wir exakt die gleichen Informationen ein. Wir schalten zuerst das TCP/IP Protokoll frei, dann vergeben wir einen Alias und die entsprechenden Ports und tatsächlichen SQL Server Maschinen Namen (nicht die Instanznamen).
Achtung
Wie man allerdings sehr schnell bemerken wird, ist die Trennung zwischen 32 und 64bit hier nicht besonders gelungen. au Meinen Tests nach wird es genau verkehrt herum konfiguriert. So landet der 64.-bit Eintrag aus dem SysWOW64 als 32bit Alias..
REGISTRY
Letztendlich sind die Settings in Registry zu finden.
und ließen sich automatisiert verteilen, wenn man den entsprechenden Schlüssel exportiert und anschließend editiert:
Sharepoint
Wenn Sie sich also einen Gefallen tun wollen, dann verwenden Sie bereits bei der Konfiguration zu Beginn einen SQL Alias. Dann müssen Sie lediglich im Fall des Falles nur den tatsächlichen Server im Alias ändern. Sharepoint und jede andere Software wird das sofort mitmachen.
Falls Sie dies nicht getan haben, können Sie das dennoch auch nachträglich tun. Einfach als Alias den aktuell gültigen SQL Server als Alias eintragen und den neuen SQL Server als tatsächlichen Datenbankserver eintragen. Fertig…
Einfach und große Wirkung!
