Update Installation ohne Adminrechte

[surfer123 10]

Hallo,

 

ich suche für ein Programm ein neues Update-Verfahren:

 

Bei dem Programm handelt es sich um eine Client-Server Umgebung. Die Clients (ca. 150 Stück) sind auf mehrere Geschäftsstellen verteilt, laufen teils auf Windows Vista und teils auf Windows 7, haben eine aktive Benutzerkontensteuerung und kaum Rechte. Sie haben kein Schreiberecht im Windowsverzeichnis und die aktive Benutzerkontensteuerung lässt sich nicht deaktivieren.

 

Gewollt ist, dass das Programmupdate einmal auf den Server eingespielt wird und das Programmupdate für die Clients automatisch durchgeführt wird.

 

Momentan werden die Updates mittels MSI-Pakete und den Benutzerrichtlinien übergeben. Das funktioniert auch soweit ganz gut. Das Problem ist nur, dass die MSI-Pakete ca. 50 – 60 MB groß sind, das Update beim Hochfahren des Clients durchgeführt wird und die Geschäftsstellen der Kunden zum Teil eine miserable Internetverbindung haben und somit die Clients (wenn z.B. 5 Clients gleichzeitig hochgefahren werden) für einige Stunden arbeitsunfähig sind.

 

Ist es möglich das Update über einen Dienst laufen zu lassen, der den Server anfragt, ob ein neues Update vorhanden ist und sich dieses holen kann?

Oder weiß jemand, ob es dafür evtl. bereits eine Lösung im MSDN gibt?

Oder gibt es sonst irgendeine Möglichkeit zur Lösung des Problems?

 

Ich bin für jede Idee und jeden Vorschlag dankbar.

 

Vielen Dank bereits im Voraus

[Sunny61 811]

Du kannst die Updates mit dem Local Update Publisher in den WSUS schieben und darüber zur Verfügung stellen. Der lokale Windows Update Agent downloadet die Software mit Hilfe des BITS, und den Dienst kannst Du via GPO konfigurieren.

 

Teil 1 + 2 lesen: Deployment von MSP-Updates über WSUS: Teil 1 (Konfiguration) | How the ESCde does IT

 

BITS Konfiguration über GPO: WSUS.DE - Background Intelligent Transfer Services (BITS)

[surfer123 10]

Hallo,

 

vielen Dank schon mal für diesen sehr interessanten Lösungsansatz.

Wir sind Softwarehersteller der seine Software als Drittanbieter in einer Rechenzentrale betreibt.

Die WSUS Variante hört sich für mich schon sehr gut an und werden ich auf jeden Fall weiter prüfen.

Hat mit der WSUS Variante schon jemand erfahrung?

 

Gibt es noch anderweitige Ideen das mittels Updatedienst oder ähnlichen zu bewerkstelligen, denn ich weiß leider nicht ob in der Rechenzentrale der WSUS betrieben wird. Die verteilen die Update nämlich selbts. Leider bekommen wir keine Informationen der Rechenzentrale wie die das machen.

 

Danke

 

Gruß

 

Surfer123

[Sunny61 811]

vielen Dank schon mal für diesen sehr interessanten Lösungsansatz.

Wir sind Softwarehersteller der seine Software als Drittanbieter in einer Rechenzentrale betreibt.

 

Das hättest Du gleich ins erste Posting schreiben sollen.

 

Die WSUS Variante hört sich für mich schon sehr gut an und werden ich auf jeden Fall weiter prüfen.

Hat mit der WSUS Variante schon jemand erfahrung?

 

Ja, läuft bei uns seit 1 Jahr erfolgreich.

 

Gibt es noch anderweitige Ideen das mittels Updatedienst oder ähnlichen zu bewerkstelligen, denn ich weiß leider nicht ob in der Rechenzentrale der WSUS betrieben wird. Die verteilen die Update nämlich selbts. Leider bekommen wir keine Informationen der Rechenzentrale wie die das machen.

 

Alternativ schreibst Du dir einen eigenen Dienst, der die Updates von dem Server downloadet und installiert.

 

Der Vorteil bei der WSUS Variante ist der BITS, der Intelligente Hintergrundübertragungsdienst, der kann konfiguriert werden, welche Bandbreite zum Download benutzt werden kann/darf.

[Dukel 457]

Evtl. kann man einen eigenen Updatemechanismus in die Anwendung einbauen.

 

Bezüglich BITS kann man dieses auch ohne wsus nutzen und mit in die eigene Anwendung integrieren.

Ich habe es einmal kurz getestet. Man kann z.B. mit Powershell Bits steuern und damit Dateien herunterladen.

[surfer123 10]

Hallo,

 

@Sunny61:

Alternativ schreibst Du dir einen eigenen Dienst, der die Updates von dem Server downloadet und installiert.

Der Download sollte keine Problem sein, hier prüf ich auch die Möglichkeit des BITS (Danke an Dukel für die Idee).

 

Aber das Hauptproblem ist die Installation des Updates. Das liegt nicht als Installer vor sondern als reine Dateien.

• DLL-Dateien
  
• EXE-Dateien
  
• anderweitige Dateien
  

DLL-Dateien müssen in Windows\System32 bzw Windows\SysWow64

Dementsprechend natürlich Registriert (RegSVR32.exe)

Der Rest in c:\Program Files\...

 

Da liegt mein Hauptproblem.

 

Wenn möglich würde ich mir auf dem Client natürlich einen eigenen Windows-Dienst sparen.

 

Gruß Surfer123

[Sunny61 811]

Aber das Hauptproblem ist die Installation des Updates. Das liegt nicht als Installer vor sondern als reine Dateien.

• DLL-Dateien
  
• EXE-Dateien
  
• anderweitige Dateien
  

DLL-Dateien müssen in Windows\System32 bzw Windows\SysWow64

Dementsprechend natürlich Registriert (RegSVR32.exe)

Der Rest in c:\Program Files\...

 

Da liegt mein Hauptproblem.

 

Hmm, das ist wieder mal ein ganz typischer Thread wie er nicht vorkommen sollte. Mit jedem Posting kommt ein Stückchen Wahrheit mehr ans Licht. Im ersten Posting schreibst Du noch von MSI Dateien und die Installation via GPO im Benutzerkontext funktioniert einwandfrei. Das glaube ich nicht. Ein Benutzer darf keine SW installieren. Oder sind das alles Administratoren? Jetzt heißt es plötzlich, es liegt kein Installer vor, sondern es werden nur Dateien ausgetauscht. Was sollen wir denn jetzt davon halten? Was stimmt denn nun?

 

Aber ich sehe schon, Du hast dich in keinster Art und Weise mit den gebotenen Hinweisen beschäftigt, denn ansonsten wäre die Sache schon längst geklärt.

 

Mußt Du bei den Windows Updates als eingeschränkter Benutzer irgendetwas zustimmen? Nein, denn das läuft alles mit Systemrechten. Und genau das willst Du haben. Also setz dir eine Testumgebung auf und spiel das durch. Wir verteilen EXEN, MSI-Files und es funktioniert einwandfrei. Die Benutzer merken nichts davon.

 

Ein Installer macht übrigens nichts anderes als Dateien auszutauschen. Was glaubst Du passiert bei einem Update vom Reader 10.1.2 auf 10.1.3? Genau, es werden Dateien ausgetauscht.

 

Wenn möglich würde ich mir auf dem Client natürlich einen eigenen Windows-Dienst sparen.

 

Dann nimm die Windows Boardmittel. Du kannst natürlich auch einen geplanten Task erstellen, beim starten des Sytem wird dein Installer ausgeführt, ob das klappt weiß ich nicht.

[surfer123 10]

Hallo Sunny61,

 

das will ich so jetzt auch nicht auf mir sitzen lassen.:mad:

Ich kann doch nicht auf 20 Seiten genau im Detail erklären was die Sachlage ist.

Du hast recht, dass ich etwas detaillierter schrieben hätte können.

Aber wir sind doch hier in einem Forum! Da kann man ja etwas nachfragen oder?

Im Ersten Thread hab ich geschrieben:

Momentan werden die Updates mittels MSI-Pakete und den Benutzerrichtlinien übergeben

Mit Benutzerrichtlinien meinte ich Gruppenrichtlinie. Das ist auch so richtig.

Ich habe ein MSI-Packet das eine Neuinstalltion und eine Updatevariante in sich beinhaltet.

Das kann ich auch per GPO verteilen (zum neuinstallieren der aktuellen Version oder aber auch zur Installation des Updates auf eine bereits installierte ältere Version). Da die GPO Arbeitsplatz bezogen angewandt wird funktioniert die Installation einwandfrei und ohne Benutzerinteraktion (auch ein aktualisierendes Update).

 

Da das MSI-Packet 50 MB groß ist und das eigentliche Update (Dateien) nur max. 20 MB groß sind habe ich nach einer Variante gefragt die Dateien selbst irgendwie zu aktuallisieren und Registrieren. Da hab ich mich im hervorgehenden Thread vielleicht etwas unglücklich ausgedrückt.

 

Ich habe auch deshalb nach weiteren möglichkeiten gefragt, weil ich folgendes bereits geschreiben habe:

Gibt es noch anderweitige Ideen das mittels Updatedienst oder ähnlichen zu bewerkstelligen, denn ich weiß leider nicht ob in der Rechenzentrale der WSUS betrieben wird. Die verteilen die Update nämlich selbts. Leider bekommen wir keine Informationen von der Rechenzentrale wie die das machen.

 

Ein Normaler User hat gar keine Rechte!

Er darf nicht mal nen Desktop Hintergrund ändern. Die Meldungen der Administrationsauffroderung (die bei einer Installation kommen würden) werden per GPO unterdrückt. Er hat auch keine Schreibrechte in C:\Program Files\

 

Ich denke das erklärt jetzt einiges.

 

Eine Testumgebung Aufbauen ist leider nich so schnell getan, bin aber schon dabei!

 

Trotzdem vielen Dank für dein Engagement.

Ich werde deinen Ansatz erst vollständig prüfen und mich dann hier wieder melden.

 

Gruß

 

surfer123

[Sunny61 811]

Ich kann doch nicht auf 20 Seiten genau im Detail erklären was die Sachlage ist.

Du hast recht, dass ich etwas detaillierter schrieben hätte können.

Aber wir sind doch hier in einem Forum! Da kann man ja etwas nachfragen oder?

 

Du bist hier der Fragende, also kann ich von dir erwarten möglichst genaue Details dazu zu bekommen. Du möchtest ja auch eine möglichst zielführende Antwort. Aber gut, jetzt heißt es nach vorne schauen.

 

Im Ersten Thread hab ich geschrieben:

Mit Benutzerrichtlinien meinte ich Gruppenrichtlinie. Das ist auch so richtig.

Ich habe ein MSI-Packet das eine Neuinstalltion und eine Updatevariante in sich beinhaltet.

Das kann ich auch per GPO verteilen (zum neuinstallieren der aktuellen Version oder aber auch zur Installation des Updates auf eine bereits installierte ältere Version). Da die GPO Arbeitsplatz bezogen angewandt wird funktioniert die Installation einwandfrei und ohne Benutzerinteraktion (auch ein aktualisierendes Update).

 

Der zweite Fehler von dir ist die Ausdrucksweise. Es gibt Softwareinstallationen als Computer GPO und als Benutzer GPO. Da Du von Benutzerrichtlinien gesprochen hast, fragte ich korrekterweise nach Adminrechten. Jetzt schreibst Du von einer Arbeitsplatz GPO, also vermutlich eine Computer GPO, richtig?

 

Da das MSI-Packet 50 MB groß ist und das eigentliche Update (Dateien) nur max. 20 MB groß sind habe ich nach einer Variante gefragt die Dateien selbst irgendwie zu aktuallisieren und Registrieren. Da hab ich mich im hervorgehenden Thread vielleicht etwas unglücklich ausgedrückt.

 

Genau.

 

Eine Testumgebung Aufbauen ist leider nich so schnell getan, bin aber schon dabei!

 

Trotzdem vielen Dank für dein Engagement.

Ich werde deinen Ansatz erst vollständig prüfen und mich dann hier wieder melden.

 

Gut, wenn Du dazu Fragen hast, melde dich einfach wieder. ;)