Windows 10 Upgrades in der Praxis
Hallo zusammen,
ich bin als Ausbilder mit einem Azubi in einem mittelständischen Unternehmen für ca. 100 Client-Rechner zuständig. Die Administration der Serverlandschaft und der Netzwerkinfrastruktur fällt zum Teil auf mich und zum Teil auf die Kollegen in der Zentrale. 95% der Clients laufen auf Windows 10 Pro und werden über eine Windows Domäne verwaltet.
Nun zu meiner Frage: Wie fahrt ihr die Upgrades (1607, 1703, 1709, 1803, ...) in der Praxis? Wir machen das Ganze aktuell noch händisch. Der Aufwand ist für uns kaum noch tragbar, bis zum Auslauf der Support-Enden schaffen wir es einfach nicht. Einfach deployen ist für die Anwender nicht tragbar, da die Zeit des Hochfahrens nach dem Upgrade zu lang ist.
Viele Grüße,
Tiefgarage
ich bin als Ausbilder mit einem Azubi in einem mittelständischen Unternehmen für ca. 100 Client-Rechner zuständig. Die Administration der Serverlandschaft und der Netzwerkinfrastruktur fällt zum Teil auf mich und zum Teil auf die Kollegen in der Zentrale. 95% der Clients laufen auf Windows 10 Pro und werden über eine Windows Domäne verwaltet.
Nun zu meiner Frage: Wie fahrt ihr die Upgrades (1607, 1703, 1709, 1803, ...) in der Praxis? Wir machen das Ganze aktuell noch händisch. Der Aufwand ist für uns kaum noch tragbar, bis zum Auslauf der Support-Enden schaffen wir es einfach nicht. Einfach deployen ist für die Anwender nicht tragbar, da die Zeit des Hochfahrens nach dem Upgrade zu lang ist.
Viele Grüße,
Tiefgarage
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 388818
Url: https://administrator.de/contentid/388818
Ausgedruckt am: 25.11.2024 um 00:11 Uhr
23 Kommentare
Neuester Kommentar
@Penny.Cilin:
Ich denke, auch WSUS fiele unter "deployen", je nach Rechnerperformance (und insbesondere, ob SSD oder nicht) hockt der Anwender doch zwischen 20 und 90 Minuten vor dem Upgrade-Dialog und kann nichts tun … ?
@Tiefgarage:
Deployen wäre schon richtig, gleichgültig, ob aus einem Share oder über WSUS.
Ihr könntet mal über ein WOL nachdenken, das zeitgesteuert frühmorgens um 04.00 Uhr (nur ein Beispiel, Hauptsache, das Zeitfenster genügt bis zum Dienst-/Arbeitsbeginn) die Rechner hochfährt. Beim Rechnerstart ein Skript ausführen lassen (z. B. per GPO), das die Aktualisierung anstößt. Müßte allerdings ein Skript sein, das sogleich auch die Fragen des Upgrade-Dialogs beantwortet (Apps und Daten behalten usw.), vermutlich könnte das mit einem PS-Skript funktionieren.
Bei mir sind es 60 Rechner, ich bin allein und mache das auch noch zu Fuß, lasse mir aber Zeit, es müssen ja nicht alle Windows-10-Rechner nahezu zeitgleich die neue Windows-Build bekommen. Die Supportzeiträume sind ja lang genug, so daß man sich auch ein Jahr lang Zeit lassen könnte, alle Rechner zu aktualisieren.
Viele Grüße
von
departure69
Ich denke, auch WSUS fiele unter "deployen", je nach Rechnerperformance (und insbesondere, ob SSD oder nicht) hockt der Anwender doch zwischen 20 und 90 Minuten vor dem Upgrade-Dialog und kann nichts tun … ?
@Tiefgarage:
Deployen wäre schon richtig, gleichgültig, ob aus einem Share oder über WSUS.
Ihr könntet mal über ein WOL nachdenken, das zeitgesteuert frühmorgens um 04.00 Uhr (nur ein Beispiel, Hauptsache, das Zeitfenster genügt bis zum Dienst-/Arbeitsbeginn) die Rechner hochfährt. Beim Rechnerstart ein Skript ausführen lassen (z. B. per GPO), das die Aktualisierung anstößt. Müßte allerdings ein Skript sein, das sogleich auch die Fragen des Upgrade-Dialogs beantwortet (Apps und Daten behalten usw.), vermutlich könnte das mit einem PS-Skript funktionieren.
Bei mir sind es 60 Rechner, ich bin allein und mache das auch noch zu Fuß, lasse mir aber Zeit, es müssen ja nicht alle Windows-10-Rechner nahezu zeitgleich die neue Windows-Build bekommen. Die Supportzeiträume sind ja lang genug, so daß man sich auch ein Jahr lang Zeit lassen könnte, alle Rechner zu aktualisieren.
Viele Grüße
von
departure69
Zitat von @Tiefgarage:
Nun zu meiner Frage: Wie fahrt ihr die Upgrades (1607, 1703, 1709, 1803, ...) in der Praxis? Wir machen das Ganze aktuell noch händisch. Der Aufwand ist für uns kaum noch tragbar, bis zum Auslauf der Support-Enden schaffen wir es einfach nicht. Einfach deployen ist für die Anwender nicht tragbar, da die Zeit des Hochfahrens nach dem Upgrade zu lang ist.
Nun zu meiner Frage: Wie fahrt ihr die Upgrades (1607, 1703, 1709, 1803, ...) in der Praxis? Wir machen das Ganze aktuell noch händisch. Der Aufwand ist für uns kaum noch tragbar, bis zum Auslauf der Support-Enden schaffen wir es einfach nicht. Einfach deployen ist für die Anwender nicht tragbar, da die Zeit des Hochfahrens nach dem Upgrade zu lang ist.
Nachts per WOL die Kisten hochfrahren, deployen und wieder runterfahren.
Morgens wenn die Mitarbeiter das sind, sind die Kisten wieder frisch und munter, zumindest meistens, wenn man vorher sorgfältig getestet hat.
lks
Hallo,
wir nutzen WSUS auch um das Feautreupdate auf Windows 10 Rechner zu verteilen und die Mitarbeiter habe keine lange Ausfallzeiten.
Wenn du das Update freigibst, dann lädt Windows das Update ja erstmal im laufenden Betrieb herunter und fängt die Installation teilweise im Hintergrund schon an. Sobald der User dann Herunterfahren drückt, geht es ja richtig los.
Beim nächsten Start wird die Installation ja quasi abgeschlossen, normalerweise dauert das höchstens 10-15 Minuten (wenn die Rechner eine SSD haben). Wenn du am Rechner direkt sitzt, dann haben die Mitarbeiter ja eine höhere Ausfallzeit?
Bei ca. 100 Rechnern würde ich das nicht händisch machen...das wäre mir zu viel Arbeit, vor allem, wenn es mit WSUS ohne Probleme geht.
Das die User halt mal ein paar Minuten an einem Tag früh Morgens nicht direkt arbeiten können, muss man so hin nehmen. Oder du kommst ganz früh und startest alle Rechner per Hand, damit das Upgrade weiter geführt wird ;)
wir nutzen WSUS auch um das Feautreupdate auf Windows 10 Rechner zu verteilen und die Mitarbeiter habe keine lange Ausfallzeiten.
Wenn du das Update freigibst, dann lädt Windows das Update ja erstmal im laufenden Betrieb herunter und fängt die Installation teilweise im Hintergrund schon an. Sobald der User dann Herunterfahren drückt, geht es ja richtig los.
Beim nächsten Start wird die Installation ja quasi abgeschlossen, normalerweise dauert das höchstens 10-15 Minuten (wenn die Rechner eine SSD haben). Wenn du am Rechner direkt sitzt, dann haben die Mitarbeiter ja eine höhere Ausfallzeit?
Bei ca. 100 Rechnern würde ich das nicht händisch machen...das wäre mir zu viel Arbeit, vor allem, wenn es mit WSUS ohne Probleme geht.
Das die User halt mal ein paar Minuten an einem Tag früh Morgens nicht direkt arbeiten können, muss man so hin nehmen. Oder du kommst ganz früh und startest alle Rechner per Hand, damit das Upgrade weiter geführt wird ;)
Hallo,
@departure69
ja meine Antwort war bewusst einfach gehalten.
@Tiefgarage
Wie bereits geschrieben, wäre WoL (Wake on LAN) eine Möglichkeit. Zumanderen könntest Du im WSUS Gruppen einrichten, welche zu bestimmten Zeiten dann per WoL die Upgrades bekommen.
Was ich damit meine, ist daß Du zeitgesteuert die Rechner dann aktualisierst, wenn die Personen diese nicht benutzen.
Zum Beispiel, wenn jemand Spätschicht hat, dann kannst Du nach der Spätschicht den Rechner aktualisieren. Du hast dann noch ein Zeitfenster danach, wo Du ggf. noch reagieren kannst, wenn etwas fehlschlägt.
Beim nächsten Spätdienst kann der Anwender wieder arbeiten.
Gruss Penny.
@departure69
ja meine Antwort war bewusst einfach gehalten.
@Tiefgarage
Wie bereits geschrieben, wäre WoL (Wake on LAN) eine Möglichkeit. Zumanderen könntest Du im WSUS Gruppen einrichten, welche zu bestimmten Zeiten dann per WoL die Upgrades bekommen.
Was ich damit meine, ist daß Du zeitgesteuert die Rechner dann aktualisierst, wenn die Personen diese nicht benutzen.
Zum Beispiel, wenn jemand Spätschicht hat, dann kannst Du nach der Spätschicht den Rechner aktualisieren. Du hast dann noch ein Zeitfenster danach, wo Du ggf. noch reagieren kannst, wenn etwas fehlschlägt.
Beim nächsten Spätdienst kann der Anwender wieder arbeiten.
Gruss Penny.
Schön zu lesen dass man mit dieser Aufgabe nicht alleine auf der Welt ist. Wir stellen grade erst von Windows 7 auf Windows 10 um, habe ca. 200 Clients zu betreuen, und ich sehe es schon auf mich zukommen dass die Funktionsupdates in Zukunft ein massives zeitfressendes Problem werden.
Ich habe einen Client zuletzt vor dem Rollout zum Stellplatz via WSUS von 1709 auf 1803 upgedatet und diese Wartezeit mit dem Reboot etc. ist für den Anwender absolut nicht tragbar. Also kann das nur außerhalb dessen Arbeitszeit erfolgen.
Ich habe einen Client zuletzt vor dem Rollout zum Stellplatz via WSUS von 1709 auf 1803 upgedatet und diese Wartezeit mit dem Reboot etc. ist für den Anwender absolut nicht tragbar. Also kann das nur außerhalb dessen Arbeitszeit erfolgen.
Hi.
und ab dafür. Keinerlei Probleme damit.
bis zum Auslauf der Support-Enden schaffen wir es einfach nicht
Die Supportzeiträume haben sich geändert. Die Herbstupdates (1809,1909,...) werden 30 Monate supportet.Wie fahrt ihr die Upgrades
Einmal im Jahr an einem Wochenende geskriptet (immediate Task mit Randomzeit) bei allen (Vorab einen Monat lang IT-interner Test).\\server\share\setup.exe /auto upgrade /dynamicupdate disable
Zitat von @DerWoWusste:
Mann sollte auch erwähnen, dass das nicht für die Home und Pro Version gilt.bis zum Auslauf der Support-Enden schaffen wir es einfach nicht
Die Supportzeiträume haben sich geändert. Die Herbstupdates (1809,1909,...) werden 30 Monate supportet.
Servus,
das mit WSUS für die Upgrades ist mir irgendwie komisch. Zumal wenn ich an unsere langsame DSL-Verbindung zu mehreren Außenstellen denke.
Und WOL funktioniert offenbar über VPN mit jeweils Hardwarefirewalls an jedem Ende nicht zuverlässig?!
Zudem werden unsere Geräte teilweise auch zu "unmöglichen" Zeiten bedient und deren grundsätzliche Funktionsbereitschaft an Sonn-/Feiertagen und zur Nachtzeit erwartet.
Ich teste i.d.R. ein Reservegerät sowie meinen PC mit den Upgrades und informiere dann per Mail, dass der Download erfolgt war und die Installation vom Benutzer dann (ohne lokale Adminrechte) gestartet wird, sobald es für ihn i.O. geht.
Gruß
das mit WSUS für die Upgrades ist mir irgendwie komisch. Zumal wenn ich an unsere langsame DSL-Verbindung zu mehreren Außenstellen denke.
Und WOL funktioniert offenbar über VPN mit jeweils Hardwarefirewalls an jedem Ende nicht zuverlässig?!
Zudem werden unsere Geräte teilweise auch zu "unmöglichen" Zeiten bedient und deren grundsätzliche Funktionsbereitschaft an Sonn-/Feiertagen und zur Nachtzeit erwartet.
Ich teste i.d.R. ein Reservegerät sowie meinen PC mit den Upgrades und informiere dann per Mail, dass der Download erfolgt war und die Installation vom Benutzer dann (ohne lokale Adminrechte) gestartet wird, sobald es für ihn i.O. geht.
Gruß
@spec1re
Danke für den Hinweis. Ich muss gestehen, dass ich wohl glaubte, irgendwo gelesen zu haben, dass es für alle gilt.
Danke für den Hinweis. Ich muss gestehen, dass ich wohl glaubte, irgendwo gelesen zu haben, dass es für alle gilt.
Zitat von @Tiefgarage:
Hallo,
es scheint sich also herauszukristallisieren, dass die einzige Möglichkeit WOL + Skripting oder Turnschuhsupport ist.
Ich lasse die Frage noch ein wenig offen, vielleicht gibt es ja noch eine charmantere Lösung.
Dann werde ich mir wohl initial die Arbeit machen müssen und WOL bei allen Clients aktivieren.
@DerWoWusste danke für den Befehl.
Dank gilt auch der regen Beteiligung.
Viele Grüße,
Tiefgarage
Hallo,
es scheint sich also herauszukristallisieren, dass die einzige Möglichkeit WOL + Skripting oder Turnschuhsupport ist.
Ich lasse die Frage noch ein wenig offen, vielleicht gibt es ja noch eine charmantere Lösung.
Dann werde ich mir wohl initial die Arbeit machen müssen und WOL bei allen Clients aktivieren.
@DerWoWusste danke für den Befehl.
Dank gilt auch der regen Beteiligung.
Viele Grüße,
Tiefgarage
Wie habt ihr denn vergleichsweise früher Service Packs installiert, z. B. das SP1 zu Windows 7? Oder SP3 zu Windows XP? Der Problemstellung und dem Aufwand nach muß das doch ähnlich gewesen sein? Einziger Unterschied natürlich, daß das nicht alle 6 Monate erforderlich war.
Viele Grüße
von
departure69
Wie viele Rechner haben denn bisher Version 1803 *noch nicht* ?
Wenn der Aufwand für das ständige Aktualisieren zu groß ist, könnte man erstmal alle Geräte zumindest auf 1803 bringen und ab da dann nur einmal pro Jahr ein Update fahren, so dass man z.B. das April Update oder Oktober Update jedes Jahr auslässt.
1810 ist ja erst erschienen und schon wieder zurück gezogen wegen Dateiverlust beim Upgrade. Inzwischen sollte man die neuste Version nicht direkt installieren sondern gut paar Wochen oder Monate abwarten.
Ansonsten, wie groß sind die Außenstellen um ggf. dort einen WSUS hinzustellen oder laufen dort gar keine Server? Dann macht das mit dem DSL kein Problem.
Wenn der Aufwand für das ständige Aktualisieren zu groß ist, könnte man erstmal alle Geräte zumindest auf 1803 bringen und ab da dann nur einmal pro Jahr ein Update fahren, so dass man z.B. das April Update oder Oktober Update jedes Jahr auslässt.
1810 ist ja erst erschienen und schon wieder zurück gezogen wegen Dateiverlust beim Upgrade. Inzwischen sollte man die neuste Version nicht direkt installieren sondern gut paar Wochen oder Monate abwarten.
Ansonsten, wie groß sind die Außenstellen um ggf. dort einen WSUS hinzustellen oder laufen dort gar keine Server? Dann macht das mit dem DSL kein Problem.
Servus,
@vBurak:
Exakt getroffen, dort läuft z.Zt. kein Server (würde wieder zusätzliche Hardware- und Lizenzkosten bedeuten und natürlich mehr Serviceaufwand).
Und, Du meintest sicher die 1809? Weil, eine Version 1810 gibt es laut Internet doch gar nicht?!
Gruß
@vBurak:
Exakt getroffen, dort läuft z.Zt. kein Server (würde wieder zusätzliche Hardware- und Lizenzkosten bedeuten und natürlich mehr Serviceaufwand).
Und, Du meintest sicher die 1809? Weil, eine Version 1810 gibt es laut Internet doch gar nicht?!
Gruß
Sorry, ja, ich mein 1809.
Ich war auch der Meinung, dass trotz WSUS die Daten direkt über Microsoft gezogen werden und anscheinend geht das auch, schau mal hier:
https://docs.microsoft.com/en-us/previous-versions/orphan-topics/ws.10/d ...
Bin aber gerade unsicher, was genau dann eingestellt werden muss. Wahrscheinlich über GPOs, wo dann der Download Server eben nicht angegeben wird.
Somit kannst du für jede Außenstelle weiterhin die Updates über den WSUS in der Zentrale genehmigen und die Clients in der Außenstelle laden dann diese Updates über Windows Update von Microsoft herunter.
Ich war auch der Meinung, dass trotz WSUS die Daten direkt über Microsoft gezogen werden und anscheinend geht das auch, schau mal hier:
https://docs.microsoft.com/en-us/previous-versions/orphan-topics/ws.10/d ...
If you want, you can store update files remotely on Microsoft servers. WSUS enables you to use Microsoft Update for the distribution of approved updates throughout your organization. This is particularly useful if most of the client computers connect to the WSUS server over a slow WAN connection but have high-bandwidth connections to the Internet, or if there are only a small number of client computers.
Bin aber gerade unsicher, was genau dann eingestellt werden muss. Wahrscheinlich über GPOs, wo dann der Download Server eben nicht angegeben wird.
Somit kannst du für jede Außenstelle weiterhin die Updates über den WSUS in der Zentrale genehmigen und die Clients in der Außenstelle laden dann diese Updates über Windows Update von Microsoft herunter.
Servus,
@vBurak:
Danke erst mal für den Tipp, ist nur fraglich, wie ich manchen Außenstellen klar mache, dass der direkte Download mal eben die dortigen DSL-Leitungen (max. 16000) für mehrere Stunden dicht macht?! Was ich weiß, wird doch immer das komplette ISO geladen, was jeweils mehrere GB Download bedeutet.
Aber, war da nicht auch was, dass sich W10 Updates (auch Upgrades?) von anderen PCs im gleichen Netzwerk holen kann?
Gruß
@vBurak:
Danke erst mal für den Tipp, ist nur fraglich, wie ich manchen Außenstellen klar mache, dass der direkte Download mal eben die dortigen DSL-Leitungen (max. 16000) für mehrere Stunden dicht macht?! Was ich weiß, wird doch immer das komplette ISO geladen, was jeweils mehrere GB Download bedeutet.
Aber, war da nicht auch was, dass sich W10 Updates (auch Upgrades?) von anderen PCs im gleichen Netzwerk holen kann?
Gruß
Servus,
wir handhaben das ähnlich wie @DerWoWusste
funktioniert bei uns genauso auch problemlos.
Und hat für uns noch den Vorteil, das wir das Offline-Image vorher entsprechend
anpassen können. Apps entfernen etc.
Grüße
eazy-isi
wir handhaben das ähnlich wie @DerWoWusste
funktioniert bei uns genauso auch problemlos.
Und hat für uns noch den Vorteil, das wir das Offline-Image vorher entsprechend
anpassen können. Apps entfernen etc.
Grüße
eazy-isi
Zitat von @VGem-e:
Danke erst mal für den Tipp, ist nur fraglich, wie ich manchen Außenstellen klar mache, dass der direkte Download mal eben die dortigen DSL-Leitungen (max. 16000) für mehrere Stunden dicht macht?! Was ich weiß, wird doch immer das komplette ISO geladen, was jeweils mehrere GB Download bedeutet.
Danke erst mal für den Tipp, ist nur fraglich, wie ich manchen Außenstellen klar mache, dass der direkte Download mal eben die dortigen DSL-Leitungen (max. 16000) für mehrere Stunden dicht macht?! Was ich weiß, wird doch immer das komplette ISO geladen, was jeweils mehrere GB Download bedeutet.
Aber genau das ist ja der Sinn eines WSUS Servers, DSL Leitung schonen und die Updates selbst und zentral im LAN bereitstellen.
Zitat von @VGem-e:
Aber, war da nicht auch was, dass sich W10 Updates (auch Upgrades?) von anderen PCs im gleichen Netzwerk holen kann?
Aber, war da nicht auch was, dass sich W10 Updates (auch Upgrades?) von anderen PCs im gleichen Netzwerk holen kann?
Auch das ist der Grundgedanke des WSUS.
Der Post von DerWoWusste (Level 5) um 09.10.2018 um 10:43 Uhr mit dem Bereitstellen des Windows 10 ISOs für das Upgrade könnte mit einem geskripteten Automatismus zumindest für die Funktionsupdates eine Lösung für dich sein. Wenn du aber auf Server in deiner Niederlassung verzichten möchtest hast du ja keine Komponente, die irgendeine zentrale Funktion für dich übernehmen kann.
@VGem-e:
Hi.
Ja, richtig, Du meinst dies hier:
Probier's aus, wenn ich das richtig verstanden habe, müßte es dann genügen, das Upgrade auf einem einzigen PC durchzuführen, die anderen saugen sich dann die notwendigen Update-Dateien von dem Einen. Zumindest in der Theorie, ich hab' das noch nie genutzt, ist bei uns auch überall abgeschaltet (brauchen's nicht, haben WSUS). Natürlich muß diese Einstellung auf allen PCs aktiviert sein, die daran teilnehmen sollen.
Viele Grüße,
departure69
Hi.
Aber, war da nicht auch was, dass sich W10 Updates (auch Upgrades?) von anderen PCs im gleichen Netzwerk holen kann?
Ja, richtig, Du meinst dies hier:
Probier's aus, wenn ich das richtig verstanden habe, müßte es dann genügen, das Upgrade auf einem einzigen PC durchzuführen, die anderen saugen sich dann die notwendigen Update-Dateien von dem Einen. Zumindest in der Theorie, ich hab' das noch nie genutzt, ist bei uns auch überall abgeschaltet (brauchen's nicht, haben WSUS). Natürlich muß diese Einstellung auf allen PCs aktiviert sein, die daran teilnehmen sollen.
Viele Grüße,
departure69
Servus,
@departure69:
Genau das hatte ich im Hinterkopf.
Auch wir verwenden einen WSUS, der die zentrale Updateverwaltung durchführt und der auch für die Außenstellen konfiguriert ist.
Aber einen Updload von unserem WSUS mit der langsamen DSL-Anbindung zu insges. 5 Außenstellen, die manchmal dummerweise gleichzeitig arbeiten, würde wohl alles lahm legen.
Gruß
@departure69:
Genau das hatte ich im Hinterkopf.
Auch wir verwenden einen WSUS, der die zentrale Updateverwaltung durchführt und der auch für die Außenstellen konfiguriert ist.
Aber einen Updload von unserem WSUS mit der langsamen DSL-Anbindung zu insges. 5 Außenstellen, die manchmal dummerweise gleichzeitig arbeiten, würde wohl alles lahm legen.
Gruß
Moin ,
ja ja diese schönen Versionsupgrades.
Wir machen es mit Script, PDQ Deploy und Richtlinien.
Die Mitarbeiter ( meist Abteilungsweise ) werden informiert, das die Rechner Freitags an bleiben sollen. Eine passende Gruppenrichtlinie verhindert das Herunterfahren zuverlässig. Mit PDQ Deploy ein passendes "Upgradepackage" gebastelt und ab dafür.
Im Anschluss werden die Kisten heruntergefahren und gut ist.
Ferner werden dafür auch gerne die Urlaubtage der Mitarbeiter genutzt ;)
Gruss Michael
ja ja diese schönen Versionsupgrades.
Wir machen es mit Script, PDQ Deploy und Richtlinien.
Die Mitarbeiter ( meist Abteilungsweise ) werden informiert, das die Rechner Freitags an bleiben sollen. Eine passende Gruppenrichtlinie verhindert das Herunterfahren zuverlässig. Mit PDQ Deploy ein passendes "Upgradepackage" gebastelt und ab dafür.
Im Anschluss werden die Kisten heruntergefahren und gut ist.
Ferner werden dafür auch gerne die Urlaubtage der Mitarbeiter genutzt ;)
Gruss Michael