Aufruf über Link stellt keine Verbindung her

[Jasocul]

Hallo,

folgende Situation liegt vor:
Jemand meldet sich über aus einer anderen Domain über rdp auf unserer Domain an.
Es soll ein Programm gestartet werden, dass eine Verbindung zu unserem SQL-Server aufbaut.
Fall 1: Das Programm liegt auf dem Desktop, wird gestartet und baut die Verbindung auf. Alles ok.
Fall 2: Das Programm liegt auf einem anderen Server und wird als Link auf dem Desktop zur Verfügung gestellt. Das Programm startet, kann aber keine Verbindung zum SQL-Server aufbauen. Das selbe Verhalten ist auch, wenn es ohne Link vom anderen Server gestartet wird.

Es ist wirklich die selbe Anwendung.
Zur Sicherheit habe ich ein Test-Programm geschrieben, dass über einen Button die Verbindung aufbaut. Programm startet, aber die Verbindung zum SQL-Server kann nicht aufgebaut werden. Es sei denn, die Anwendung liegt auf dem Server, der die rdp-Sitzung verwaltet.

Ein weiterer Test:
Die Anwendung kann Dateien auf dem Server erzeugen, wo die Anwendung normalerweise liegt.
Es scheint wirklich nur ein Problem mit der Verbindung zu unserem SQL-Server zu sein. Allerdings habe ich keine Vorstellung woran das liegen soll, da das Programm zwar an unterschiedlichen Orten abgelegt ist, aber immer in der selben Umgebung gestartet wird.

Hat jemand eine Idee, was das Problem sein kann?

EDIT:
Die Fehlermeldung hatte ich vergessen:
[DBNETLIB][ConnectionOpen(Connect()).]SQL Server existiert nicht oder Zugriff verweigert.

[Bambini]

Auf welchem Computer ist der SQL Server?
Evtl. Erlaubt der SQL Server keine Anfragen von anderen - im Netzwerk liegenden - Rechnern, sondern nur lokale.

[Jasocul]

Alle Rechner sind in der selben Domain.
Es sind 3 Server beteiligt:
- SQL-Server
- Server für RDP-Sitzung
- File-Server für die Anwendung

Die Domain-User haben nur den Link zur Anwendung auf ihrem Desktop. Bei denen funktioniert es problemlos.

[jaenicke]

Liegt es vielleicht an der Firewall?
Wird für die SDAC-Komponenten vielleicht der Native Client benötigt und dieser ist nicht installiert?

[Jasocul]

Hallo jaenicke,

Firewall ist bereits ausgestellt.
Ich kann mir beim besten Willen nicht vorstellen, warum der Native-Client einen Unterschied machen soll, wenn ich ein Programm auf dem lokalen Rechner starte oder über den Explorer vom anderen Server. Die Arbeitsumgebung ändert sich dadurch ja nicht und die Anwendung ist identisch.

[Bambini]

Zitat:

Zitat von Jasocul (Beitrag 1344212)

Firewall ist bereits ausgestellt.

Auch auf dem Rechner, von dem du die Anwendung startest?

Zitat:

Zitat von Jasocul (Beitrag 1344212)

Ich kann mir beim besten Willen nicht vorstellen, warum der Native-Client einen Unterschied machen soll, wenn ich ein Programm auf dem lokalen Rechner starte oder über den Explorer vom anderen Server. Die Arbeitsumgebung ändert sich dadurch ja nicht und die Anwendung ist identisch.

Die Fehlermeldung sieht auch so aus, dass diese vom DB Client kommt.

[Bambini]

Zitat:

Zitat von Jasocul (Beitrag 1344212)

Ich kann mir beim besten Willen nicht vorstellen, warum der Native-Client einen Unterschied machen soll, wenn ich ein Programm auf dem lokalen Rechner starte oder über den Explorer vom anderen Server. Die Arbeitsumgebung ändert sich dadurch ja nicht und die Anwendung ist identisch.

In der Firewall kann man Ausnahmen für bestimmt EXE Dateien machen. Startet man die gleiche EXE von woanders gelingt ihr keine Verbindung.

[Jasocul]

@Bambini:
Firewall ist auf dem Client ausgestellt. Aber ich spreche gleich mal mit meinem Kollegen, wie es auf den anderen Servern aussieht. Wir teilen uns hier gerade die Arbeit, damit wir das Problem schneller gelöst bekommen.

Klar kommt die Meldung vom Client. Es kann ja gar nicht erst eine Verbindung aufgebaut werden. :wink:

Wie schon gesagt, es ist immer die gleiche Anwendung. Einmal liegt diese lokal und einmal auf einem anderen Server der Domain.

[Bambini]

Zitat:

Zitat von Jasocul (Beitrag 1344216)

Wie schon gesagt, es ist immer die gleiche Anwendung. Einmal liegt diese lokal und einmal auf einem anderen Server der Domain.

In den Ausnahmen der Firewall ist der komplette Pfad mit EXE angegeben. Der muss passen.

[Jasocul]

Zitat:

Zitat von Bambini (Beitrag 1344214)

In der Firewall kann man Ausnahmen für bestimmt EXE Dateien machen. Startet man die gleiche EXE von woanders gelingt ihr keine Verbindung.

Der Kollege versucht sich gerade daran, aber der Server murmelt was von "neu starten". Das können wir leider im Moment nicht. Aber wir probieren an der Stelle mal weiter.

[Bambini]

Optional kann man die Verbindungen zum SQL Server auch über "Named Pipes" erlauben.
Dann umgeht man damit das ganze Firewall Thema. Standardmäßig ist das aber am SQL Server deaktiviert.
Das Einschalten geht aber auch nur durch einen SQL Server Neustart:(

[Jasocul]

Named-Pipes waren aktiviert und sind jetzt deaktiviert, weil wir genau die umgekehrte Schlussfolgerung gezogen hatten. :lol:

Inzwischen vermuten wir, dass es irgendetwas mit der Vertrauensstellung zu tun hat. Aber um ehrlich zu sein, stochern wir immer noch im Nebel.

[Bambini]

Zitat:

Zitat von Jasocul (Beitrag 1344223)

Named-Pipes waren aktiviert und sind jetzt deaktiviert, weil wir genau die umgekehrte Schlussfolgerung gezogen hatten. :lol:

Named Pipe Zugriffe sind wie Dateizugriffe, diese lässt die Firewall gewähren.

Zitat:

Zitat von Jasocul (Beitrag 1344223)

Inzwischen vermuten wir, dass es irgendetwas mit der Vertrauensstellung zu tun hat. Aber um ehrlich zu sein, stochern wir immer noch im Nebel.

Hm, wenn der Connect beim Start vom Desktop funktioniert, sollte genügend Vertrauen da sein :-D
Ist ein Antivirus Programm aktiv?

[nahpets]

Hab' mal 'ne Frage:

Hat der Inhalt von "Ausführen in" (Das Arbeitsverzeichnis im Link) eventuell Auswirkungen?

Versucht der Client eventuell in das Verzeichnis der Exe (oder deren nähere Umgebung) zu schreiben.

Ändert sich das Verhalten, wenn im Link bei "Ausführen in" ein definitiv beschreibbares Verzeichnis eingegeben wird?

[Jasocul]

Zitat:

Zitat von Bambini (Beitrag 1344226)

Hm, wenn der Connect beim Start vom Desktop funktioniert, sollte genügend Vertrauen da sein :-D
Ist ein Antivirus Programm aktiv?

Sollte eigentlich nicht aktiv sein. Aber ich werde das mal prüfen.

Zitat:

Zitat von nahpets (Beitrag 1344227)

Hat der Inhalt von "Ausführen in" (Das Arbeitsverzeichnis im Link) eventuell Auswirkungen?

Leider nicht.

Zitat:

Zitat von nahpets (Beitrag 1344227)

Versucht der Client eventuell in das Verzeichnis der Exe (oder deren nähere Umgebung) zu schreiben.

Ja. Aber ich habe einen kleine Test-Anwendung geschrieben. Diese versucht nur die Connection zum SQL-Server zu öffnen. Schreibfunktionen in Verzeichnisse habe ich damit auch schon geprüft. Das funktioniert ohne Probleme. Auch wenn es nicht lokal gestartet wird.

Zitat:

Zitat von nahpets (Beitrag 1344227)

Ändert sich das Verhalten, wenn im Link bei "Ausführen in" ein definitiv beschreibbares Verzeichnis eingegeben wird?

Leider nicht. Ich habe da alle denkbaren Konstellationen getestet.

[nahpets]

Hilft Dir der dort http://www.mcseboard.de/topic/194150...bindung/page-2 geführte Dialog eventuell weiter?

Oder diese Beschreibung von MS: https://support.microsoft.com/de-de/kb/888228

Andernorts fand ich diese Beschreibung zu der von Dir genannten Fehlermeldung:

Zitat:

Das liegt daran, das Excel nicht den SQL-Alias anspricht, sondern nach einem DNS Eintrag sucht. Sollten Sie keine Benamteinstanz benutzen, sondern hier eine Standardinstanz, so können Sie das Problem relativ einfach lösen, indem Sie einen DNS- oder CNAME Eintrag innerhalb Ihres DNS-Servers hinzufügen, um nun die Excel Berichte innerhalb einer SQL-Alias betriebenen Infrastruktur zu erstellen, ist es das Einfachste, eine neue ODBC-Verbindung zu verwenden, die auf die jeweilige SQL-Instanz verweist. Gehen Sie hierzu wie folgt vor.

[Jasocul]

Ein kleines Stück weiter ...
Also das AV haben wir einmal komplett ausgeschaltet. Keine Änderung im Verhalten.

Ich habe meiner Anwendung jetzt gesagt, es soll ein Login-Prompt für den SQL-Server anzeigen.
Beim Versuch die Server-Liste anzeigen zu lassen, bekomme ich folgenden Fehler:

"Cannot create UDP socket:
Ein ungültiges Argument wurde angegeben.
Socket-Error Code: 10022($2726)"

Starte ich die Anwendung lokal, funktioniert die Server-Liste.

@nahpets:
Das schaue ich mir gleich genauer an.

[Bambini]

Zitat:

Zitat von Jasocul

"Cannot create UDP socket:
Ein ungültiges Argument wurde angegeben.
Socket-Error Code: 10022($2726)"

Schau mal hier:
https://social.msdn.microsoft.com/Fo...-and?forum=wsk

[Jasocul]

Da bin ich auch gerade drauf gestoßen und es war tatsächlich die Ursache.

Allerdings hilft das nicht weiter, weil es durchaus einen Grund hat, warum in den oberen Verzeichnissen keine Berechtigungen sein sollen.

Zumindest wissen wir jetzt woran es liegt und müssen uns eine andere Lösung ausdenken. Plan B gibt es, aber der ist eigentlich nicht gewünscht.

Danke an alle, die mir geholfen haben.

[jaenicke]

Was ist denn mit der Lösung, die in dem Link genannt wird?

Zitat:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\servic es\FltMgr
add this entry
Name: UseTildeShortcut(DWORD)
Data: 1
You have to add this entry on the client machine.

[Jasocul]

Das habe ich delegiert. :lol:
Spaß bei Seite. Darum kümmert sich jetzt der SysAdmin. Der muss das mit seinen Vorgaben und Nebenwirkungen abgleichen.

[rokli]

Hi Jasocul,

nur mal nebenbei: Die DNS Server sind korrekt?

Das haben wir nach der Abschaltung alter DNS Server mal gehabt, das bei fehlerhaften DNS Einträgen keine Verbindungen mit dem SQL aufgenommen werden konnten.

Gruß

Edit: Da war ich wohl zu spät ;-)

[Jasocul]

@Rolf:
Daran hatten wir auch schon gedacht, konnte allerdings relativ schnell ausgeschlossen werden. Aber sicher eine gute Info, falls nochmal Jemand mit ähnlichen Problemen zu kämpfen hat.