Hallo liebe Leute,
ich möchte gerne mit Windows-Bordmitteln eine ODBC-Systemdatenquelle per GPO-Richtlinie verteilen.
Umgebung: Server sind 2008R2 (64bit!), die Clients sind Vista/Win7 32 bit. Datenbank Pervasive SQL (sollte aber keine Rolle spielen), Client dafür ist installiert.
Ich verwende eine Computer-Richtlinie.
Folgende Hürden habe ich bereits genommen:
-> Unterscheidung 64/32 Bit auf dem Server, durch Verwenden von odbcad32 und gpmc aus dem SysWOW64-Verzeichnis
-> bug/feature bzgl Benutzername und Passwort:
- Datenbankquelle im gpmc heranziehen
- Eintrag per D&D herausziehen
- im Editor die Einträge für cpassword= und username= entfernen
- Datenbankquelle im gpmc löschen
- geändertes xml per D&D in die gpmc ziehen
Ich habe die Einträge im sysvol gefunden und überprüft, hier steht alles wie ich es vorgegeben habe.
Wenn die GPO jetzt angewendet wird, wird die Datenquelle leider nicht eingefügt, vielmehr erhalte ich im Syslog -> Application die Meldung:
Source: Group Policy Data Sources, Event-ID: 4098, Das Einstellungselement konnte wegen Fehler 0x80004005 (unbekannter Fehler) nicht übernommen werden.
Ich habe jetzt einige Varianten bezüglich der Parameter durchprobiert. Ich komme immer auf das gleiche Ergebnis. Auch Win7 / Vista als Client machen keine Unterschiede.
Hat jemand vergleichbare Probleme?
Wo kann ich noch nachschauen, was schief läuft?
Ich habe eine xml (exportiert aus dem gpmc) zum Anschauen angefügt.
@NorbretFe:
Ich arbeite mit w2k8R2, ich muß also alles mit admx abdecken. Leider arbeiten diese Werkzeuge auch nicht (richtig), sodaß ich diesen Schritt eigentlich vermeiden wollte.
Außerdem stellt MS diese Funktion ja explizit zur Verfügung. Würde das heißen, daß es da Funktionen gibt, die definitiv überhaupt nicht funktionieren?
@zahni:
Der Hersteller behandelt unter Stichwort ODBC und GPO lediglich das Verteilen seiner Treiber.
Ich glaube das Problem liegt schon etwas früher. Beim Übernehmen der GPO sollte der Treiber eigentlich noch keine Rolle spielen, es handelt sich lediglich um ein paar Einträge in der Registry. Der ODBC-Mechanismus erwartet eine Reihe Parameter, die bei mir offenbar nicht stimmen. Wird irgendwo dokumentiert, welche Parameter MS erwartet, welche Werte sie annehmen dürfen und was gar nicht tut?
@NorbretFe:
Ich arbeite mit w2k8R2, ich muß also alles mit admx abdecken.
Aha, wer sagt das?
Leider arbeiten diese Werkzeuge auch nicht (richtig), sodaß ich diesen Schritt eigentlich vermeiden wollte.
Wieso funktionieren diese Werkzeuge (welche denn?) nicht (richtig)?
Außerdem stellt MS diese Funktion ja explizit zur Verfügung. Würde das heißen, daß es da Funktionen gibt, die definitiv überhaupt nicht funktionieren?
Aha. Ich meine mich zu erinnern, dass ich schon häufiger von Problemen mit der ODBC ANlage und GPP gelesen zu haben.
sollte der Treiber eigentlich noch keine Rolle spielen, es handelt sich lediglich um ein paar Einträge in der Registry.
Weswegen die Anlage per adm wahrscheinlich auch schneller und zuverlässiger funktionieren sollte, als GPP, die bei dir anscheinend gar nicht funktioniert.
Ich arbeite mit w2k8R2, ich muß also alles mit admx abdecken.
Aha, wer sagt das?
Mr. Boddenberg sagt, daß ADMs nur sehr eingeschränkt funktionieren und man lieber auf ADMX ausweichen soll. Da ich mit beiden Varianten nicht allzu firm bin, habe ich mich gleich an ADMX gehalten. Ich verspreche mir davon, daß das erworbene KnowHow länger hält.
Leider arbeiten diese Werkzeuge auch nicht (richtig), sodaß ich diesen Schritt eigentlich vermeiden wollte.
Wieso funktionieren diese Werkzeuge (welche denn?) nicht (richtig)?
Der überall angepriesene ADMX-Migrator, erstellt von FullArmor und vertrieben von Microsoft, der seit Jahren in der Version 1.3 zuverlässig alle Value-Werte aus einer ADMX-Datei entfernt und diese damit in kürzester Zeit unbrauchbar macht.
Wenn man erst eine ADMX-Datei hat, funktioniert alles wunderbar, sofern man nicht gerade den einen Datentyp (ich glaube das war Int) in der Registry braucht, der in diesem Konzept nicht unterstützt wird.
ODBC und MS war schon immer spannend. Das weiß ich auch aus meinen Programmierzeiten. Ich bin mir aber sicher, daß ich, wenn ich Kenntnis über die richtigen Parameter erlange, dieses Problem zügig über GPP lösen könnte. Ich zweifle aber, daß ich in dieser Richtung zeitnah Erfolg haben werde.
Mein nächster Schritt wird, sofern in diesem Board nicht noch ein durchschlagender Einfall publiziert wird, sein, mir, entsprechend Deinem Rat, mit dem ADMX-Migrator ein ADMX-Gerüst zu bauen, das manuell mit einem Editor mit Werten gefüllt wird.
Die letzte Alternative, nämlich per Skript bei jedem Hochfahren die Einträge aus einer .reg-Datei zu setzen, möchte ich vermeiden, da beim Hochfahren schon genug Skripte laufen. Ich muß auch an meine User denken und will nicht für ihre Koffeinsucht verantwortlich sein.
Trotz allem vielen Dank.
Martin
Eins ist sicher: Ich werde länger leben als Windows.
Mr. Boddenberg sagt, daß ADMs nur sehr eingeschränkt funktionieren und man lieber auf ADMX ausweichen soll.
Sollte ich den kennen? Und das einzige was bei ADMs nur eingeschränkt (nämlich gar nicht) funktioniert ist der Central Store und ein Datenformat. Für dich in diesem Fall vollkommen irrelevant. Wieviel Know How hast du denn im ADMX schreiben inzwischen erworben? Denn für das Prinzip ist adm schreiben einfacher zu lernen und funktioniert definitiv. ADMX Schreiben, da kenne ich niemanden, der auch nur annähernd so ein Teil per Hand zusammenklimpern kann. Und auch mit Tools wirds schwierig z.T.
Der überall angepriesene ADMX-Migrator, erstellt von FullArmor und vertrieben von Microsoft, der seit Jahren in der Version 1.3 zuverlässig alle Value-Werte aus einer ADMX-Datei entfernt und diese damit in kürzester Zeit unbrauchbar macht.
Das Ding funktioniert hier mehr buggy als gut. Und ich wollte wissen, welche Werkzeuge nicht funktionieren, so dass du nicht mit adms arbeiten kannst.
Wenn man erst eine ADMX-Datei hat, funktioniert alles wunderbar, sofern man nicht gerade den einen Datentyp (ich glaube das war Int) in der Registry braucht, der in diesem Konzept nicht unterstützt wird.
Ja, das ist leider sowohl bei admx als auch bei adm Dateien der Fall (binary wars übrigens). Aber wie gesagt, für sowas gibts notfalls noch die GPP oder andere Methoden. Für dein Problem aber total irrelevant.
Ich persönlich würd mir die Arbeit mit admx sparen. Das Ergebnis rechtfertigt nicht die Zeit, die man üblicherweise gegenüber adms verbraucht.
Bye
Norbert
PS: Zum Konvertieren von adm zu admx schau lieber bei sysprosoft. Die können das nämlich.
Ich habe das gleiche Problem mit der Erstellung der DSNs via GPO. Auch halfen die im Internet gängigen Lösungsvorschläge (user und pass aus XML löschen) nicht. Ich habe mir dann mit einem VBA Makro geholfen, die ich in unsere Access-Frontends eingebaut habe.
So, ich habe jetzt eine Lösung gefunden. Für alle, die über Google über diesen Thread stolpern:
- die System-DSN finden sich unter:
HKLM\SOFTWARE\ODBC\ODBC.INI\<Datenbankname>
HKLM\SOFTWARE\ODBC\ODBC.INI\ODBC DATA SOURCES
idealerweise legt man sich über die Systemsteuerung einmal diese Quelle an und schaut nach, was dort genau steht.
Dann habe ich mir einfach ein .msi erstellt, das diese Schlüssel setzt. Dieses msi verteile ich über die Windows-Softwareverteilung.
Damit gehts jetzt.
Viel Erfolg!
Martin
