3
SQL Anywhere 12 ODBC-Treiber verteilen
Für eine unserer Anwendungen muss ich den ODBC-Treiber verteilen und eine Benuter-DSN generieren - und beisse bald in die Tischkante...
Moin zusammen,
vom Hersteller der von uns verwendeten Software habe ich eine MSI-Datei erhalten, die bei manueller Ausführung den SQL Anywhere ODBC-Treiber in Version 12 installiert und dann ein zweites Setup startet, welches dann eine Benutzer-DSN für den Zugriff auf den Datenbankserver einrichtet. Soweit, so gut.
Der Treiber muss nun auf > 200 Rechnern verteilt und der Benutzer-DSN eingerichtet werden und genau daran beisse ich mir jetzt die Zähne aus. Umgebung:
Windows-Domain mit XP und 7 Clients, SCCM steht zur Verfügung.
Egal, wie herum ich das MSI-Paket verteile (no user logged on, user logged on/user right's), die Installation läuft durch, die Software startet aber nicht, weil der ODBC-Treiber fehlt. Ich vermute hier einen Zusammenhang mit dem "verschachtelten" Setup, kann aber nicht den Finger drauf legen, wo _genau_ ich das Paket anpacken müsste. Habe schon einige Experimente mit InstEd durch, bisher erfolglos.
Das Setup stellt sich so dar:
Ich starte das mir zur Verfügung gestellte MSI-Paket und klicke brav auf Weiter, Weiter, Weiter - am Ende des Setups ist eine Checkbox gesetzt, die nach der Installation des Treibers dann die Konfiguration des DSN startet. Und genau dieser Schritt wird beim Verteilen wohl nicht ausgeführt bzw. im falschen Kontext (Benuzter-DSNs lassen sich halt nur im Benutzerkontext erstellen, weil HKCU).
Ich habe nur den Treiber verteilt und die Registry-Keys per Hand eingefügt, kein Erfolg, Software meckert den fehlenden ODBC-Treiber an. Per MST-File versucht, an das "nur-Treiber-Setup-Paket" die nötigen Informationen ran zu hängen, ebenfalls erfolglos. Mit einem System-DSN funktioniert die Software leider ebenfalls nicht (wäre ja auch zu einfach).
Es muss doch einen Weg geben?
Irgendwer anwesend, der sich mit dem SQL Anywhere Krams besser auskennt und mich mal schubsen kann?
Tausend Dank!
Cheers,
jsysde
vom Hersteller der von uns verwendeten Software habe ich eine MSI-Datei erhalten, die bei manueller Ausführung den SQL Anywhere ODBC-Treiber in Version 12 installiert und dann ein zweites Setup startet, welches dann eine Benutzer-DSN für den Zugriff auf den Datenbankserver einrichtet. Soweit, so gut.
Der Treiber muss nun auf > 200 Rechnern verteilt und der Benutzer-DSN eingerichtet werden und genau daran beisse ich mir jetzt die Zähne aus. Umgebung:
Windows-Domain mit XP und 7 Clients, SCCM steht zur Verfügung.
Egal, wie herum ich das MSI-Paket verteile (no user logged on, user logged on/user right's), die Installation läuft durch, die Software startet aber nicht, weil der ODBC-Treiber fehlt. Ich vermute hier einen Zusammenhang mit dem "verschachtelten" Setup, kann aber nicht den Finger drauf legen, wo _genau_ ich das Paket anpacken müsste. Habe schon einige Experimente mit InstEd durch, bisher erfolglos.
Das Setup stellt sich so dar:
Ich starte das mir zur Verfügung gestellte MSI-Paket und klicke brav auf Weiter, Weiter, Weiter - am Ende des Setups ist eine Checkbox gesetzt, die nach der Installation des Treibers dann die Konfiguration des DSN startet. Und genau dieser Schritt wird beim Verteilen wohl nicht ausgeführt bzw. im falschen Kontext (Benuzter-DSNs lassen sich halt nur im Benutzerkontext erstellen, weil HKCU).
Ich habe nur den Treiber verteilt und die Registry-Keys per Hand eingefügt, kein Erfolg, Software meckert den fehlenden ODBC-Treiber an. Per MST-File versucht, an das "nur-Treiber-Setup-Paket" die nötigen Informationen ran zu hängen, ebenfalls erfolglos. Mit einem System-DSN funktioniert die Software leider ebenfalls nicht (wäre ja auch zu einfach).
Es muss doch einen Weg geben?
Irgendwer anwesend, der sich mit dem SQL Anywhere Krams besser auskennt und mich mal schubsen kann?
Tausend Dank!
Cheers,
jsysde
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 186057
Url: https://administrator.de/contentid/186057
Printed on: April 18, 2024 at 16:04 o'clock
3 Comments
Latest comment
Hi jsysde.
Zunächst: mein Beileid
Was sagt denn der Hersteller zum deployment?
Zu ODBC-Treibern kann ich nur beitragen, dass dies unter x64 oft nicht ohne Weiteres funktioniert.
Mehr kann ich erstmal nicht dazu sagen. Was sagt das Setup-Log? Ist festzustellen, ob der verschachtelte teil überhaupt läuft (also läuft, aber fehlschlägt)?
Zunächst: mein Beileid
Was sagt denn der Hersteller zum deployment?
Zu ODBC-Treibern kann ich nur beitragen, dass dies unter x64 oft nicht ohne Weiteres funktioniert.
Mehr kann ich erstmal nicht dazu sagen. Was sagt das Setup-Log? Ist festzustellen, ob der verschachtelte teil überhaupt läuft (also läuft, aber fehlschlägt)?
Moin DerWoWusste,
Cheers,
jsysde
Zunächst: mein Beileid
Danke. Was sagt denn der Hersteller zum deployment?
Das "verkorkste" MSI-Paket stammt ja direkt vom Hersteller mit dem Hinweis, das Paket eben für jeden User auszuführen.Zu ODBC-Treibern kann ich nur beitragen, dass dies unter x64 oft nicht ohne Weiteres
funktioniert.
Manuell per User ausgeführt tut es das eben doch, auch auf x64-Systemen.funktioniert.
Mehr kann ich erstmal nicht dazu sagen. Was sagt das Setup-Log?
Ist festzustellen, ob der verschachtelte teil überhaupt
läuft (also läuft, aber fehlschlägt)?
Genau das ist das anscheinend das Problem: Der verschachtelte Teil des Setups läuft nicht, selbst dann nicht, wenn ich das Paket per SCCM mit den Optionen "Run only when user is logged on" und "Re-Run for every user that logs on" ausrolle. Und ich konnte keinen Parameter für msiexec finden, der verschachtelte Setups korrekt ausführen würde.Ist festzustellen, ob der verschachtelte teil überhaupt
läuft (also läuft, aber fehlschlägt)?
Cheers,
jsysde
So, dem Hersteller die Hölle heiß gemacht, anständigen "Stand-Alone-Treiber" bekommen und per SCCM verteilt. Reg-Keys für HKCU (die Benutzer-DSN) per "each time a user logs on" auch via SCCM verteilt. Und gut isses.
Cheers,
jsysde
Cheers,
jsysde
