none
Keine Remote Verbindung zu SQL2012 Server RRS feed

  • Frage

  • Ich habe einige Threads zu diesem Thema gefunden, aber die Antworten dort haben mir nur zum Teil geholfen.

    Die Situation:
    Ein SQL Server 2012 Webedtition innerhalb einer AD Struktur installiert
    Per RDP eingeloggt auf diesem Server kann ich ohne Probleme mit dem SQL Server arbeiten - der Locale Login und Connection zum SQL Server funktionieren ohne Probleme
    Versuche ich von einer anderem Server innerhalb dieser AD Struktur auf den SQL Server zuzugreifen funktioniert das nicht, der SQL Server und Instanz wird nicht gefunden. Das gleiche gilt wenn ich mich von außerhalb über den Forefront zum SQL Server verbinden möchten, ich denke aber wenn es innerhalb der AD Struktur nicht funktioniert geht es schon gar nicht von außerhalb.

    Folgende Aktionen habe ich gemacht oder durchgeführt:
    - Der SQL Server und der SQL ServerBrowserDienst laufen
    - Remote Connection/Logins sind erlaubt
    - TCP/IP, Name Pipes ist aktiviert, generell und für diese Instanz
    - Die Windows-Firewall wurde konfiguriert:
    -- 1. Freischalten des Ports 1433 - ohne Wirkung ein netstat -ano|find "1433" zeigt nichts an und ein telnet zu diesem Server auf diesen Port klappt nicht
    -- 2. Erstellen einer FW Rule die den SQL Server ohne Portbindung freigibt - führt auch zu keinem Ergebnis

    In den SQL Server Logs stehen u.a. diese Einträge:

    .
    .
    09/23/2012 15:34:37,spid18s,Unknown,SQL Server is now ready for client connections. This is an informational message; no user action is required.
    .
    .
    .
    09/23/2012 15:34:37,spid18s,Unknown,Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$IRGENDEINEINSTANZ\sql\query ].
    09/23/2012 15:34:37,spid18s,Unknown,Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\IRGENDEINEINSTANZ ].
    09/23/2012 15:34:37,spid18s,Unknown,Server is listening on [ 'any' <ipv4> 51588].
    09/23/2012 15:34:37,spid18s,Unknown,Server is listening on [ 'any' <ipv6> 51588].
    </ipv6></ipv4>

    Irritiert haben mich allerdings diese Einträge:

    09/23/2012 15:34:37,Server,Unknown,The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/sql01.domainname.intra:51588 ] for the SQL Server service. Windows return code: 0x2098<c> state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
    09/23/2012 15:34:37,Server,Unknown,The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/sql01.domainname.intra:IRGENDEINEINSTANZ ] for the SQL Server service. Windows return code: 0x2098<c> state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
    09/23/2012 15:34:37,Server,Unknown,SQL Server is attempting to register a Service Principal Name (SPN) for the SQL Server service. Kerberos authentication will not be possible until a SPN is registered for the SQL Server service. This is an informational message. No user action is required.
    </c></c>

    Aktuell weiß ich nicht mehr weiter und auch nicht mehr welche Schlagwörter ich in Google eingeben muss das darüber an Hinweise komme.

    Ich würde mich riesig freuen wenn ich von hier Hinweise bekomme, wenn dazu noch weitere Informationen notwendig sind, dann Bitte sagt welche.
    Vielen Dank.

    Grüße Michael 

    -

    Sonntag, 23. September 2012 16:17

Antworten

Alle Antworten

  • wenn Du den SQL Browser Dienst gestartet hast, musst Du auch noch UDP 1434 freischalten

     lies diesen KB Artikel:

    http://support.microsoft.com/kb/287932

    und

    http://technet.microsoft.com/en-us/library/cc646023.aspx#BKMK_ssde

    und noch ein Artikel: http://msdn.microsoft.com/en-us/library/ms175043%28SQL.110%29.aspx


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.


    • Bearbeitet Daniel_Steiner Sonntag, 23. September 2012 17:07
    • Als Antwort markiert Mikel1961 Montag, 1. Oktober 2012 11:48
    Sonntag, 23. September 2012 16:58
  • Dein SPN-Fehler bedeutet im Normalfall, das der SQL Server Dienst unter einem Konto läuft, welches nicht über die benötigen Berechtigungen zum Registrieren der SPN im AD verfügt.

    Zum Freischalten der Firewall ist ja dem Log schon zu entnehmen, das der SQL Server sich auf Port 51588 bindet. Daher solltest du die Variante 2. der FW-Konfiguration wählen/beibhalten. Wichtig: da es sich um eine benannte Instanz handelt, musst du darauf achten, das die sqlserv.exe aus dem entsprechenden Instanzverzeichnis freigegeben wird.

    Für den SQL Server Browser macht ihr entweder das gleiche, oder gebt den Port 1434 frei.

    Auf Named Pipes würde ich ganz verzichten, wenn ihr sie nicht braucht.

    • Als Antwort markiert Mikel1961 Montag, 1. Oktober 2012 11:47
    Sonntag, 23. September 2012 17:01
  • 2 Dinge konnte ich durch Eure Hinweise erkennen und ändern UDP Port 1434 und sqlserv.exe aus dem entsprechendem Instanzverzeichnis.

    Jetzt kann ich mich einloggen, aber nur unter der Verwendung der IP\INSTANZNAME nur die IP schlägt fehl und es funktioniert auch nur innerhalb des AD Netwerks, von außerhalb über den Forefront (Entsprechende Regel ist gesetzt) schlägt ebenfalls fehl.

    Könnte das immer noch an dem SQL Server Browser liegen oder ist der Fehler mehr in der Registrierung der SPN zu suchen.
    Da konnte ich mit der Anleitung zur automatischen Registrierung leider nicht soviel anfangen, da die dort Aufgeführten Hinweise nicht zu unserem 2008R2 dc passen, auch eine weitere Suche hat zwar eine Unmenge an Seiten als Ergebnis hervorgebracht, aber auf Anhieb kein Zielführenden Hinweis.

    Anbei zur Info die Ausgabe von netstat:

    Active Connections

      Proto  Local Address          Foreign Address        State
      TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
      TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
      TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING
      TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING
      TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING
      TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING
      TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING
      TCP    0.0.0.0:49160          0.0.0.0:0              LISTENING
      TCP    0.0.0.0:49194          0.0.0.0:0              LISTENING
      TCP    0.0.0.0:51588          0.0.0.0:0              LISTENING
      TCP    127.0.0.1:51589        0.0.0.0:0              LISTENING
      TCP    ip-address:139        0.0.0.0:0              LISTENING
      TCP    ip-address:3389       ip-address:51665      ESTABLISHED
      TCP    ip-address:49247      ip-address:135        TIME_WAIT
      TCP    ip-address:49248      ip-address:49158      ESTABLISHED
      TCP    ip-address:49250      ip-address:49158      TIME_WAIT
      TCP    [::]:135               [::]:0                 LISTENING
      TCP    [::]:445               [::]:0                 LISTENING
      TCP    [::]:3389              [::]:0                 LISTENING
      TCP    [::]:47001             [::]:0                 LISTENING
      TCP    [::]:49152             [::]:0                 LISTENING
      TCP    [::]:49153             [::]:0                 LISTENING
      TCP    [::]:49154             [::]:0                 LISTENING
      TCP    [::]:49160             [::]:0                 LISTENING
      TCP    [::]:49194             [::]:0                 LISTENING
      TCP    [::]:51588             [::]:0                 LISTENING
      TCP    [::1]:51589            [::]:0                 LISTENING
      UDP    0.0.0.0:123            *:*                    
      UDP    0.0.0.0:500            *:*                    
      UDP    0.0.0.0:1434           *:*                    
      UDP    0.0.0.0:4500           *:*                    
      UDP    0.0.0.0:5355           *:*                    
      UDP    127.0.0.1:50271        *:*                    
      UDP    127.0.0.1:56877        *:*                    
      UDP    127.0.0.1:56879        *:*                    
      UDP    ip-address:137        *:*                    
      UDP    ip-address:138        *:*                    
      UDP    [::]:123               *:*                    
      UDP    [::]:500               *:*                    
      UDP    [::]:1434              *:*                    
      UDP    [::]:4500              *:*                    
      UDP    [::]:5355              *:*     

    Grüße Michael

    Montag, 24. September 2012 09:37
  • Zu ForeFront kann ich nicht viel sagen, habe noch nicht damit gearbeitet. Aber wie lauten den die Fehler bei der Anmeldung? Um welche Art der Anmeldung (Windows oder SQL Server Authentifizierung) handelt es sich?

    Mal ins Blaue geschossen: Wenn es sich um eine Windows-Authentifizierung handelt, kann es sein, das es Aufgrund von ForeFront ein Kerberos Multi-Hop-Problem ist, d.h. ein Problem mit der Delegation von Anmeldeinformationen.

    Es liegt aber in der Regel nicht am SQL Server Browser. Der ist "nur" dazu da, das deine SQL Server Instanz gefunden werden kann. Siehe SQL Server-Browserdienst. Bei einer benannten Instanz muss immer der Instanznamen mit angeben werden, d.h. IP\INSTANZNAME oder SERVERNAME\INSTANZNAME.

    Montag, 24. September 2012 10:13
  • Zu Instanzname: 
    Das habe ich jetzt verstanden, d.h. aber auch das man in Applikationen (z.B. in Webapplikationen) immer den Servername\Instanz angeben muss.
    Kann ich dafür evtl. Alias im Konfigurationsmanager benennen, der für die Kombination Servername\Instanz steht ?

    Über das Internet nutze ich die SQL Authentifizierung es wird die folgende Meldung ausgegeben, die eigentlich ähnlich der ist die ich bisher innerhalb des AD Netzwerk hatte. Damit denke ich das ich noch etwas an den Regeln des Forefront ändern muss, damit die Anfrage durchkommt und auf die "SQL Server Maschine" geleitet wird:

    TITEL: Verbindung mit Server herstellen
    ------------------------------

    Es kann keine Verbindung mit 'FQDN\INSTANZ' hergestellt werden.

    ------------------------------
    ZUSÄTZLICHE INFORMATIONEN:

    Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Überprüfen Sie, ob der Instanzname richtig ist und ob SQL Server Remoteverbindungen zulässt. (provider: SQL Network Interfaces, error: 26 - Fehler beim Bestimmen des angegebenen Servers/der angegebenen Instanz) (Microsoft SQL Server, Fehler: -1)

    Vielen Dank.
    Grüße Michael

    Montag, 24. September 2012 11:12
  • Benutze zum Verbindungstest IP\INSTANCENAME. Aber deine Vermutung bezüglich der ForeFront-Weiterleitung kann korrekt sein. Da musst du deinen zuständigen (Netzwerk-)Admin fragen.
    Dienstag, 25. September 2012 16:22
  • Hallo,

    also innerhalb des AD Netztwerks funktioniert es jetzt ohne Probleme, die Server haben, entsprechende Zugriffsrechte vorrausgesetzt, Zugriff auf die Datenbanken des SQL Servers.  
    Für die Hilfe bedanke ich mich auch, die Tips von Stefan und Daniel.

    Der Zugriff von außerhalb durch den Forefront konnte ich noch nicht realisieren (obwohl es in unserer Testumgebung geklappt hat und ich genau identische Regeln am Forefront verwende wie in der Testumgebung). 
    Da bin ich aber jetzt wieder an dem Punkt an dem ich keine neue Ideen habe. 

    Benötigt wird der Zugang weil eine Warenwirtschaft eines Kunden darüber synchronisiert werden soll, ein Internet Shop greift dann wiederum auf die Datenbank zu. Dieser Internet-Shop ist auf einem Webserver innerhalb des ADs und hat damit keine Verbindungs Probleme zum SQL Server.
    Wir kommen aber nicht vom Computer des Kunden auf den SQL Server.
    Zum testen nutzen wir das SQL Server Management Studio auf dem Computer des Kunden.

    Wenn Du noch eine Idee hast, dann gerne.

    Vielen Dank.

    Gruß
    Michael

     

    Donnerstag, 27. September 2012 16:23
  • Michael

    lies mal diesen MSDN Artikel: http://technet.microsoft.com/en-us/library/cc441596.aspx(configuring SQL Server publishing)

    und diesen Thread (vorallem die Antwort) http://social.technet.microsoft.com/Forums/en-US/Forefrontedgesetup/thread/29613849-8e39-4d9f-8cc6-54ccd93bb6d4 (Problem with publishing of SQL 2008 R2 via Forefront TMG 2010)


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    • Als Antwort markiert Mikel1961 Montag, 1. Oktober 2012 11:47
    Donnerstag, 27. September 2012 18:51
  • Danke für Eure Hilfe das Problem scheint gelöst. Es gibt ja den Spruch "Man sieht den Wald vor lauter Bäume ...."
    richtig bei mir wäre "Man sieht die Firewall vor lauter Firewalls nicht".

    Letzt endlich war es eine Hardware Firewall beim Kunden die dafür sorge das wir Remote nicht auf den SQL Server gekommen sind. Die Ports sind geöffnet worden und seit dem funktionierst.

    Das einzige was mich wundert, ist die Sache mit der benannten Instanz. Innerhalb des ADs benötige ich die Angabe des Instanznamen um Verbindnung mit dem SQL Server aufzunehmen, wenn ich von Außerhalb durch den Forefront komme reicht die IP Adresse des Forefront oder der öffentliche FQDN.

    Kann mir mal jemand das erklären ?
    Liegt das daran der Forefront die Anfrage automatisch zum richtigen Port der Instanz leitet (in unserer Regel ist kein Destination Port angegeben) ?
    Oder habe ich da doch noch irgendein Konfigurationsfehler das ich innerhalb des Ads den Instanznamen angeben muss ?

    Vielen Dank.

    Gruß Michael

    Sonntag, 30. September 2012 08:36
  • Hallo Michael,

    gut dass es jetzt funktioniert.

    Könntest Du bitte auch die Antworten markieren, die Dir geholfen haben?

    So dass auch andere davon profitieren können.

    Danke & Gruss,
    Raul


    Raul Talmaciu, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 1. Oktober 2012 10:59