SQL Server Express verrichtet sehr gute Dienste. Seit es den kleinen Bruder des SQL Express mit Advanced Features gibt, stehen nicht nur das SQL Server Management Studio für die Verwaltung der Datenbanken bereit, sondern auch das Business Intelligence Development Studio, um bspw. Berichte für Reporting Services zu  entwickeln. Aber Gerüchten zu Folge, sei der SQL Server Express (SSE) nur für lokalen Installationen verfügbar. Das wäre ja fast so, als würde man sich in sein Auto setzten und das Garagentor geschlossen halten. Mit einer Kapazität von 4 GB pro Datenbank läßt sich deutlich mehr anstellen, als eine simple Videosammlung zu archivieren. Die entscheidende Frage ist also:  Kann der SSE wirklich nicht  remote verwendet werden? Die Antwort sei hier schon gegeben: Das kommt darauf an! Warum es sich hier eine relativ unklare Antwort gibt, soll eine Versuchsreihe Aufschluss geben.

Das Experiment beginnt – Standardinstallation

Wir lassen das Experiment in der Stunde Null beginnen und installieren den SSE mit den Standardeinstellungen. Von einem weiteren PC aus werden wir über das SQL Server Management Studio versuchen ein Verbindung herzustellen. Der erste Verbindungsversuch erweist sich als vernichtend. Tatsächlich bleiben unsere Anfragen an den SSE  gänzlich unbeantwortet. Aber so schnell wird die Flinte nicht in das Korn geworfen und wir versuchen es mit der Ursachenforschung. Der erster Gedanke gilt der Netzverbindung. Und tatsächlich! Die Firewall ist aktiv und vermutlich wird jeglicher Zugriff auf den SSE unterbunden.



Doch auch das kurzfristige Deaktivieren der Firewall erweist sich als Fehlschlag.  Wenn also die Firewall nicht der Schuldige ist, bleibt nur noch der SSE selber. In der Grundinstallation wird ein Werkzeug – der Konfigurationsmanager – mitgeliefert, in dem wir tatsächlich fündig werden.

Bei unserer Instanz des SSE ist das TCP/IP Protokoll auf „disabled“ eingestellt.  Wenn also hier das TCP/IP Protokoll aktiviert werden kann, dann sollte doch auch der remote Zugriff funktionieren. Ein Test – die Firewall wurde deaktiviert – bestätigt unsere Vermutung.  Das erste Fazit lautet folglich: SSE kann remote verwendet werden!

Nun wissen wir, dass lt. IANA der Microsoft SQL Server standardmäßig auf den Port 1433 TCP seine Lauscher aufstellt und konfigurieren daher die Firewall so, daß diese Anfragen durchgestellt werden können.
Eine nette Beigabe der XP Firewall besteht übrigens darin, daß ein permanent geöffneter Port, so eingestellt werden kann, daß nur bestimmten Netzwerksegmenten Zugriff gestattet wird.

Nach Aktivieren des TCP/IP Protokolls sollte der Zugriff nun möglich sein. Doch knapp vorbei ist auch daneben. Selbst bei einer deaktivierten Firewall ist noch keine Verbindung möglich.  Guter Rat ist teuer. Das Problem muss folglich im SSE oder seitens der Netzwerkschicht zu finden sein. Als Werkzeug verwenden wir in der Kommandokonsole „netstat“. Mit der Eingabe netstat –a –b lassen wir uns alle Anwendungen inklusive des benutzten Ports auflisten:

C:\netstat –a –b
…
TCP    xp-pc:ms-sql-s      xp-pcs:0             ABHÖREN         2304  [sqlservr.exe]
…

Technischer Background

Nun ist es klar. Nicht der Standardport 1433 TCP wird verwendet, sondern der Port 2304. Das ist allerdings kein Default Wert. Bei jeder Neuistallation könnte dies ein anderer sein. Der Grund dafür liegt auf der Hand. SSE wird eigtl. immer als zusätzliche Instanz bspw. <servername>\SQLExpress installiert. Falls ein Standardserver bereits installiert wäre,  hätte dieser ja schon den Port 1433 belegen müssen. Um dieses Problem zu umgehen, wurde übrigens schon im SQL Server 2000 ein Technik zur Verfügung gestellt, um mehrere Instanzen auf einem Server hosten zu können.  Die Verbindung über sogenannte Endpunkte übernahm hier noch SQL Server Dienst (sqlserver.exe) selber. Sobald ein Client eine Instanz benötigte, wurde dem Client der jeweilige Endpunkte mitgeteilt. Diese Funktion wurde im SQL Server 2005 dem neuen Dienst SQL Browser zugewiesen. Technisch hat das nun folgende Konsequenz. Nach Start einer SSE Instanz wird ihr dynamisch ein Port zugewiesen. Allerdings kennt der Client diesen Port nicht. Um jetzt nicht alles manuell herausfinden und konfigurieren zu müssen, übernimmt der SQL Browserdienst die Veröffentlichung des jeweiligen Instanznamens und dem dabei zugewiesenen Port. Dieser Informatiosaustausch bewerkstelligt der SQL Browser immer über  den Port 1434 UDP. Insofern beißt man also auf Granit, wenn der SQL Browser Dienst deaktiviert oder der Port 1434 UDP  geschlossen ist. Sollte also der Browser deaktiviert sein, würde auch bei deaktivierter Firewall keine Clientzugriff möglich sein, wenn man den Port nicht kennt. Um nun die Instanz freizugeben sind also folgende Dinge zu beachten:

Konfiguration nach Standardinstallation

Nach einer Standardinstallation sollten Sie unbedingt für einen Remotezuriff darauf achten, der SQL Browser Dienst aktiviert ist. Als nächstes konfigurieren sie die Firewall so, daß die Ports 1434 UDP für den Browser, sowie der TCP Port für die Instanz in der Firewall freigegeben ist. Welchen Port genau Sie freigeben müssen, stellen Sie über netstat fest. Nachteil dieser Methode: der Port ist dynamisch und könnte sich somit ändern. Daher könnten Sie alternativ direkt die sqlserver.exe in der Firewall freigeben.

Sofern Sie auf einen fixen Port bestehen, können Sie diesen im Konfigurationsmanager angeben. Der Konfigurationsmanager bietet die Eintellungen pro Netzwerkkarte an. Tragen Sie deshalb anstatt der „0“ einen fixen Wert ein. Die Einstellung „0“ in den jeweiligen Zeilen „TCP Dynamic Ports“  gibt dem SQL Browser die Möglichkeit einen Port selbst zu wählen. Sofern Sie keinen Unterschied bei den einzelnen Netzwerkkarten wünschen wird Ihnen der Eintrag „IPAll“ angeboten, mit dem sich auf einen Schlag alle integrierten Netzwerkkarten gleichzeitig definieren lassen.

Feature Entscheidung bei Installation – User Instanzen

Eine weitere Besonderheit , oder nennen wie es besser Möglichkeit, des SSE sind sogenannte Benutzer Instanzen. Dieses nette Feature können Sie bereits bei der Installation aktivieren, sofern Sie die „Erweiterte Konfigurationsoptionen“ aktiviert haben.

Alternativ könne Sie Benutzerinstanzen auch nachträglich mit  sp_configure 'user instances enabled','1' aktivieren.

Benutzer Instanzen - Technischer Background

Die Benutzerinstanz oder auch untergeordnete Instanz genannt, wird von der übergeordneten z.B. dem <sqlserver>\SQLExpress generiert. Für den jeweiligen Benutzer wird eine isolierte Instanz zur Verfügung gestellt, die auch ohne weitere Administrationsrechte die Erlaubnis gewährt als Datenbankbesitzer zu fungieren. Da jeder Benutzer in seiner eigenen Instanz arbeitet  - übrigens auch mit Kopien der Systemdatenbanken – stellt die Benutzerinstanz somit sicher, daß keiner der User auf Daten des anderen zugreifen kann. Die Daten werden bei der ersten Verwendung in das lokale UserProfil kopiert und sind somit vor anderen User ohne Adminrechte realtiv sicher.Der Zugriff auf Datenbanken in Benutzerinstanzen geschieht durch den Aufruf der Datenbank Datei. Ein Zugriff könnte wie folgt aussehen:

conn string =
   "Data Source=.\\SQLExpress" +
   integrated security=true;" +
   "attachdbfilename=|DataDirectory|\test.mdf;" +
   "user instance=true"
string connstr = GetConnectionString();
using(SqlConnection conn = new SqlConnection(connstr))
conn.Open();
(Verbindungszeichenfolge für Benutzerinstanz)

Auf Grund dieser Einstellungen erlaubt die Benutzerinstanz  keinen Remotezugriff. Eine Installation des SQLExpress kann allerdings durchaus beides .  Das heißt , in  einer SSE Installation stehen Ihnen jederzeit  parallel Benutzerinstanzen  der „Normalbetrieb“ zur Wahl.

Fazit

Somit dürfte klar sein, dass der SQL Express durchaus remote  betrieben werden kann. Wer dies verhindern will, kann das durch  Benutzerinstanzen oder durch abschalten der Netzwerkdienste erreichen.  An dieser Stelle sei SQL Everywhere  erwähnt, der hier durchaus als Alternative zu Benutzerinstanzen zu erwähnen ist. Nur die SSE erlaubt den Betrieb von  Benutzerinstanzen, was Sie durchaus mal mit den von Microsoft downloadbaren Tool SSEUTIL testen können. Wer auf Netzwerkbetrieb  setzt muss sich nur geringfügig mit dem Konfigurationsmanager und der Firewall  plagen. Insofern viel Spaß mit SQL Express  online ;-)
 

  Links:

Benutzerinstanzen:
http://msdn2.microsoft.com/de-de/library/ms143684.aspx
SQL Everywere
http://www.mssql-forum.de/news/sql-2005/sql-server-everywhere.html
Internet Assigned Numbers Authority  - Liste der well-known-ports
http://www.iana.org/assignments/port-numbers