Windows 7 (64Bit) und die Installation von Treibern

rch
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Windows 7 (64Bit) und die Installation von Treibern

Beitrag von rch » 14. Jan 2010, 16:29

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. ;) :D

Würde mich über Tipps freuen.

Danke im voraus.
Gruß
René
---
Empirum Pro V15.1 Patch 9, DB Version 6.11, SQL 2012, Server 2012 (x64)
Airwatch 7.3 FP08, SQL 2012, Server 2012 R2 (x64)

Benutzeravatar
Hendrik_Ambrosius
Moderator
Moderator
Beiträge: 7552
Registriert: 13. Dez 2004, 23:10
Wohnort: Adendorf/Lüneburg

Beitrag von Hendrik_Ambrosius » 14. Jan 2010, 17:29

Hilft es wenn vorher dieser RegKey auf 0 gesetzt wird?

HKLM,"SOFTWARE\\Microsoft\\Driver Signing","Policy",0x00000001,00,00,00,00
Hendrik Ambrosius / Senior Consultant
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 AG | Elbinger Straße 7 | 60487 Frankfurt am Main | Germany | www.matrix42.com

Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG or of the support team.

rch
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Beitrag von rch » 14. Jan 2010, 21:23

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
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Beitrag von rch » 18. Jan 2010, 09:13

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
Beiträge: 248
Registriert: 05. Feb 2007, 11:42
Kontaktdaten:

Beitrag von philipp.kiessler » 18. Jan 2010, 11:58

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...
Philipp Kießler

rch
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Beitrag von rch » 18. Jan 2010, 15:40

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
Beiträge: 212
Registriert: 06. Feb 2006, 14:22
Kontaktdaten:

Beitrag von Moeki » 18. Jan 2010, 18:29

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
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Beitrag von rch » 18. Jan 2010, 21:10

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
Beiträge: 78
Registriert: 04. Jan 2005, 11:15
Kontaktdaten:

Beitrag von Bela » 02. Mär 2010, 14:23

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
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Beitrag von rch » 02. Mär 2010, 14:39

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.
Gruß
René
---
Empirum Pro V15.1 Patch 9, DB Version 6.11, SQL 2012, Server 2012 (x64)
Airwatch 7.3 FP08, SQL 2012, Server 2012 R2 (x64)

Bela
Beiträge: 78
Registriert: 04. Jan 2005, 11:15
Kontaktdaten:

Beitrag von Bela » 02. Mär 2010, 14:54

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
Beiträge: 474
Registriert: 26. Mai 2005, 11:16
Wohnort: Zürich
Kontaktdaten:

Beitrag von Rene » 02. Mär 2010, 15:06

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
Beiträge: 152
Registriert: 07. Dez 2006, 08:12
Wohnort: Eschborn
Kontaktdaten:

Beitrag von rch » 02. Mär 2010, 15:18

Rene hat geschrieben: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? :D
Gruß
René
---
Empirum Pro V15.1 Patch 9, DB Version 6.11, SQL 2012, Server 2012 (x64)
Airwatch 7.3 FP08, SQL 2012, Server 2012 R2 (x64)

Rene
Beiträge: 474
Registriert: 26. Mai 2005, 11:16
Wohnort: Zürich
Kontaktdaten:

Beitrag von Rene » 02. Mär 2010, 15:31

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
Beiträge: 78
Registriert: 04. Jan 2005, 11:15
Kontaktdaten:

Beitrag von Bela » 02. Mär 2010, 15:40

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...

Antworten

Zurück zu „Paketierung“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste