7
Third Party Installation als Windows Update verpacken
Hallo zusammen,
Ich bin auf der Suche nach einer Möglichkeit die Windows Updates User Experience für Third Party Intallationen zu nutzen.
Wir haben in unserer Firma eine Software die unbedingt einen Neustart erfordert, aber wir haben kein Maintenance Windows in dem wir das Update durchführen können.
Ohne den Neustart ist der Rechner quasi unbenutzbar.
Wir haben verschiedene Möglichkeiten versucht, ohne Erfolg:
- Powersell AppDeployment Toolkit hat versagt, weil die Elevation verloren geht und das Update unbedingt mit Admin Rechten laufen muss
- Unser Symantec Software Management System was die Installation als SYSTEM laufen lässt und den Reboot erzwingt (die User verlieren ungespeicherte Arbeit)
- Es dem User selbst überlassen den Reboot durchzuführen (kaum ein User macht das und ruft dann lieber unseren Helpdesk an, wenns Probleme gibt)
Da das Update nur 60 Sekunden dauert haben wir also einen Scheduled Task erstellt, der VOR DEM USER LOGON läuft und einen Reboot nach Abschluss erzwingt. Dadurch minimieren wir die Gefahr, das ein User ungespeicherte Daten verliert. Leider verschießt sich der Scheduled Task, wenn es pending Windows Updates gibt.
Nun wäre es ideal, wenn es eine Möglichkeit gibt die Installation/Update unserer Software als eigens gebautes Windows Update zu basteln und dann vor dem User Logon zu installatieren. Hat bestimmt jeder schonmal gesehen, dass bei einem Neustart Windows Updates vorm Login installiert werden und dann ein Reboot kommt (Anzeige "Working on Updates mit Prozentangabe).
Falls das nicht geht, kann mir jemand eine Methode empfehlen die quasi Best Practice ist? Herlichen Dank für eure Hilfe im Vorfeld.
Ich bin auf der Suche nach einer Möglichkeit die Windows Updates User Experience für Third Party Intallationen zu nutzen.
Wir haben in unserer Firma eine Software die unbedingt einen Neustart erfordert, aber wir haben kein Maintenance Windows in dem wir das Update durchführen können.
Ohne den Neustart ist der Rechner quasi unbenutzbar.
Wir haben verschiedene Möglichkeiten versucht, ohne Erfolg:
- Powersell AppDeployment Toolkit hat versagt, weil die Elevation verloren geht und das Update unbedingt mit Admin Rechten laufen muss
- Unser Symantec Software Management System was die Installation als SYSTEM laufen lässt und den Reboot erzwingt (die User verlieren ungespeicherte Arbeit)
- Es dem User selbst überlassen den Reboot durchzuführen (kaum ein User macht das und ruft dann lieber unseren Helpdesk an, wenns Probleme gibt)
Da das Update nur 60 Sekunden dauert haben wir also einen Scheduled Task erstellt, der VOR DEM USER LOGON läuft und einen Reboot nach Abschluss erzwingt. Dadurch minimieren wir die Gefahr, das ein User ungespeicherte Daten verliert. Leider verschießt sich der Scheduled Task, wenn es pending Windows Updates gibt.
Nun wäre es ideal, wenn es eine Möglichkeit gibt die Installation/Update unserer Software als eigens gebautes Windows Update zu basteln und dann vor dem User Logon zu installatieren. Hat bestimmt jeder schonmal gesehen, dass bei einem Neustart Windows Updates vorm Login installiert werden und dann ein Reboot kommt (Anzeige "Working on Updates mit Prozentangabe).
Falls das nicht geht, kann mir jemand eine Methode empfehlen die quasi Best Practice ist? Herlichen Dank für eure Hilfe im Vorfeld.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2108357817
Url: https://administrator.de/contentid/2108357817
Printed on: April 28, 2024 at 18:04 o'clock
7 Comments
Latest comment
Wir nutzen auch wenn kaum noch entwickelt den WSUS Package Publisher. Einige Funktionen gehen halt unter Windows 10+ nicht mehr. Funktioniert zur Verteilung aber auch unter windows 10 noch einwandfrei. Man kann auch Custom Updates erstellen und dabei einen Neustart erzwingen. Wird dann parallel zu den WIndows Updates ausgeführt.
Ist vielleicht einen Versuch wert.
Ist vielleicht einen Versuch wert.
Moin,
so ganz verstehe ich das Problem nicht, warum machst du das nicht ganz einfach per Softwareverteilung über GPO?
Grüße
so ganz verstehe ich das Problem nicht, warum machst du das nicht ganz einfach per Softwareverteilung über GPO?
Grüße
Aloha,
Oder einfach ein Logon Skript das den Schirm abdunkelt, Überprüft ob Updates sind, dies entsprechend auf einem gesperrten Schirm ausgibt und die Updates samt Neustart durchführt?
Wenn die Nachfrage zu lange laufen sollte, kann man ja in einer Variablen lokal hinterlegen im Betrieb das das Update beim nächsten Anmelden gemacht wird.
Oder einfach ein Logon Skript das den Schirm abdunkelt, Überprüft ob Updates sind, dies entsprechend auf einem gesperrten Schirm ausgibt und die Updates samt Neustart durchführt?
Wenn die Nachfrage zu lange laufen sollte, kann man ja in einer Variablen lokal hinterlegen im Betrieb das das Update beim nächsten Anmelden gemacht wird.
Upps
Habe gerade gelesen das Ihr das schon quasi macht.
Was ist mit einem automatischen Neustart nach dem Booten?
Und einem Zähler der nach der Anmeldung automatisch auf 0 gesetzt wird?
Bei den aktuellen Systemen ist ein reboot meistens sehr flott.
Dann sollte der Punkt mit den Updates erledigt sein.
Habe gerade gelesen das Ihr das schon quasi macht.
Was ist mit einem automatischen Neustart nach dem Booten?
Und einem Zähler der nach der Anmeldung automatisch auf 0 gesetzt wird?
Bei den aktuellen Systemen ist ein reboot meistens sehr flott.
Dann sollte der Punkt mit den Updates erledigt sein.
Vielen Dank für eure Antworten.
@sabines: Wir haben keine GPO mehr, da wir AzureAD only Systeme nutzen.
@TomTomBon: Sowas wie du mit den Logon Scripten vorschlägst haben wir mit dem PS AppDeployment Toolkit schon gemacht. Quasi einen Splash Screen über den Desktop gelegt. Problem ist, dass im Hintergrund alle Prozesse starten, die gerne mit der Installation in Konflikt geraten.
@UnbekannterNR1: Das sieht sehr vielversprechend aus. Weißt du ob man den Package Builder auch nutzen kann ohne mit einem WSUS Server zu verbinden? Bei mir bleiben die Optionen ausgegraut.
@sabines: Wir haben keine GPO mehr, da wir AzureAD only Systeme nutzen.
@TomTomBon: Sowas wie du mit den Logon Scripten vorschlägst haben wir mit dem PS AppDeployment Toolkit schon gemacht. Quasi einen Splash Screen über den Desktop gelegt. Problem ist, dass im Hintergrund alle Prozesse starten, die gerne mit der Installation in Konflikt geraten.
@UnbekannterNR1: Das sieht sehr vielversprechend aus. Weißt du ob man den Package Builder auch nutzen kann ohne mit einem WSUS Server zu verbinden? Bei mir bleiben die Optionen ausgegraut.
Nur zur Erklärung. Bei der Installation/Update handelt es sich um eine privilege management software die vielen Prozessen ein admin token gibt, sodass der eingeloggte User kein Admin sein muss.
Die Software kann das Update nicht elevaten, wenn es deinstalliert ist, und das muss es ja bevor die neue Version drauf kommt.
Darum ist es notwendig die Installation/Update im SYSTEM Context laufen zu lassen. Und das am besten vorm User Logon, damit es nicht in Konflik mit startenden Prozessen kommt.
Außerdem muss der User dann nicht einloggen, nur um nach dem Update einen erneuten Reboot zu sehen, um dann ein zweites Mal das PW einzugeben.
Die Software kann das Update nicht elevaten, wenn es deinstalliert ist, und das muss es ja bevor die neue Version drauf kommt.
Darum ist es notwendig die Installation/Update im SYSTEM Context laufen zu lassen. Und das am besten vorm User Logon, damit es nicht in Konflik mit startenden Prozessen kommt.
Außerdem muss der User dann nicht einloggen, nur um nach dem Update einen erneuten Reboot zu sehen, um dann ein zweites Mal das PW einzugeben.
Oh fast vergessen zu antworten.
Der WPP funktioniert am besten direkt auf dem WSUS selbst. Zur erklärung er legt die Updates auf dem WSUS ab, nicht am Client. Das bedeutet natürlich auch das, das ganze nur mit einem eigenen WSUS funktioniert. Ich weiß leider nicht wie das mit eine Azure AD ist, hat man da noch einen eigenen WSUS?
Der WPP funktioniert am besten direkt auf dem WSUS selbst. Zur erklärung er legt die Updates auf dem WSUS ab, nicht am Client. Das bedeutet natürlich auch das, das ganze nur mit einem eigenen WSUS funktioniert. Ich weiß leider nicht wie das mit eine Azure AD ist, hat man da noch einen eigenen WSUS?
