Jump to content

OCX-Datei via GPO verteilen und registrieren


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

Hallo zusammen,

 

hier nun der dritte und letzte Teil meiner aktuellen GPO-Fragen. Nachdem nun die Verteilung des Zertifikates dank des virtuellen Win7-Admin-PCs geklappt hat, muß ich nun noch eine PCX-Datei (msinet.ocx) auf die Zielrechner bringen und dort auch registrieren. Diesmal habe ich sowohl unter gruppenrichtlinien.de als auch via Google schon gesucht und nichts gefunden (außer über ein Startup-Script mit regsvr32).

 

Ist das wirklich die einzige Lösung, oder geht das auch direkt über ein GPO?

 

 

Danke im Voraus,

Sarek

Link to comment

Msi Datei ginge afaik auch. Aber startup Skript ist einfacher. ;)

Heißt das, selbst die moderne GPMC von Windows 7 / Server 2008 hat da keine eingebaute Lösung? Naja, das haben sich die MS-Strategen wohl für die GPMC von Windows 8 / Server 2012 aufgespart, damit die Leute sich brav wieder die neuen Softwareversionen kaufen, die sonst keiner bräuchte :-)

Edited by Sarek
Link to comment

Nein, auch in 8 8.1 geht's afaik nicht.

OK, dann sparen die das noch ein bißchen länger auf. Ist sicher eine rein strategische Überlegung, genauso, wie es sicher eine strategische Überlegung war, die Verteilung von Zertifikaten für "Vertrauenswürdige Herausgeber" noch nicht bei Server 2003 einzubauen, obwohl es die Problemstellung doch auch damals schon gab.

 

Aber noch mal zurück zur MSI-Datei. Das ist vielleicht gar keine dumme Idee. Klar, nur für die OCX-Registrierung mag ein Script einfacher sein, aber mit der MSI-Datei könnte ich eigentlich den gesamten Setup-Vorgang zusammenfassen, also die Verteilung der Dateien (die ich bisher einfach per Freigabe c$ auf die Zielrechner geschoben habe), die Eintragung der Registry-Keys, die Registrierung der OCX-Datei und vielleicht sogar, wenn MSI das unterstützt, die Verteilung des Code-Zertifikates. Ich kenne als kostenlosen MSI-Editor eigentlich nur das WinInstall Lite, aber das hat ja nun auch schon ein paar Jahre auf dem Buckel. Gibt es da was aktuelleres?

Link to comment

Je nach Anforderung, und in diesem Fall ist die Anforderung nicht besonders hoch, würde ich selbst eine kleine EXE in Visual Studio erstellen, dazu reicht IMHO auch eine kostenlose Express Version aus.

 

Visual Studio habe ich ja ... zumindest die alte 6er-Version. Aber um sich da etwas selber zu schreiben, braucht man meines Erachtens eine ganze Menge Hintergrundwissen. Man muß ja zum Beispiel wissen, wie eine OCX-Datei registriert wird, um diesen Vorgang selber in einem (z.B. Basic-)Programm nachbilden zu können. Oder meintest Du nur eine EXE, die über die Shell-Funktion die entsprechenden Kommandozeilen-Tools auf dem Zielrechner aufruft? Das kann man natürlich schnell hinbasteln, aber es gilt dann immer noch der Kritikpunkt in meinem letzten Absatz unten.

 

 

 

Hm, da konnte ich jetzt nicht so viel rausziehen. Bemerkenswert fand ich aber den Satz "Generell ist die Softwareverteilung per GPO nicht empfohlen". Ich war bisher immer der Meinung, daß das "State of the Art" für die Installation von Programmen in Domänennetzwerken ist ...

 

Ein Script hat meines Erachtens gegenüber der MSI/GPO-Variante den Nachteil, daß das Script bei jedem Start des PCs wieder ausgeführt wird, auch wenn nach dem ersten Durchlauf das zu installierende Programm längst auf dem Zielrechner vorhanden ist. Das ist eine unschöne Verzögerung des Bootvorgangs ...

Edited by Sarek
Link to comment

Hm, da konnte ich jetzt nicht so viel rausziehen. Bemerkenswert fand ich aber den Satz "Generell ist die Softwareverteilung per GPO nicht empfohlen". Ich war bisher immer der Meinung, daß das "State of the Art" für die Installation von Programmen in Domänennetzwerken ist ...

Du bist ja auch der Meinung, dass man mit einer alten GPMC im Jahr 2013 gut bedient ist. ;)

 

Ein Script hat meines Erachtens gegenüber der MSI/GPO-Variante den Nachteil, daß das Script bei jedem Start des PCs wieder ausgeführt wird, auch wenn nach dem ersten Durchlauf das Programm längst auf dem Zielrechner installiert ist. Das ist eine unschöne Verzögerung des Bootvorgangs ...

Das schöne an einem Skript ist, man kann da eine Abbruchbedingung einfach reinschreiben. ;)

 

Bye

Norbert

Link to comment

Du bist ja auch der Meinung, dass man mit einer alten GPMC im Jahr 2013 gut bedient ist. ;)

 

Die Frage ist dabei ja eher, warum Microsoft die Funktionen, die schon vor zehn Jahren notwendig gewesen wären, erst pö a pö in immer neuen Serverversionen umsetzt. Wie gesagt, ich halte das ganze für ein reines Verkaufsförderungsprogramm. Hätte die GPMC von Server 2003 schon alles unterstützt, was im Jahr 2003 wichtig war (eben auch die Verteilung von Codezertifikaten, die es damals ja schon gab), dann würde in der Tat eine alte GPMC für meine Zwecke völlig ausreichend sein.

 

 

Das schöne an einem Skript ist, man kann da eine Abbruchbedingung einfach reinschreiben. ;)

 

Na, aber trotzdem muß das Script erst mal aufgerufen und teilweise ausgeführt werden, um zu erkennen, daß die Abbruchbedingung erfüllt ist (z.B. durch Auslesen eines Schlüssels aus der Registry). Und man hat eben nicht alles unter einem Dach. Es wäre doch viel schöner (auch für die Dokumentation des Servers), wenn alles zentral im AD geregelt wird, statt dass man da Verknüpfungen auf irgendwelche außerhalb liegenden Scripts reinschreibt.

Link to comment

 

Die Frage ist dabei ja eher, warum Microsoft die Funktionen, die schon vor zehn Jahren notwendig gewesen wären, erst pö a pö in immer neuen Serverversionen umsetzt.

Ja klar, ein Airbag war auch 1950 schon notwendig gewesen, gibt's aber serienmässig auch erst seit 1980. :rolleyes:

Wie gesagt, ich halte das ganze für ein reines Verkaufsförderungsprogramm. Hätte die GPMC von Server 2003 schon alles unterstützt, was im Jahr 2003 wichtig war (eben auch die Verteilung von Codezertifikaten, die es damals ja schon gab), dann würde in der Tat eine alte GPMC für meine Zwecke völlig ausreichend sein.

Hätte wenn und aber. ;)

Na, aber trotzdem muß das Script erst mal aufgerufen und teilweise ausgeführt werden, um zu erkennen, daß die Abbruchbedingung erfüllt ist (z.B. durch Auslesen eines Schlüssels aus der Registry). Und man hat eben nicht alles unter einem Dach. Es wäre doch viel schöner (auch für die Dokumentation des Servers), wenn alles zentral im AD geregelt wird, statt dass man da Verknüpfungen auf irgendwelche außerhalb liegenden Scripts reinschreibt.

Dann bau nen .msi und verteils per WSUS.

 

Bye

Norbert

Link to comment

Visual Studio habe ich ja ... zumindest die alte 6er-Version. Aber um sich da etwas selber zu schreiben, braucht man meines Erachtens eine ganze Menge Hintergrundwissen. Man muß ja zum Beispiel wissen, wie eine OCX-Datei registriert wird, um diesen Vorgang selber in einem (z.B. Basic-)Programm nachbilden zu können. Oder meintest Du nur eine EXE, die über die Shell-Funktion die entsprechenden Kommandozeilen-Tools auf dem Zielrechner aufruft? Das kann man natürlich schnell hinbasteln, aber es gilt dann immer noch der Kritikpunkt in meinem letzten Absatz unten.

Ich meinte die einfache Variante. In der EXE wird der Aufruf zusammengestellt und an die Commandline übergeben. So etwas wie hier: http://www.vbarchiv.net/forum/read.php?f=2&i=98860&t=98846

Allerdings nehme ich kein VB6 mehr her, die Zeit ist vorbei, mit .Net geht vieles um Welten einfacher. Und das Framework ist ja bei den W7-Maschinen auch schon vorhanden.

 

 

Hm, da konnte ich jetzt nicht so viel rausziehen. Bemerkenswert fand ich aber den Satz "Generell ist die Softwareverteilung per GPO nicht empfohlen". Ich war bisher immer der Meinung, daß das "State of the Art" für die Installation von Programmen in Domänennetzwerken ist ...

Hmm, überleg mal warum das nicht mehr empfehlenswert ist. Sieh dir WPP mit WSUS an, ist viel umfangreicher, mächtiger und bietet auch super Reporting. Auf http://www.wsus.de/lup gibt es ein paar HowTos zu dem Thema.

 

Eine ZAP Datei hast Du recht schnell erstellt, schon kannst Du das ausrollen. In diesem Fall würde ich allerdings lieber eine EXE in .Net erstellen, Fehlermeldungen gleich ins Eventlog schreiben oder mit einem passenden zusätzlichen Modul gleich Mails verschicken. ;)

Ein Script hat meines Erachtens gegenüber der MSI/GPO-Variante den Nachteil, daß das Script bei jedem Start des PCs wieder ausgeführt wird, auch wenn nach dem ersten Durchlauf das zu installierende Programm längst auf dem Zielrechner vorhanden ist. Das ist eine unschöne Verzögerung des Bootvorgangs ...

Nein, auch das muß nicht sein. Lies doch dieses Posting: http://www.mcseboard.de/topic/168705-regkey-per-batch-abfragen/?p=1037595

Link to comment
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...