Windows 7 (64Bit) und die Installation von Treibern
Windows 7 (64Bit) und die Installation von Treibern
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.
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.
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)
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)
-
- Moderator
- Posts: 7965
- Joined: 13. Dec 2004, 23:10
- Location: Adendorf/Lüneburg
Hilft es wenn vorher dieser RegKey auf 0 gesetzt wird?
HKLM,"SOFTWARE\\Microsoft\\Driver Signing","Policy",0x00000001,00,00,00,00
HKLM,"SOFTWARE\\Microsoft\\Driver Signing","Policy",0x00000001,00,00,00,00
Hendrik Ambrosius / Senior Presales Consultant
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 GmbH | 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 or of the support team.
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 GmbH | 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 or of the support team.
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.
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.
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.
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.
-
- Posts: 248
- Joined: 05. Feb 2007, 11:42
- Contact:
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...
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
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.
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.
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...
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...
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
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
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.
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)
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)
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
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
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 wrote: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
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)
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)
Who is online
Users browsing this forum: No registered users and 7 guests