Fehler "SSPI-Kontext kann nicht generiert werden" bei Verwendung Windows Authentifizierung zum Verbinden SQL Server

Gilt für:   SQL Server
Ursprüngliche KB-Nummer: 811889

Hinweis

Bevor Sie mit der Problembehandlung beginnen, empfehlen wir, die Voraussetzungen zu überprüfen und die Prüfliste durchzugehen.

Wenn Sie Windows Authentifizierung verwenden, um eine SQL Server Instanz remote zu verbinden, wird die folgende Fehlermeldung angezeigt:

Der Zielprinzipalname ist falsch. SSPI-Kontext kann nicht generiert werden.

Häufig gestellte Fragen

Was ist SSPI?

SSPI (Security Support Provider Interface) ist eine Reihe von Windows-APIs, die die Delegierung und gegenseitige Authentifizierung über alle generischen Datentransportebenen wie TCP/IP-Sockets ermöglichen. Mindestens ein Softwaremodul stellt die tatsächlichen Authentifizierungsfunktionen bereit. Jedes Modul wird als Sicherheitsunterstützungsanbieter (Security Support Provider, SSP) bezeichnet und als Dynamic Link Library (DLL) implementiert.

Was ist Kerberos?

Das Kerberos v5-Protokoll ist ein Branchenstandardsicherheitspaket und eines der drei Sicherheitspakete in Windows Betriebssystemen. Weitere Informationen finden Sie unter Sicherheitssupportanbieter (Security Support Providers, SSPs).

Was bedeutet der Fehler "SSPI-Kontext kann nicht generiert werden"?

Dieser Fehler bedeutet, dass SSPI versucht, die Kerberos-Authentifizierung jedoch nicht verwenden kann, um Clientanmeldeinformationen über TCP/IP oder Named Pipe an SQL Server zu delegieren. In den meisten Fällen verursacht ein falsch konfigurierter Dienstprinzipalname (SERVICE Principal Name, SPN) diesen Fehler.

Was ist SPN?

Ein Dienstprinzipalname (SPN) ist ein eindeutiger Bezeichner einer Dienstinstanz. SPNs werden von der Kerberos-Authentifizierung verwendet, um eine Dienstinstanz einem Dienstanmeldekonto zuzuordnen. Dieser Zuordnungsprozess ermöglicht es einer Clientanwendung, den Dienst aufzufordern, ein Konto zu authentifizieren, auch wenn der Client keinen Kontonamen hat.

Ein typischer SPN für einen Server, auf dem eine Instanz von SQL Server ausgeführt wird, lautet beispielsweise wie folgt:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Das Format eines SPN für eine Standardinstanz ist identisch mit einem SPN für eine benannte Instanz. Die Portnummer verbindet den SPN mit einer bestimmten Instanz. Weitere Informationen zum Registrieren SQL Server Service SPNs finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Warum verwendet SSPI die NTLM- oder Kerberos-Authentifizierung?

Windows Authentifizierung ist die bevorzugte Methode für Benutzer, um sich bei SQL Server zu authentifizieren. Clients, die Windows Authentifizierung verwenden, werden mit NTLM oder Kerberos authentifiziert.

Wenn ein SQL Server Client integrierte Sicherheit über TCP/IP-Sockets auf einem Remoteserver verwendet, auf dem SQL Server ausgeführt wird, verwendet die SQL Server Clientnetzwerkbibliothek die SSPI-API, um eine Sicherheitsdelegierung durchzuführen. Der SQL Server Netzwerkclient ruft die AcquireCredentialsHandle-Funktion auf und übergibt "negotiate" für den pszPackage Parameter. Dieser Prozess benachrichtigt den zugrunde liegenden Sicherheitsanbieter, die Delegierung auszuhandeln. In diesem Kontext bedeutet "Aushandeln", die Kerberos- oder NTLM-Authentifizierung auf Windows-basierten Computern auszuprobieren. Anders ausgedrückt: Windows verwendet die Kerberos-Delegierung, wenn der Zielcomputer, auf dem SQL Server ausgeführt wird, über einen zugeordneten und ordnungsgemäß konfigurierten SPN verfügt. Andernfalls verwendet Windows ntlm-Delegierung.

Warum tritt kein Failover der Verbindung zu NTLM auf, nachdem Probleme mit Kerberos aufgetreten sind?

Der SQL Server-Treibercode auf dem Client verwendet die WinSock-Netzwerk-API zum Auflösen des vollqualifizierten DNS des Servers, wenn der Treiber Windows Authentifizierung verwendet, um eine Verbindung mit SQL Server herzustellen. Zum Ausführen dieses Vorgangs ruft der Treibercode die gethostbyname WinSock-APIs auf gethostbyaddr . Wenn integrierte Sicherheit verwendet wird, versucht der Treiber, das vollqualifizierte DNS des Servers aufzulösen, auch wenn eine IP-Adresse oder ein Hostname als Name des Servers übergeben wird.

Wenn der SQL Server-Treiber auf dem Client das vollqualifizierte DNS des Servers auflöst, wird das entsprechende DNS verwendet, um den SPN für den Server zu bilden. Daher können Probleme beim Auflösen der IP-Adresse oder des Hostnamens in einem vollqualifizierten DNS von WinSock dazu führen, dass der SQL Server-Treiber einen ungültigen SPN für den Server erstellt.

Beispielsweise kann der clientseitige SQL Server Treiber als vollqualifizierte DNS verwendet werden, um ungültige SPNs wie folgt aufzulösen:

  • MSSQLSvc/SQLSERVER1:1433
  • MSSQLSvc/123.123.123.123:1433
  • MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
  • MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Wenn der SQL Server Treiber einen ungültigen SPN bildet, funktioniert die Authentifizierung weiterhin, da die SSPI-Schnittstelle versucht, den SPN im Active Directory-Dienst nachzuschlagen. Wenn die SSPI-Schnittstelle den SPN nicht findet, wird die Kerberos-Authentifizierung nicht ausgeführt. An diesem Punkt wechselt die SSPI-Ebene in den NTLM-Authentifizierungsmodus, und die Anmeldung verwendet die NTLM-Authentifizierung und ist in der Regel erfolgreich. Wenn der SQL Server-Treiber einen gültigen SPN bildet, der nicht dem entsprechenden Container zugewiesen ist, versucht der Treiber den SPN, kann ihn jedoch nicht verwenden. In diesem Fall kann die Fehlermeldung "SSPI-Kontext kann nicht generiert werden" auftreten. Wenn das SQL Server Startkonto ein lokales Systemkonto ist, ist der entsprechende Container der Computername. Bei jedem anderen Konto ist der entsprechende Container das SQL Server Startkonto. Die Authentifizierung verwendet den ersten gefundenen SPN. Stellen Sie daher sicher, dass keine SPNs falschen Containern zugewiesen sind. Mit anderen Worten, jeder SPN darf nur einem Container zugewiesen werden.

Wie kann ich die Authentifizierungsmethode der Verbindung überprüfen?

Führen Sie die folgende Abfrage aus, um die Authentifizierungsmethode einer Verbindung zu ermitteln:

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Weitere Informationen finden Sie unter Ermitteln, ob ich mit SQL Server mithilfe der Kerberos-Authentifizierung verbunden bin.

Wie erstellen Sie SPNs für SQL Server?

Wenn eine Instanz des SQL Server Datenbank-Engine gestartet wird, versucht SQL Server, den SPN mithilfe der DsWriteAccountSpn-API automatisch für den SQL Server Dienst zu registrieren. Dieser Aufruf ist erfolgreich, wenn das SQL Server Dienstkonto über LeseservicePrincipalName- und Schreibrechte servicePrincipalName in Active Directory verfügt. Andernfalls benötigen Sie Ihren Active Directory-Administrator, um den richtigen SPN mithilfe des Microsoft Kerberos-Managers für SQL Server oder des integrierten Setspn-Tools manuell zu registrieren. Weitere Informationen zum Verwalten von SPNs für SQL Server finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Hinweis

Dieses Verfahren gilt nur für Situationen, in denen diese Fehlermeldungen immer und nicht zeitweise angezeigt werden.

Es gibt verschiedene Gründe, warum Kerberos-Verbindungen fehlschlagen, z. B. falsch konfigurierte SPNs, Probleme mit der Namensauflösung oder unzureichende Rechte für SQL Server Dienststartkonten. Microsoft Kerberos Configuration Manager (KCM) ist ein Tool, mit dem die Fehlerursachen überprüft werden können. KCM bietet auch Optionen zum Beheben von identifizierten Problemen im Prozess.

Führen Sie die folgenden Schritte aus, um den Fehler durch KCM zu beheben.

  1. Laden Sie auf dem Computer, auf dem Die Verbindungsprobleme auftreten, Kerberos Configuration Manager herunter, und installieren Sie sie.

  2. Starten Sie KerberosConfigMgr.exe aus dem Ordner "%SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager ". Verwenden Sie dann ein Domänenkonto, das über Berechtigungen zum Herstellen einer Verbindung mit dem SQL Server Computer verfügt, mit dem Sie keine Verbindung herstellen können.

  3. Wählen Sie Verbinden aus, und lassen Sie den Servernamen und andere Für Ihr Szenario zutreffende Details leer, wenn Sie KCM auf dem SQL Server Computer ausführen. Wählen Sie Verbinden aus, um die Analyse durchzuführen. Nachdem KCM die erforderlichen Informationen abgerufen hat, wechselt er automatisch zur SPN-Registerkarte und zeigt standardmäßig Informationen für SQL Server, SQL Server Reporting Services, Analysis Services und AG-Listener an. Um diesen Fehler zu beheben, deaktivieren Sie alles außer SQL Server.

  4. Überprüfen Sie die Diagnose des Tools mithilfe der Spalte "Status ", und führen Sie die relevanten Schritte aus, um das Problem zu beheben:

    Status Weitere Informationen Aktion
    Gut Das überprüfte Element ist ordnungsgemäß konfiguriert. Sie können das nächste Mal in der Ausgabe fortfahren. Keine Aktion erforderlich
    Erforderlicher SPN fehlt Dieser Status wird gemeldet, wenn der in der Spalte "Erforderlicher SPN" identifizierte SPN für das SQL Server Startkonto im Active Directory fehlt. 1. Wählen Sie "Beheben " aus, um die Informationen im Dialogfeld "Warnung " zu überprüfen.
    2. Wählen Sie "Ja " aus, um den fehlenden SPN zu Active Directory hinzuzufügen.
    3. Wenn Ihr Domänenkonto über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, wird der erforderliche SPN zu Active Directory hinzugefügt.
    4. Wenn Ihr Domänenkonto nicht über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, verwenden Sie "Generieren " oder "Alle generieren ", um das Skript zu generieren, mit dem der Active Directory-Administrator die fehlenden SPNs hinzufügen kann.
    5. Nachdem die SPNs hinzugefügt wurden, führen Sie Kerbersos Configuration Manager erneut aus, um zu überprüfen, ob die SPN-Probleme behoben sind.
    TCP muss für die Verwendung der Kerberos-Konfiguration aktiviert sein Dies tritt auf, wenn TCP auf dem Clientcomputer nicht aktiviert ist. Führen Sie die folgenden Schritte aus, um das TCP/IP-Protokoll für die SQL Server Instanz zu aktivieren:
    1. Erweitern Sie in SQL Server-Konfigurations-Manager im Konsolenbereich SQL Server Netzwerkkonfiguration.
    2. Wählen Sie im Konsolenbereich Protokolle für <instance name>aus.
    3. Klicken Sie im Detailbereich mit der rechten Maustaste auf TCP/IP, und wählen Sie " Aktivieren" aus.
    4. Wählen Sie im Konsolenbereich SQL Server Dienste aus.
    5. Klicken Sie im Detailbereich mit der rechten Maustaste auf SQL Server (<instance name>), und wählen Sie "Neu starten" aus, um den SQL Server Dienst zu beenden und neu zu starten.
    Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren eines Servernetzwerkprotokolls.
    Dynamischer Port Diese Meldung wird für benannte Instanzen angezeigt, die dynamische Ports verwenden (Standardkonfiguration). In Umgebungen, in denen Sie Kerberos zum Herstellen einer Verbindung mit SQL Server verwenden müssen, sollten Sie die benannte Instanz auf einen statischen Port festlegen und diesen Port bei der Registrierung von SPN verwenden. Führen Sie die folgenden Schritte aus, um ihre SQL Server Instanz für die Verwendung eines statischen Ports zu konfigurieren:
    1. Erweitern Sie in SQL Server-Konfigurations-Manager im Konsolenbereich SQL Server Netzwerkkonfiguration, erweitern Sie Protokolle für <instance name>und doppelklicken Sie dann auf TCP/IP.
    2. Überprüfen Sie im Dialogfeld "TCP/IP-Eigenschaften " die Einstellung "Alle überwachen " auf der Registerkarte "Protokoll ".
    3. Wenn die Einstellung "Alle überwachen" auf "Ja" festgelegt ist, wechseln Sie zur Registerkarte "IP-Adressen", und scrollen Sie zum Ende der Windows, um die Einstellung "IPAll" zu finden. Löschen Sie den aktuellen Wert, der in den dynamischen TCP-Ports enthalten ist, und legen Sie den gewünschten Wert im FELD "TCP-Port " fest. Wählen Sie "OK" aus, und starten Sie die SQL Server Instanz neu, damit die Einstellungen wirksam werden.
    4. Wenn die Einstellung " Alle überwachen " auf "Nein" festgelegt ist, wechseln Sie zur Registerkarte " IP-Adressen ", und überprüfen Sie jede der IP-Adressen, die in IP1, IP2 angezeigt werden. Entfernen Sie für aktivierte IP-Adressen den aktuellen Wert im Feld "Dynamische TCP-Ports ", und legen Sie den gewünschten Wert im Feld "TCP-Port " fest. Wählen Sie "OK" aus, und starten Sie die SQL Server Instanz neu, damit die Einstellungen wirksam werden.
    Weitere Informationen finden Sie unter Konfigurieren eines Servers zum Überwachen auf einem bestimmten TCP-Port.
    Doppelter SPN Sie können auf die Situation stoßen, wenn derselbe SPN unter verschiedenen Konten in Active Directory registriert ist. 1. Klicken Sie auf die Schaltfläche "Korrigieren ", zeigen Sie die Informationen im Dialogfeld "Warnung " an, und wählen Sie "Ja " aus, wenn Sie den fehlenden SPN zu Active Directory hinzufügen können.
    2. Wenn Ihr Domänenkonto über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, wird der falsche SPN gelöscht.
    3. Wenn Ihr Domänenkonto nicht über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, verwenden Sie die Schaltfläche " Alle generieren " oder " Alle generieren ", um das erforderliche Skript zu generieren, das Sie an Ihren Active Directory-Administrator übergeben können, um die doppelten SPNs zu entfernen. Nachdem die SPNs entfernt wurden, führen Sie den KCM erneut aus, um sicherzustellen, dass die SPN-Probleme behoben sind.

    Hinweis

    Wenn das Domänenkonto, das KCM startet, nicht über Berechtigungen zum Bearbeiten von SPNs in Active Directory verfügt, können Sie die entsprechende Schaltfläche " Alle generieren " oder " Alle generieren " unter der SPN-Skriptspalte verwenden, um die erforderlichen Befehle zu generieren, und mit Ihrem Active Directory-Administrator zusammenarbeiten, um die von KCM identifizierten Probleme zu beheben.

  5. Nachdem Sie alle im KCM identifizierten Probleme behoben haben, führen Sie das Tool erneut aus. Stellen Sie sicher, dass keine anderen Probleme gemeldet werden, und wiederholen Sie dann die Verbindung. Wenn das Tool weiterhin Probleme meldet, wiederholen Sie das vorherige Verfahren.

Beheben des Fehlers ohne Kerberos Configuration Manager

Wenn Sie KCM nicht verwenden können, führen Sie die folgenden Schritte aus:

Schritt 1: Überprüfen der Namensauflösung mit dem Pingbefehl

Der schlüsselfaktor, der die Kerberos-Authentifizierung erfolgreich macht, ist die gültige DNS-Funktionalität im Netzwerk. Sie können diese Funktionalität auf dem Client und dem Server mithilfe des Ping Eingabeaufforderungsprogramms überprüfen. Führen Sie auf dem Clientcomputer den folgenden Befehl aus, um die IP-Adresse des Servers abzurufen, auf dem SQL Server ausgeführt wird (wobei der Name des Computers lautetSQLServer1):

ping sqlserver1

Führen Sie den folgenden Befehl aus, um festzustellen, ob das Ping-Hilfsprogramm den vollqualifizierten DNS von SQLServer1auflöst:

ping -a <IPAddress>

Beispiel:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

Wenn der Befehl ping -a <IPAddress> in das richtige vollqualifizierte DNS des Computers aufgelöst wird, auf dem SQL Server ausgeführt wird, ist auch die clientseitige Auflösung erfolgreich.

Verwenden Sie für detaillierte Diagnosen das Cmdlet "Test-NetConnection " oder "Test-Connection", um die TCP-Konnektivität gemäß der auf dem Computer installierten PowerShell-Version zu testen. Weitere Informationen zum PowerShell-Cmdlet finden Sie in der Cmdlet-Übersicht.

Hinweis

Zu den Methoden für die Namensauflösung können DNS-, WINS-, Hosts- und Lmhosts-Dateien gehören. Weitere Informationen zu Problemen bei der Namensauflösung und zur Problembehandlung finden Sie unter den folgenden Links:

Überprüfen Sie, ob Aliase für das Ziel in SQL Server-Konfigurations-Manager und im SQL Server Clientnetzwerk-Dienstprogramm vorhanden SQL Server. Wenn ein solcher Alias vorhanden ist, stellen Sie sicher, dass er ordnungsgemäß konfiguriert ist, indem Sie Servernamen, Netzwerkprotokoll, Portnummer usw. überprüfen.

Schritt 2: Überprüfen der Kommunikation zwischen Domänen

Stellen Sie sicher, dass die Domäne, bei der Sie sich anmelden, mit der Domäne des Servers kommunizieren kann, auf dem SQL Server ausgeführt wird. Es muss auch eine korrekte Namensauflösung in der Domäne vorhanden sein.

  1. Stellen Sie sicher, dass Sie sich mit demselben Domänenkonto und Kennwort wie das SQL Server Dienststartkonto bei Windows anmelden können. Beispielsweise kann der SSPI-Fehler in einer der folgenden Situationen auftreten:

    • Das Domänenkonto ist gesperrt.
    • Sie haben den SQL Server Dienst nicht neu gestartet, nachdem das Kennwort des Kontos geändert wurde.
  2. Wenn sich Ihre Anmeldedomäne von der Domäne des Servers unterscheidet, auf dem SQL Server ausgeführt wird, überprüfen Sie die Vertrauensstellung zwischen den Domänen.

  3. Überprüfen Sie, ob sich die Domäne, zu der der Server gehört, und das Domänenkonto, mit dem Sie eine Verbindung herstellen, in derselben Gesamtstruktur befinden. Dieser Schritt ist erforderlich, damit SSPI funktioniert.

Schritt 3: Überprüfen SQL Server SPNs mit sqlcheck- und Setspn-Tools

Wenn Sie sich lokal beim SQL Server Computer anmelden können und Über Administratorzugriff verfügen, verwenden Sie SQLCheck aus dem Microsoft SQL Networking GitHub Repository. SQLCheck bietet die meisten informationen, die für die Problembehandlung in einer Datei erforderlich sind. Weitere Informationen zur Verwendung des Tools und zu den gesammelten Informationen finden Sie auf der Startseite des Tools. Sie können auch die empfohlenen Voraussetzungen und die Checklistenseite überprüfen. Nachdem Sie die Ausgabedatei generiert haben, überprüfen Sie die SPN-Konfiguration für Ihre SQL Server Instanz im Abschnitt SQL Server Informationen der Ausgabedatei.

Beispiel für die Ausgabe:

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Verwenden Sie die obige Ausgabe, um die nächsten Schritte zu ermitteln (siehe Beispiele unten), und verwenden Sie das Setspn-Tool , um die erforderlichen Abhilfemaßnahmen zur Behebung von SPN-Problemen zu ergreifen.

Szenario Vorgeschlagene Aktion
SPN ist nicht vorhanden Fügen Sie die erforderlichen SPNs für Ihr SQL Server-Dienstkonto hinzu.
Doppelte SPNs Löschen Sie den SPN, der für Ihren SQL Dienst registriert ist, unter dem falschen Konto.
SPN unter falschem Konto Löschen Sie den registrierten SPN für Ihren SQL Dienst unter dem falschen Konto, und registrieren Sie den SPN dann unter dem richtigen Dienstkonto.

Hinweis

  • Sie können den Abschnitt SQL Server Informationen in der Ausgabedatei des SQLCheck-Tools überprüfen, um das Dienstkonto Ihrer SQL Server Instanz zu finden.

  • Setspn ist ein integriertes Tool in neueren Versionen von Windows, mit dem Sie SPNs in Active Directory lesen, hinzufügen, ändern oder löschen können. Mit diesem Tool können Sie überprüfen, ob SQL Server SPNs gemäß "Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen" konfiguriert sind. Weitere Informationen finden Sie im Setspn-Tool und in Beispielen zur Verwendung.

  • Weitere Informationen zu Szenarien, in denen SQL Server SPNs automatisch registriert und eine manuelle SPN-Registrierung erforderlich ist, finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Schritt 4: Überprüfen der Kontoberechtigung für SQL Server Startkonto auf dem verknüpften Server

Wenn Sie den Identitätswechsel als Authentifizierungsoption auf der Sicherheitsseite Ihres verknüpften Servers verwenden, ist SQL Server erforderlich, um eingehende Anmeldeinformationen an Remote-SQL Server zu übergeben. Für das SQL Server Startkonto, in dem der verknüpfte Server definiert ist, sollte das Konto als vertrauenswürdig für das Delegierungsrecht in Active Directory zugewiesen sein. Weitere Informationen finden Sie unter Aktivieren von Computer- und Benutzerkonten als vertrauenswürdig für die Delegierung.

Hinweis

Dieser Schritt ist nur erforderlich, wenn Sie Probleme im Zusammenhang mit verknüpften Serverabfragen behandeln.

Siehe auch