17
Win10 Update per Script
HI,
ich würde gern einige PC's auf den aktuellen WIndows 10 Stand hoch ziehen, da diese Cleints das nicht automatisch gemacht haben.
Ich habe das ganze per Script vor. Das Script per Hand ausgeführt funktioniert. Ich stelle mir das so vor, dass ich mich mer psexec auf einen Client anmelde und das Script ausführe.
Leider kommt dann ein Zugriff verweigert.
Hier mal das Script:
Hatte auch anfangs den Ordner direkt auf C:\ angelegt. Auch hier kommt Zugriff verweigert.
Falls die Frage kommt: WSUS ist keiner (mehr) im Netz. Der lief nicht so wie gewünscht. Daher ist das Patch Management über ein Dritt Tool. Aber hier finde ich auch noch nicht die Möglichkeit, ein Win 10 Upgrade anzuschieben.
Hat jemand eine Idee / einen Tipp wie ich das realisieren könnte?
Danke
ich würde gern einige PC's auf den aktuellen WIndows 10 Stand hoch ziehen, da diese Cleints das nicht automatisch gemacht haben.
Ich habe das ganze per Script vor. Das Script per Hand ausgeführt funktioniert. Ich stelle mir das so vor, dass ich mich mer psexec auf einen Client anmelde und das Script ausführe.
Leider kommt dann ein Zugriff verweigert.
Hier mal das Script:
set winset=21H1
mkdir C:\users\%username%\%winset%
robocopy \\server\install\21H1\ C:\users\%username%\ /copy:DAT /E /W:0 /R:0
C:\users\%username%\setup.exe /auto upgrade /quiet /DynamicUpdate enable /eula accept /telemetry disableHatte auch anfangs den Ordner direkt auf C:\ angelegt. Auch hier kommt Zugriff verweigert.
Falls die Frage kommt: WSUS ist keiner (mehr) im Netz. Der lief nicht so wie gewünscht. Daher ist das Patch Management über ein Dritt Tool. Aber hier finde ich auch noch nicht die Möglichkeit, ein Win 10 Upgrade anzuschieben.
Hat jemand eine Idee / einen Tipp wie ich das realisieren könnte?
Danke
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 806132940
Url: https://administrator.de/forum/win10-update-per-script-806132940.html
Ausgedruckt am: 02.04.2025 um 08:04 Uhr
17 Kommentare
Neuester Kommentar
Hi. Ich würde von psexec aus Sicherheitsaspekten Abstand nehmen.
Lokal kopieren macht Setup von selbst automatisch - ein unnötiger Schritt.
ISO entpacken nach \\server\share
Geplanten Task per GPO verteilen (wenn's ein AD gibt), welcher als Systemkonto läuft und schlicht ausführt:
Dazu nimmt man am besten die Option randomization bei der Ausführungszeit, damit die Leitung nicht verglüht.
Lokal kopieren macht Setup von selbst automatisch - ein unnötiger Schritt.
ISO entpacken nach \\server\share
Geplanten Task per GPO verteilen (wenn's ein AD gibt), welcher als Systemkonto läuft und schlicht ausführt:
\\server\share\setup.exe /auto upgrade /quiet /DynamicUpdate enable /eula accept /telemetry disable
Hi,
ja, AD ist vorhanden, die Idee per GPO ist nicht schlecht
Server hat genug Power in der Anbindung, aber die randomization klingt gut (Blöde frage, wo finde ich das in der GUI? )
Ich kann ja dann die CLients, die es betrifft einfach in eine Sicherheitsgruppe packen und die GPO auf diese anwenden, korrekt?
Gruß
ja, AD ist vorhanden, die Idee per GPO ist nicht schlecht
Server hat genug Power in der Anbindung, aber die randomization klingt gut
(Blöde frage, wo finde ich das in der GUI? )Ich kann ja dann die CLients, die es betrifft einfach in eine Sicherheitsgruppe packen und die GPO auf diese anwenden, korrekt?
Gruß
So upgraden wir nahezu alle Maschinen, auch die im HomeOffice. Kopieren aber die Sachen vorher auf die lokale Platte und prüfen den Hash der ISO. So bin ich sicher, dass auch alles Nötige kopiert wurde.
Funktioniert tadellos.
VG
Edit noch: Wenn du ein /norestart (Edit: Falsch, es heißt /NoReboot) anfügst, startet er nicht automatisch neu, wenn das Setup soweit ist. Fanden unsere Benutzer ganz nett.
Funktioniert tadellos.
VG
Edit noch: Wenn du ein /norestart (Edit: Falsch, es heißt /NoReboot) anfügst, startet er nicht automatisch neu, wenn das Setup soweit ist. Fanden unsere Benutzer ganz nett.
Hmm,
die Einstellung finde ich in der GPO leider nicht, Habe es aktuell so stehen:
GPO-PFad:
GPO Einstellungen
Meine Test-VM ist Mitglied der Gruppe. Ich würde den Task jetzt direkt in der Aufgabenplanung erwarten, jedoch sehe ich da nichts
Habe die VM auch schon 2x Rebootet und per gpupdate /force die gpo neu laden lassen.
Bei der GPO ist in der Sicherheitsfilterung Authentifizierte Benutzer, müsste hier nicht meine Gruppe mit den CLients-PC's rein?
Gruß
die Einstellung finde ich in der GPO leider nicht, Habe es aktuell so stehen:
GPO-PFad:
GPO Einstellungen
Meine Test-VM ist Mitglied der Gruppe. Ich würde den Task jetzt direkt in der Aufgabenplanung erwarten, jedoch sehe ich da nichts
Habe die VM auch schon 2x Rebootet und per gpupdate /force die gpo neu laden lassen.
Bei der GPO ist in der Sicherheitsfilterung Authentifizierte Benutzer, müsste hier nicht meine Gruppe mit den CLients-PC's rein?
Gruß
Zitat von @Tezzla:
So upgraden wir nahezu alle Maschinen, auch die im HomeOffice. Kopieren aber die Sachen vorher auf die lokale Platte und prüfen den Hash der ISO. So bin ich sicher, dass auch alles Nötige kopiert wurde.
Funktioniert tadellos.
VG
Edit noch: Wenn du ein /norestart anfügst, startet er nicht automatisch neu, wenn das Setup soweit ist. Fanden unsere Benutzer ganz nett.
Das werde ich mit aufnehmen So upgraden wir nahezu alle Maschinen, auch die im HomeOffice. Kopieren aber die Sachen vorher auf die lokale Platte und prüfen den Hash der ISO. So bin ich sicher, dass auch alles Nötige kopiert wurde.
Funktioniert tadellos.
VG
Edit noch: Wenn du ein /norestart anfügst, startet er nicht automatisch neu, wenn das Setup soweit ist. Fanden unsere Benutzer ganz nett.
Kurze Korrektur: /NoReboot nicht /NoRestart
Mein Fehler.
Mein Fehler.
Du musst dazu den Task schon bei der Erstellung vom Typ "Windows 7 oder höher" nehmen!
@DerWoWusste rein aus Interesse...warum aus Sicherheitsaspekten? Wurde psexec nicht erst neulich "gepatcht"?
Wurde psexec nicht erst neulich "gepatcht"?
Nach dem Patch ist vor dem Patch. Wenn man ohne Komfortverlust Dinge sicherer lösen kann, dann sollte man das tun.psexec hat Voraussetzungen, die unschön sind, man muss remote Admin sein und man muss offene Ports haben. Der geplante Task braucht all das nicht. Auch PowerShell-Remoting ist da nicht besser als psexec und auch WinRM hatte vor kurzem erst eine ausnutzbare Sicherheitslücke.
1
Blöde Frage,
habt ihr den Task im Benutzerbereich oder Computerbereich eingetragen?
Hab sie aktuell im Computerbereich, jedoch wird die GPO nicht angewendet.
Gruß
habt ihr den Task im Benutzerbereich oder Computerbereich eingetragen?
Hab sie aktuell im Computerbereich, jedoch wird die GPO nicht angewendet.
Gruß
Im Computerbereich.
Das Troubleshooting von GPOs und deren Anwendung ist doch einfach:
Mach auf einer elevated Shell ein GPUpdate, aktualisiere die Ansicht im Taskplaner. Taucht der Task nicht auf, mach am Client auf einer elevated Shell ein
gpresult /r
Taucht die GPO dort auf? Wenn nein, dann prüfe die Sicherheitsfilterung der GPO. Passt die, dann prüfe, ob die GPO an die OU verlinkt ist, in der dieser Computer sitzt.
Das Troubleshooting von GPOs und deren Anwendung ist doch einfach:
Mach auf einer elevated Shell ein GPUpdate, aktualisiere die Ansicht im Taskplaner. Taucht der Task nicht auf, mach am Client auf einer elevated Shell ein
gpresult /r
Taucht die GPO dort auf? Wenn nein, dann prüfe die Sicherheitsfilterung der GPO. Passt die, dann prüfe, ob die GPO an die OU verlinkt ist, in der dieser Computer sitzt.
Was für ein Dritt-Tool hast Du in Benutzung? Für nahezu alle gibt es fertige Repos welche genau diese Aufgabe ausführen.
MfG,
MacLeod
MfG,
MacLeod
Zitat von @DerWoWusste:
Im Computerbereich.
Das Troubleshooting von GPOs und deren Anwendung ist doch einfach:
Mach auf einer elevated Shell ein GPUpdate, aktualisiere die Ansicht im Taskplaner. Taucht der Task nicht auf, mach am Client auf einer elevated Shell ein
gpresult /r
Taucht die GPO dort auf? Wenn nein, dann prüfe die Sicherheitsfilterung der GPO. Passt die, dann prüfe, ob die GPO an die OU verlinkt ist, in der dieser Computer sitzt.
Im Computerbereich.
Das Troubleshooting von GPOs und deren Anwendung ist doch einfach:
Mach auf einer elevated Shell ein GPUpdate, aktualisiere die Ansicht im Taskplaner. Taucht der Task nicht auf, mach am Client auf einer elevated Shell ein
gpresult /r
Taucht die GPO dort auf? Wenn nein, dann prüfe die Sicherheitsfilterung der GPO. Passt die, dann prüfe, ob die GPO an die OU verlinkt ist, in der dieser Computer sitzt.
Ja, in der Tat habe ich mich verleiten lassen und im Taskplaner des Users geschaut...
das Tool ist eine Kombination. Es ist ein Patch Management mit dem AV zusammen. Eine Scriptausführung ist aktuell nicht möglich.
Zitat von @killtec:
Ja, in der Tat habe ich mich verleiten lassen und im Taskplaner des Users geschaut...
das Tool ist eine Kombination. Es ist ein Patch Management mit dem AV zusammen. Eine Scriptausführung ist aktuell nicht möglich.
Zitat von @DerWoWusste:
Im Computerbereich.
Das Troubleshooting von GPOs und deren Anwendung ist doch einfach:
Mach auf einer elevated Shell ein GPUpdate, aktualisiere die Ansicht im Taskplaner. Taucht der Task nicht auf, mach am Client auf einer elevated Shell ein
gpresult /r
Taucht die GPO dort auf? Wenn nein, dann prüfe die Sicherheitsfilterung der GPO. Passt die, dann prüfe, ob die GPO an die OU verlinkt ist, in der dieser Computer sitzt.
Im Computerbereich.
Das Troubleshooting von GPOs und deren Anwendung ist doch einfach:
Mach auf einer elevated Shell ein GPUpdate, aktualisiere die Ansicht im Taskplaner. Taucht der Task nicht auf, mach am Client auf einer elevated Shell ein
gpresult /r
Taucht die GPO dort auf? Wenn nein, dann prüfe die Sicherheitsfilterung der GPO. Passt die, dann prüfe, ob die GPO an die OU verlinkt ist, in der dieser Computer sitzt.
Ja, in der Tat habe ich mich verleiten lassen und im Taskplaner des Users geschaut...
das Tool ist eine Kombination. Es ist ein Patch Management mit dem AV zusammen. Eine Scriptausführung ist aktuell nicht möglich.
Weia. Ich glaube ich weiß was Du meinst. Hatte ich auch mal als ultimative Lösung Für managed Services angeboten bekommen. Taugt leider nicht. Flog nach der Testphase wieder raus.
Für inhouse Netzwerk und einen IP Range ist PDQ Inventory/Deploy geeignet. Für echte managed Services als Provider werden brauchbare Lösungen gerne vierstellig.
Nun ja, mit dem Patch Management bin ich bisher zufrieden.
Patch auch nicht WIndows-Sachen.
Das was ich aber mache ist dann kein Patchen sondern ein Upgraden...
Patch auch nicht WIndows-Sachen.
Das was ich aber mache ist dann kein Patchen sondern ein Upgraden...
Zitat von @killtec:
Nun ja, mit dem Patch Management bin ich bisher zufrieden.
Patch auch nicht WIndows-Sachen.
Das was ich aber mache ist dann kein Patchen sondern ein Upgraden...
Nun ja, mit dem Patch Management bin ich bisher zufrieden.
Patch auch nicht WIndows-Sachen.
Das was ich aber mache ist dann kein Patchen sondern ein Upgraden...
Und was unterscheidet Patchen von Upgraden? Beim Wsus ist das auch ein Brei. Bei einer integrierten Deployment Lösung muss es doch auch möglich sein Dateien zu verteilen und Scripte zu laden/starten. Wie sollte man sonst Konfigurationen an PCs verteilen können, die nicht in der Domäne hängen und folglich keinen GPOs folgen? Oder wie will man eigene Pakete verteilen?
Nee, das war eine halbherzige Geschichte und wurde als supertoll angepriesen.
Wir sind geheilt.
