Windows 7 (64Bit) und die Installation von Treibern

[rch]

Hallo zusammen,

ich war gestern dabei ein Paket für einen SSL VPN Client (ein MSI Paket) für Empirum zu schnüren. Nachdem die ersten Probleme gelöst waren habe ich es auf einem meiner Testclients ausgerollt (Windows 7 Enterprise x64).

Da bei der Installation des MSI Paketes (ist noch ein 32Bit MSI) "unsignierte" Treiber mit installiert werden, bringt Windows eine Userabfrage.

Der Anwender soll entweder die Installation der Treiber bestätigen oder ablehnen. Wenn man die Installation bestätigt funktioniert alles wunderbar.

Allerdings ist diese Meldung so ziemlich unerwünscht wie man sich nur vorstellen kann.

Selbiges passiert im übrigen auch zum Beispiel bei der Installation von Freepdfxp!

Daher habe wüsste ich gerne ob jemand einen Tipp hat wie man diese Meldung gänzlich im Betriebssystem abschalten kann.

Ich habe in den Gruppenrichtlinien schon einen Eintrag gefunden.

(gpedit.msc -> Benutzerkofiguration -> Administrative Vorlagen -> System -> Treiberinstallation: "Codesignatur für Gerätetreiber" => Aktiviert, "Ignorieren")

Diesen habe ich auch per Gruppenrichtlinie so justiert, allerdings ohne Erfolg. Die Meldung erscheint immernoch.

Und ja, ich habe per GPRESULT überprüft ob die Richtlinie greift.

Würde mich über Tipps freuen.

Danke im voraus.

[Hendrik_Ambrosius]

Hilft es wenn vorher dieser RegKey auf 0 gesetzt wird?

HKLM,"SOFTWARE\\Microsoft\\Driver Signing","Policy",0x00000001,00,00,00,00

[rch]

Danke für den Tipp!
Das probiere ich am Montag aus. Ich vermute jedoch, dass es funktionieren wird! Die GPO scheint wohl doch funktioniert zu haben. Nur haben wir nach dem ersten anmelden (ist ja eine GPO im Userkontext) nicht mehr neu gestartet. Und wie wir alle Wissen benötigen einige GPOs einen Neustart.

[rch]

So, leider funktioniert der besagte Registry Key auch nicht.
Ich bin langsam am verzweifeln und zwar genausowenig die die Gruppenrichtlinie über die Domäne!

Die lokal gesetzte Gruppenrichtlinie (per gpedit.msc) fördert folgenden Key zu Tage:

HKCU,"Software\Policies\Microsoft\Windows NT\Driver Signing","BehaviorOnFailedVerify",0x00010001,0

Allerdings funktioniert dieser wie gesagt erst nach einem Neustart und kann daher nicht sofort eingesetzt werden.

Ich probiere jetzt mal den neueren Client und hoffe, dass dieser a) mit unserer SSL VPN Appliance läuft und b) dieses Problem eventuell beseitigt wurde vom Hersteller.

[philipp.kiessler]

Viel Glück.
Mir würde da jetzt noch einfallen, das Paket so aufzubauen, dass ein zwei Teilen Arbeitet. Erstmal prüft es, ob der Key für das Treiber Signing so gesetzt ist, wie es ihn braucht. Ist das nicht der Fall, kommt Teil 1 ins Spiel. Hier setzt es diesen Key, trägt einen AutoAdminLogon ein, löst einen Reboot aus und bricht das Script ab.
Nach dem Neustart wird Empirum das Paket nochmal ausgeführen. Dann ist festzustellen, dass das Driver Signing das Richtige Verhalten zeigt. Das Setup wird durchgeführt und - wenn vorhanden - werden AutoAdminLogon-Keys gelöscht. Vielleicht sollte das Script selbst eine "Markierung" hin der Registry hinterlassen, ob es den AutoAdminLogon überhaupt selbst eingetragen hat, um nicht andere Programme / Mechanismen zu zerschießen.

Wobei der neue Client, wenn er tut, was er soll, die sauberste Lösung wäre...

[rch]

So, mit dem neuen Client funktioniert es zumindest unter Windows 7 (x86)!
Auf dem 64 Bit Windows 7 muss ich es noch testen.

Allerdings habe ich das gleiche "Treiberproblem" mit Freepdf.

Auch die aktuellste Version zickt hier herum.

Haben auch schon andere bemerkt (http://www.freepdfxp.de/Forum/article.p ... re.freepdf).

Hier scheint eine "unattended" Installation im Augenblick in weiter ferne zu sein.

[Moeki]

Ich würde versuchen, mittels der Aktivierung der Protokollierung von MSI-Installationen (Administrative Gruppenrichtlinie) die Installation bzw. die übergebenen Parameter mitzuschneiden und das ganze durch entsprechende Einzelaufrufe nachzustricken. Neuerdings würde ich auch zum Packagerobot raten.

[rch]

Also Packagerobot fällt aus weil wir keine Lizenzen dafür haben.
Davon abgesehen ändert auch das Mitschneiden der Parameter bzw. Aufrufe nix an dem Problem. Denn die Meldung erscheint ja auch beim manuellen ausführen des Setup.

Das Problem hat also nur indirekt mit Empirum zu tun!
Es ist ein Windows 7 "Problem". Denn MS meint mal wieder dem User (der nicht zertifizierte Software/Treiber einsetzt) das Leben schwer machen zu müssen...

Ich bin übrigens nicht alleine mit dem Registry Problem. Hab sogar im Technet Leute gefunden die Probleme hatten bei Win 7 das Driver Signing zu deaktivieren...

[Bela]

Das Problem mit Windows 7 (32Bit) und FreePDF 4.02 haben wir auch. FreePDF bringt einen eigenen, unsignierten Treiber mit. Es kommt das Warnfenster mit der Treibersignierung. Auch wir haben versucht, per GPO die Warnmeldung zur Treibersignierung auszuschalten, aber ohne Erfolg.

Das Problem ist vermutlich folgendes: Das Verhalten der Treibersignierung lässt sich per GPO nur in der Benutzerkonfiguration (!) setzen. Damit diese Einstellung wirkt, müsste FreePDF als User installiert werden, was mangels Admin-Rechte nicht geht. Wir benutzen den Advanced-Agent. Der Dienst ERIS läuft anscheinend immer mit "Local System" Rechten, das ERIS_UI unter dem aktuell angemeldeten User. Wird also die Installation von FreePDF im Maschinenteil mit Local System Rechten ausgeführt, greift natürlich die GPO nicht, die die Treibersignierungswarnung ausschaltet. Wie auch, der "User" Local System bekommt dieses GPO nicht zugewiesen.

Besser wäre es, wenn Microsoft das Verhalten der Treibersignierung in die Computerconfiguration gelegt hätte, dann würde die Einstellung unabhängig vom User gelten und wir hätten das Problem nicht.

Gibt es schon neue Erkenntnisse?

Gruß
Bela

[rch]

Nein, Besserung ist leider in keiner Hinsicht zu erwarten.
In unserem konkreten Fall weder von Kyocera noch von Freepdf noch von Microsoft: http://social.technet.microsoft.com/For ... red&ppud=4

Ich werde jetzt nochmal eine Mail an den Kyocera Support schreiben und signierte Treiber verlangen. Vielleicht kriege ich dann wenigstens diese Kuh vom Eis.

Für Freepdf bin ich am überlegen ein AutoIT Script zu basteln.

[Bela]

Das mit AutoIT habe ich mir auch schon überlegt. Es ist die Frage, ob man auf dieses System-Warnfenster mit AutoIT überhaupt zugreifen kann. Muss ich noch ausprobieren.

Das Problem mit den AutoIT-Skripten, die auf Fenster reagieren, ist wahrscheinlich, dass ein solches Paket nicht während der Anmeldemaske installiert werden kann? Denn dann kommt kein Warnfenster zum Vorschein, auf das man reagieren kann, oder?

Gruß
Bela

[Rene]

Es gab seinerzeit bei Windows XP den commandline dpinst.exe. Damit konnte man Treiber signiert oder unsigniert Windows bekanntmachen, unattended. Für Windows 7 soll es wohl sowas auch geben. Habs aber selber noch nicht getestet: http://msdn.microsoft.com/en-us/library/ms790308.aspx bzw. dpinst commandline hier: http://msdn.microsoft.com/en-us/library/ms790806.aspx

[rch]

Es gab seinerzeit bei Windows XP den commandline dpinst.exe. Damit konnte man Treiber signiert oder unsigniert Windows bekanntmachen, unattended. Für Windows 7 soll es wohl sowas auch geben. Habs aber selber noch nicht getestet: http://msdn.microsoft.com/en-us/library/ms790308.aspx bzw. dpinst commandline hier: http://msdn.microsoft.com/en-us/library/ms790806.aspx

Wenn das funktioniert, an wen darf ich dann eine Flasche Sekt schicken?

[Rene]

Ich kann das net unterschreiben, obs für Windows 7 auch geht. Der Fall bei dir ist ja noch, dass man die Treiber erstmal irgendwo rausholen muss aus der Applikation. Bin mal gespannt, ob es geht. Viel Glück.

[Bela]

Der Druckertreiber liegt z.B. bei FreePDF einzeln im Source (freepdfxp.inf mit freepdfxp.ppd). Vielleicht kann man diesen Treiber tatsächlich mit dpinst irgendwie ins System bringen...