Jul 29, 2015, updated at 13:37:20 (UTC)

15676

Netzwerkweit auf Win10 Pro per ISO-Datei updaten - automatisiert und ohne Internet

Moin.

Die Sache ist erfreulich einfach. Man nehme ein aktiviertes Win8.1 oder Win7. Dann beschaffe man sich eine Win10 ISO (hier getestet mit Pro).

1 Nun extrahiert man den Inhalt der ISO auf eine Freigabe \\server\share
2 Nun kann man das Upgrade auf den Clients unattended starten über

\\server\share\setup.exe /auto upgrade

Alles wird behalten: Programme, Dateien und Einstellungen.
Danach kann man problemlos online aktivieren.

Weitere Optionen sind über setup.exe /? einsehbar.

Please also mark the comments that contributed to the solution of the article

Content-Key: 278702

Url: https://administrator.de/contentid/278702

Printed on: April 19, 2024 at 10:04 o'clock

38 Comments

Latest comment

Moin DWW,
das kommt mir gerade wie gerufen!

Wie bist darauf gestoßen?
Hier mal alle setup.exe-Optionen:

Gruß
Kümmel

Moin Kümmel,
wahrscheinlich im Technet den Artikel dazu gelesen...

Ich meine mit Windows 8.x ging es auch schon.

Gruß,
Dani

Zitat von @Dani:

Moin Kümmel,

Moin Dani,

wahrscheinlich im Technet den Artikel dazu gelesen...

Das war auch mein erster Gedanke.. finde den Artikel aber nicht

Kannst du mir da helfen?

Ich meine mit Windows 8.x ging es auch schon.

Gruß,
Dani

Gruß
Kümmel

Ich wusste das ja schon bei 8, siehe Upgrade von Windows 8 auf 8.1 ohne Store und automatisiert
Hatte mir damals die Optionen für setup.exe angeschaut nach dem Motto "es wird doch sicherlich Switches geben".

Ist das nicht bisschen riskant einfach so Upgrade auf "vielen" Domänen Computer auszuführen? Was ist wenn danach nichts mehr geht?

Moin Kümmel,

finde den Artikel aber nicht. Kannst du mir da helfen?

Gerne -- hier. Ist aber noch nicht für Windows 10 aktualisiert.

Gruß,
Dani

Hi vBurak.

Der Tipp hat keine Upgradestrategie vorgeschlagen, sondern nur die Methode.

Dafür nimmt man sich dann erstmal nur ein paar der Domänenrechner vor. Aktuell mache ich das bei meinem Arbeitgeber so, das erstmal nur 10 Rechner über die Methoden ein Upgrade bekommen und wenn es bei diesen 10 Rechnern alles funktioniert (Anwendungen, Einstellungen usw.) dann kommt auch ein gesteuertes Rollout für die restlichen Rechner, inklusive entsprechender Anpassung der Einstellung in Bezug auf die GPOs.

Moin,

vorab, noch bin ich in der Ausbildung zur IT-Systemkauffrau, ich hab nur bedingte Administrative Fähigkeiten aber ich hab leider nichts anderes im Internet gefunden das näher beschreibt/erklärt was der Werte DerWoWusste gemacht hat.

Ziel meiner "Aufgabe": Eine Anleitung zum Upgrade von Domain Computern auf Windows 10.

Gut wie man die einzelnd upgraded weiß ich auch, aber ich muss auch die Möglichkeit erklären wie man den Upgrade Vorgang auf alle Domain Computer 'ausrollt'....

Dafür brauche ich aber mehr Infos als nur die Sätze oben die mir zwar sagen, dass das geht aber ich nicht genau weiß wie ich dahin komme...

Könnte man das evtl. aufdröseln das ich da eine gute Anleitung draus machen kann?

Das wäre absolut toll und hilfreich und wenn nicht, dann suche ich weiter

Dankö und schönen Tag noch

Hi.

Man setzt die oben aufgeführte Zeile in einem Domänen-Startskript ein, das ist alles.
Man macht sinnigerweise zuvor noch einen Versionscheck und fährt nur fort, wenn das OS Win7 oder 8.1 ist.

Hi,
ok danke, dann werd ich das mal so aufführen und wenn da noch weitere fragen kommen dann krieg ich das schon raus

Schönen Abend noch

Zitat von @DerWoWusste:
Man setzt die oben aufgeführte Zeile in einem Domänen-Startskript ein, das ist alles.
Man macht sinnigerweise zuvor noch einen Versionscheck und fährt nur fort, wenn das OS Win7 oder 8.1 ist.

Hi, wie kann ich den Versionscheck im Script machen ?
Kannst Du mir dafür eine Anleitung geben? Müsste ja wahrscheinlich per Powershell machbar sein, oder ?

Danke und Grüße, Henere

Hi, wie kann ich den Versionscheck im Script machen ?

Powershell:

if((gwmi Win32_Operatingsystem | ?{$_.Version -match '^6\.[1-3]' -and $_.ProductType -eq 1})){  
    # Win7 -8.1
}

Batch

wmic os where (ProductType=1 and Version like "6.3%" or Version like "6.2%" or Version like "6.1%") get Caption  

https://msdn.microsoft.com/de-de/library/windows/desktop/ms724832(v=vs.8 ...

fk

Danke Dir

Hallo,

also ich versuche gerade das Scrip zu machen es lautet folgend

start "" "net use S:\\adresse02\freigabe$\Windows 10\setup.exe /auto upgrade

mit start "" "\\adresse02\freigabe$\Windows 10\setup.exe
geht es aber das ist ja nicht der sinn hier zu klicken

die Verbindung kann nicht hergestellt werden der Name ist nicht richtig geschrieben....
Jemand eine Lösung ?

Du brauchst keinen Laufwerksbuchstaben.
\\server\share\... reicht doch aus, wozu?

PS: Wenn dann
net use S: "\\adresse02\freigabe$\Windows 10"
s:\setup.exe ...

Nach s: ein Leerzeichen.

Guten Morgen

Ich versuche seit einigen Tagen das Windows 10 Anniversary Update mit einem Loginskript per GPO auszurollen.
Das ISO-File habe ich auf einen Share extrahiert und mir einen Batch mit folgendem Befehl erstellt:

"\\Server\share\Windows_10_Build1607\setup.exe" /auto upgrade

Das Skrpt rufe ich nun via Anmeldeskript über eine User-GPO auf.

Wenn ich nun vom Client aus den Batch ausführe, so installiert er das Update problemlos.
Sobald ich das Skript jedoch mit der GPO anwende, so bricht die Installation immer bei der Anzeige von ca. +/- 9% ohne Fehlermeldung ab.

Den Virenscanner habe ich deinstalliert, kann also schon mal ausgeschlossen werden.

Hat jemand noch eine Idee, was zum Abbruch der Installation führen könnte?

Beste Grüsse
Swisstom

Startskript. Kein Loginskript.
L. laufen mit zu geringen Rechten.

Zitat von @DerWoWusste:

Startskript. Kein Loginskript.

Heisst Startskript in der Computerrichtlinie?
Weil so wird die Installation scheinbar gar nicht erst gestartet...

Korrekt, in der Computerrichtlinie.
Prüfe die Zugriffsrechte auf die Freigabe. Bei anderen funktioniert es so.

Zitat von @DerWoWusste:

Korrekt, in der Computerrichtlinie.
Prüfe die Zugriffsrechte auf die Freigabe. Bei anderen funktioniert es so.

Lese-Zugriff auf die Freigabe hat "Authenticated Users". Das müsste eigentlich auch für die Computer gelten...

Richtig. Aber ist dir klar, wann Startskripte laufen (nur bei echten Starts und nicht bei fast startup) und wie sie ablaufen (unsichtbar)?

Zitat von @DerWoWusste:

Richtig. Aber ist dir klar, wann Startskripte laufen (nur bei echten Starts und nicht bei fast startup) und wie sie ablaufen (unsichtbar)?

Ok, der Schnellstart habe ich nun deaktiviert (mein Fehler...). Das Update wird trotzdem leider nicht installiert.
Es wird lediglich auf dem Client im C: der Ordner "$WINDOWS.~BT" mit ca. 252 MB Inhalt erstellt, mehr passiert dann aber auch nicht.

Dann starte setup mal per
psexec -S -I setup.exe
ohne Parameter.

Zitat von @DerWoWusste:

Dann starte setup mal per
psexec -S -I setup.exe
ohne Parameter.

Da passiert leider genau nichts, es werden nur wieder die möglichen psexec-Parameter angezeigt.
Das Problem liegt vermutlich daran, weil die Setup.exe nicht lokal sondern auf dem Share liegt.

Der Zugriff auf den Share bzw. die Setup.exe würde grundsätzlich ja eigentlich schon funktionieren, sonst würde der $WINDOWS.~BT-Ordner ja nicht angelegt, oder?

Du hast vermutlich -L und nicht -i benutzt.

Zitat von @DerWoWusste:

Du hast vermutlich -L und nicht -i benutzt.

Nein, das war schon ein "-i".

Psexec würde schon auf dem share funktionieren. Wenn die Parameter angezeigt werden, müsste es an einem Syntaxfehler liegen.

Psexec -s -i \\server\share\setup.exe
Auch die cmd muss natürlich schon elevated gestartet worden sein.

Zitat von @DerWoWusste:

Psexec -s -i \\server\share\setup.exe
Auch die cmd muss natürlich schon elevated gestartet worden sein.

So sieht die Ausgabe bei mir dann aus:

C:\>C:\Temp\PsExec.exe -s -i \\UnserServer\Build1607$\setup.exe

PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

PsExec executes a program on a remote system, where remotely executed console
applications execute interactively.

Usage: psexec [\\computer[,computer2[,...] | @File]][-u user [-p psswd][-n s][-r servicename][-h][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-<priority>][-a n,n,...] cmd [arguments]
-a Separate processors on which the application can run with
commas where 1 is the lowest numbered CPU. For example,
to run the application on CPU 2 and CPU 4, enter:
"-a 2,4"
-c Copy the specified program to the remote system for
execution. If you omit this option the application
must be in the system path on the remote system.
-d Don't wait for process to terminate (non-interactive).
-e Does not load the specified account's profile.
-f Copy the specified program even if the file already
exists on the remote system.
-i Run the program so that it interacts with the desktop of the
specified session on the remote system. If no session is
specified the process runs in the console session.
-h If the target system is Vista or higher, has the process
run with the account's elevated token, if available.
-l Run process as limited user (strips the Administrators group
and allows only privileges assigned to the Users group).
On Windows Vista the process runs with Low Integrity.
-n Specifies timeout in seconds connecting to remote computers.
-p Specifies optional password for user name. If you omit this
you will be prompted to enter a hidden password.
-r Specifies the name of the remote service to create or interact.
with.
-s Run the remote process in the System account.
-u Specifies optional user name for login to remote
computer.
-v Copy the specified file only if it has a higher version number
or is newer on than the one on the remote system.
-w Set the working directory of the process (relative to
remote computer).
-x Display the UI on the Winlogon secure desktop (local system
only).
-priority Specifies -low, -belownormal, -abovenormal, -high or
-realtime to run the process at a different priority. Use
-background to run at low memory and I/O priority on Vista.
computer Direct PsExec to run the application on the remote
computer or computers specified. If you omit the computer
name PsExec runs the application on the local system,
and if you specify a wildcard (\\*), PsExec runs the
command on all computers in the current domain.
@File PsExec will execute the command on each of the computers listed
in the file.
cmd Name of application to execute.
arguments Arguments to pass (note that file paths must be
absolute paths on the target system).
-accepteula This flag supresses the display of the license dialog.

You can enclose applications that have spaces in their name with
quotation marks e.g. psexec \\marklap "c:\long name app.exe".
Input is only passed to the remote system when you press the enter
key, and typing Ctrl-C terminates the remote process.

If you omit a user name the process will run in the context of your
account on the remote system, but will not have access to network
resources (because it is impersonating). Specify a valid user name
in the Domain\User syntax if the remote process requires access
to network resources or to run in a different account. Note that
the password and command is encrypted in transit to the remote system.

Error codes returned by PsExec are specific to the applications you
execute, not PsExec.

C:\>

Kann es erst morgen testen, melde mich.

Hi.

Hab's getestet und kann das Problem nachvollziehen.
Was geht: Du kannst weiterhin als Systemkonto (cmd über psexec -s -i cmd gestartet) lokal zum Beispiel ausführen:

c:\setup\setup.exe /auto /upgrade

Seltsamerweise geht dies nicht mehr über ein Startskript - da läuft es zwar an, aber im Schneckentempo (hier nach 2 Stunden immer noch nicht fertig - das Logfile "C:\$WINDOWS.~BT\Sources\Panther\setupact.log" wird jedoch weiterhin befüllt).

Ich werde es mir bei Zeiten nochmal vornehmen.

Hi,
in meiner Testumgebung wollte ich es auf einem Rechner ausprobieren, jedoch klappte dies nicht über "\\server\share\setup.exe /auto upgrade".
Im Taskmanager war die setup.exe zu sehen und auch der Ordner unter C:\$WINDOWS.~BT (ca. 250MB) war vorhanden, jedoch hat sich dann nichts getan.
Ich habe dann manuell die "setup.exe" ausgeführt und habe festgestellt, dass der Kaspersky (die version war kompatibel mit v1607) die Installation verhindert hatte.

Eventuell hilft diese Information einem weiter.

Bei mir liegt es nicht daran, wie gesagt, die geskriptete Installation aus der offenen Session raus klappt, nicht aber per Startskript, obwohl das selbe Konto verwendet wird. Ich werde bei Gelegenheit mal ein paar VM-Tests machen.

Zitat von @DerWoWusste:
Seltsamerweise geht dies nicht mehr über ein Startskript - da läuft es zwar an, aber im Schneckentempo (hier nach 2 Stunden immer noch nicht fertig - das Logfile "C:\$WINDOWS.~BT\Sources\Panther\setupact.log" wird jedoch weiterhin befüllt).

Das mit dem Schneckentempo stimmt (leider)!
Nach ca. 3-5 Stunden ist der Ordner aber bereits ca. 3.29 GB gross. Danach scheint die Installation allerdings stehen zu bleiben... (den Computer habe ich die Nacht durch laufen gelassen...)

So, ich habe nochmal recherchiert, wie wir das einst gemacht haben und auch geprüft, ob es mit 1511->1607 geht...und es tut!

SETUP.EXE /Auto Upgrade /Quiet /DynamicUpdate Disable /pkey W269N-WFGWX-YVC9B-4J6C9-T83GX

Das Ganze wurde eben nicht über ein Startskript gemacht, sondern über einen geplanten Task (Trigger: at system startup) mit einem globalen Admin als ausführendem Konto.

Ich denke mal, das man den pkey (hier: generischer Schlüssel) auch weglassen kann bei 1511->1607, bzw. weglassen MUSS, da Ihr ja schon aktivierte Systeme habt.

So, noch mal ein abschließender Nachtrag:

Setup-Task "1607_upgrade" per GPO verteilen. Task läuft als Systemkonto. Trigger ist "Bei Systemstart". Aktion des Tasks ist eine Batch mit

ver |findstr 14393 && schtasks /delete /tn 1607_upgrade /f && goto end
\\server\share\en_windows_10_pro_1607_x64.ISO
for /f "tokens=3 delims=\:" %%a in ('reg query hklm\system\mounteddevices ^| findstr /c:"5C003F00" ^| findstr /v "{.*}"') do (%%a:\setup.exe /Auto Upgrade /DynamicUpdate Disable)  
:end

Zitat von @DerWoWusste:

So, noch mal ein abschließender Nachtrag:

Setup-Task "1607_upgrade" per GPO verteilen. Task läuft als Systemkonto. Trigger ist "Bei Systemstart". Aktion des Tasks ist eine Batch mit

Super, so funktioniert es.
Ich habe für uns den Batch allerdings leicht geändert:

ver |findstr 14393 && schtasks /delete /tn Windows10_1607_Upgrade /f && goto end
\\Server\Share\setup.exe /auto upgrade /DynamicUpdate disable
:end

Vielen Dank für die Hilfe und Geduld!

Beste Grüsse
Swisstom

Gerne.

German Tip Windows 10 Microsoft

Hotly discussed

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

WIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 Comments

Check of ZFW Firewallgleixnerd - 2 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment