"Zugriff verweigert", wenn SSMS mit Integration Services verbunden wird

Ich erhalte die folgende Fehlermeldung, wenn ich versuche, SSMS mit Integration Services unter Verwendung des Netzwerknamens eines bestimmten SQL Server-Clusters zu verbinden:

Die Verbindung zum Integration Services-Dienst auf dem Computer 'FooDB' ist mit folgendem Fehler fehlgeschlagen: "Zugriff verweigert."

Dieser Fehler tritt auf, wenn der Computer nicht für das Zulassen von Remoteverbindungen über DCOM konfiguriert wurde oder der Benutzer über DCOM auf den SQL Server Integration Services-Dienst zugreifen kann.

Dies ist ein Routineproblem mit einer gut dokumentierten Lösung. Sehen Sie sich zum Beispiel die Lösungen hier und hier an .

Ich habe jedoch alle mir bekannten Lösungen ausprobiert und das Problem bleibt bestehen.

Im Einzelnen habe ich Folgendes getan:

• Es wurde überprüft, ob die Benutzer, die eine Verbindung herstellen, über die in den Artikeln über MsDtsServer100 aufgeführten DCOM-Berechtigungen verfügen:

  1. Start- und Aktivierungsberechtigungen: Lokalen Start zulassen, Remote-Start, Lokale Aktivierung, Remote-Aktivierung zulassen

  2. Zugriffsberechtigungen: Lokaler Zugriff zulassen, Remotezugriff zulassen

  3. Konfigurationsberechtigung: Lesen zulassen

• Bestätigt mit einem Paket-Sniffer, dass der gesamte mit der Verbindung verbundene Datenverkehr die Firewall erfolgreich passiert. Das letzte Paket, das angezeigt wird, bevor die TCP-Verbindung getrennt wird, ist eine Antwort vom Server, die den Windows-Statuscode für "Zugriff verweigert" in einem MSRPC-Header enthält.

• Wurde getestet, indem die Benutzer der Gruppe "Distributed COM Users" und / oder der lokalen Administratorgruppe hinzugefügt und anschließend die Server neu gestartet wurden. Dies ermöglichte den Benutzern, über SSMS eine Verbindung zu SSIS herzustellen, wobei die lokalen Knotennamen (FooDBN1, FooDBN2) verwendet wurden. Bei der Verbindung mit dem Clusternetzwerknamen (FooDB) wurde ihnen jedoch der Zugriff verweigert, wie sie es gewohnt sind zu verwenden, und was auf unseren anderen Clustern funktioniert.

Außerdem habe ich keine Notwendigkeit gefunden, die Mitgliedschaft dieser Gruppen in anderen Clustern zu ändern.

Bei den anderen von mir überprüften Clustern kann ich SSMS unter Verwendung des Clusternamens ohne andere als die Standardkonfiguration mit SSIS verbinden.

Mir ist klar, dass dies für ServerFault besser geeignet ist und dass die Frage bei Bedarf migriert werden kann. Es handelt sich jedoch auch um ein SQL Server-Problem, und ich denke, dass Benutzer hier mit größerer Wahrscheinlichkeit bereits zuvor damit befasst waren.

Plattformdetails:

• Windows Server 2008 R2 SP1
• SQL Server 2008 R2 SP2
• Aktiv-Passiv-Cluster mit 2 Knoten und einer einzelnen SQL Server-Instanz

Könnte jemand vorschlagen, was ich als nächstes hier suchen sollte?

Update : Das hat heute auf mysteriöse Weise erst begonnen, aber nur für Mitglieder der lokalen Administratorengruppe. Soweit ich das beurteilen kann, hat sich nichts geändert.

Long shot vielleicht, aber es lohnt sich die Datei zu überprüfen

\ Programme \ Microsoft SQL Server \ 100 \ DTS \ Binn \ MsDtsSrvr.ini

oder das Äquivalent zu Ihrem Setup. Sie müssen es möglicherweise manuell mit dem Instanznamen bearbeiten. Andernfalls suchen SSIS-Verbindungen möglicherweise nach einer MSDB einer nicht vorhandenen Standard-SQL-Instanz.

Das Problem hat etwas mit Berechtigungen auf dem zugrunde liegenden Server und nicht mit SSIS oder der MSDB zu tun. Wir hatten das gleiche Problem. Das vorübergehende Hinzufügen des AD-Kontos des Benutzers zur lokalen Administratorgruppe hat dies für uns behoben. Das Hinzufügen ihres AD-Kontos zu PowerUsers oder Benutzern war nicht der Fall. Ich bin jedoch sicher, dass wir herausgefunden haben könnten, was in der lokalen Sicherheitsrichtlinie fehlte, um dies zu erreichen.