ODBC vom Terminalserver

[webmaschder 10]

Hi zusammen,

 

ich stehe wahrscheinlich gerade auf dem Schlauch und komme einfach nicht weiter. Folgendes Szenario:

 

SQL Server: MS Server 2003 R2 mit SQL 2005

Terminalserver: MS Server 2008 R2

 

auf dem Terminalserver ist ein Programm installiert, das mittels ODBC auf den SQL Server zugreift. Nach der Installation des Programms werden auch die System-DSN angelegt, sieht alles gut aus.

Das hat jetzt ca. 6Monate problemlos funktioniert, nun aber können alle Benutzer (außer der Admin) sich nicht mehr mit dem SQL Server verbinden. Die Meldung (Original, nicht gekürzt):

 

"Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber an"

 

warum die Meldung abgeschnitten wird ist ne andere unerklärliche sache .. aber nunja.

Verändert wurde in der Zeischenzeit garnichts. Weder Programme installiert noch Updates oder sonst was.

Die User selbst können die System-DSN natürlich nicht bearbeiten.

 

Die Frage nun: habe ich irgendwelche Berechtigungen übersehen?

Teriber habe ich bereits alle nachinstalliert, das Programm natürlich auch :-)

 

Es klappt mit dem selben User auf allen anderen PCs/Servern problemlos. Meine Vermutung liegt ja an er 64bit Problematik, aber dann hätte es ja von Beginn an Probleme geben müssen?!

 

Vielleicht habt ihr ja eine Idee.

 

Gruß und Danke

[Sunny61 806]

SQL Server: MS Server 2003 R2 mit SQL 2005

Terminalserver: MS Server 2008 R2

 

auf dem Terminalserver ist ein Programm installiert, das mittels ODBC auf den SQL Server zugreift. Nach der Installation des Programms werden auch die System-DSN angelegt, sieht alles gut aus.

Das hat jetzt ca. 6Monate problemlos funktioniert, nun aber können alle Benutzer (außer der Admin) sich nicht mehr mit dem SQL Server verbinden. Die Meldung (Original, nicht gekürzt):

 

"Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber an"

 

warum die Meldung abgeschnitten wird ist ne andere unerklärliche sache .. aber nunja.

Markiere die Messagebox und drück einfach STRG + C. Jetzt Notepad öffnen und STRG + V drücken. Möglicherweise hast Du jetzt die vollständige Fehlermeldung. Auf jeden Fall ist das eine Meldung des Softwarehersteller, den solltest Du auf alle Fälle ins Boot nehmen.

 

Verändert wurde in der Zeischenzeit garnichts. Weder Programme installiert noch Updates oder sonst was.

Gefährlich 6 Monate keine Updates zu installieren.

 

Die User selbst können die System-DSN natürlich nicht bearbeiten.

Können die User denn eine User-DSN erstellen und damit weiter arbeiten? Was sagt der Hersteller der uns unbekannten Software zu dem Problem?

[webmaschder 10]

Hi,

danke für die promte Antwort.

 

Den Text habe ich schon per STRG + C kopiert, man ist ja von Haus aus faul ;-)

 

User-DSN kann ich zwar erstellen, aber beim Verbindungstest bricht er ab (Fehler bei der Anmeldung). Lege ich den Eintrag trotzdem kann, kann ich das Programm trotzdem nicht starten.

Das gleiche kommt aber auch, wenn ich das mit dem Admin ausführe. Habe es deshalb nie beachtet.

Den Softwarehersteller habe ich schon kontaktiert: "geht uns nix an, das muss am Server oder am SQL Server liegen. Mit dem Admin gehts ja auch!" ...

 

ziemlich kuriose Situation

 

EDIT: habe die AD-Berechtigungen noch mit aufgenommen. Jetzt kann ich zwar im ODBC Manager die Verbindung erfolgreioch aufbauen, sobald ich aber das Programm starte kommt wieder der gleiche Fehler.

bearbeitet 12. Februar 2013 von webmaschder

[Sunny61 806]

Den Softwarehersteller habe ich schon kontaktiert: "geht uns nix an, das muss am Server oder am SQL Server liegen. Mit dem Admin gehts ja auch!" ...

Wow, tolle Antwort. IMHO solltest Du das bei euch in der Firma eskalieren, hier ist Unterstützung des SW-Herstellers nötig.

 

EDIT: habe die AD-Berechtigungen noch mit aufgenommen. Jetzt kann ich zwar im ODBC Manager die Verbindung erfolgreioch aufbauen, sobald ich aber das Programm starte kommt wieder der gleiche Fehler.

Vermutlich ist im Programm hart die Verwendung von Sytem-DSN eingestellt, da kommst Du ohne Unterstützung vom Hersteller nicht weiter.

 

Probier doch für einen Testbenutzer ein neues TS-Profil, evtl. hakt es ja daran. Ist ein AV-Scanner installiert? Wenn ja, deinstallieren, rückstandsfrei. Hast Du den TS schon neu gestartet?

[webmaschder 10]

Hi,

ja, ziemlich nervig... aber sowas dachte ich mir schon.

 

TS ist neu gestartet, bei einem User habe ich das Profil schon neu erstellt. Gestern habe ich auch einen neuen Testuser angelegt, entsprechend berechtigt und getestet .. immer das gleiche.

Virenscanner habe ich auch schon deaktiviert, deinsallieren geht leider gerade nicht. Kann ich aber heute nacht mal versuchen. Allerdings verspreche ich mir davon nicht wirklich viel.

 

Scheint mir so, als ob der User die System-DSN garnicht lesen darf?! Gibts da irgendwelche besonderen Berechtigungen?

Die Reg Einträge habe ich testweise auch schon einzeln berechtigt und sogar für den Testuser entsprechend neu angelegt bzw. kopiert.

 

gruß

[Sunny61 806]

ja, ziemlich nervig... aber sowas dachte ich mir schon.

Eskalieren, eskalieren und nochmal eskalieren. Schalte eure Geschäftsführung ein.

 

 

 

Scheint mir so, als ob der User die System-DSN garnicht lesen darf?! Gibts da irgendwelche besonderen Berechtigungen?

Die Reg Einträge habe ich testweise auch schon einzeln berechtigt und sogar für den Testuser entsprechend neu angelegt bzw. kopiert.

 

Du kannst mit dem Prozessmonitor mitsniffen, evtl. findest Du Hinweise.

[DavidS 11]

Hallo Webmaschder,

 

füge doch zu Testzwecken einen der Anwender in die lokale Benutzergruppe der Administratoren an dem SQL Server hinzu.

 

Melde diesen Benutzer dann von dem Terminalserver ab sollte dieser in der Zwischenzeit angemeldet sein und melde dich erneut am TSR an damit die erhöhten Rechte greifen.

 

Klappt der ODBC Aufruf dann ?

[webmaschder 10]

Hi zusammen,

 

danke für die Tipps. Ich habe das Problem in einer langen Nachtschicht nun endlich gelöst.

Ich hatte zuerst die Hinweise von DavidS geprüft, das hat aber leider nicht geklappt.

 

Anschließend habe ich mir doch die Mühe gemacht und die sämtliche Bewegungen des Programms mit dem File/RegMon analysiert. Anscheinden greift das Programm auf einen zusätzlichen Pfad in der Reg. zu auf das der User eben keine Berechtigung hat. Das erklärt auch, warum es nur auf dem TS nicht läuft, auf allen anderen PCs aber schon. Auf dem TS gelten andere Sicherheitsrichtlinien...

Habe den besagten Schlüssel berechtigt und das Programm eine neue DSN anlegen lassen => läuft!

 

Total verrückt das ganze. Ich überlege mir gerade ob ich die Infos überhaupt an den Softwarehersteller weitergeben soll.... bei dem Verhalten das die an den Tag legen...

 

Danke an alle.

 

Gruß

[Sunny61 806]

 

danke für die Tipps. Ich habe das Problem in einer langen Nachtschicht nun endlich gelöst.

Freut mich für Dich und Danke für die Rückmeldung. ;)

Total verrückt das ganze. Ich überlege mir gerade ob ich die Infos überhaupt an den Softwarehersteller weitergeben soll.... bei dem Verhalten das die an den Tag legen...

Frag doch nach, was ihnen die Information wert ist. :)

[webmaschder 10]

Frag doch nach, was ihnen die Information wert ist. :)

 

So ähnlich werde ich das wohl machen :-)

Habe mal eine E-Mail an den zuständigen Mitarbeiter geschickt und CC an den GF von dem Laden ... wird schon den richtigen treffen!

Die werden das dann schon unter sich klären. Immerhin haben wir einen Vertrag mit der Firma und einfach irgendwelche Zugriffe von dem Programm auf das System zu ändern oder neue einzubinden geht halt nicht. Das muss mit uns abgesprochen werden, so stehts da schwarz auf weiß.

 

Wahrscheinlich kann ich ne Rechnung wegen Nutzungsausfall stellen, wär ja immerhin ein Anfang.

 

Gruß

[Sunny61 806]

Kannst ja Bescheid geben was dabei heraus gekommen ist. ;)