Upgrade to Spring Creators Update
This agent procedure will upgrade Windows 10 to the Spring Creators Update (Build 1803.)
This will perform an entire Operating System upgrade, it is recommended to perform a backup and/or system restore point before proceeding with the OS upgrade.
The workstation will be restarted as part of the procedure.
This listing does not provide the ISO file.
The whole process takes between 45 minutes and 2 hours until the workstation can be used again.
It is recommended to have at least 20Go free on the endpoint before running the procedure, otherwise the procedure could fail without giving any error message.
The required ISO can be downloaded here.
Once the ISO is downloaded you will need to split it up in multiple smaller files, I recommend 3 files of about 1.2Go each, but more files or smaller size should not cause any issues.
Here is a tutorial on how to split the ISO to multiple .zip.001 files to be used in the procedure: How to Split a File Using 7-Zip.
Keep in mind, if you previously used this agent procedure to upgrade to 1703 or 1709, the procedure itself has not changed, you may want to just replace the files to create the ISO.
The listing was edited to add a file less version of the procedure. It does not require the ISO file as it will download the upgrade tool directly from Microsoft and start the upgrade process. The upgrade takes longer this way but avoid the trouble of finding the ISO, splitting it and uploading it to the server before spreading it out to the environment.
Windows 10 Spring Creators Update has no reviews.
Note: To hit the download page you must use an alternative user agent if you are on windows otherwise it will just give you the download tool. I assume the writer of this was probably using a mac and the reason why it would pull the ISO rather than the tool.
Example extension for chrome that does user agent switching: https://chrome.google.com/webstore/detail/user-agent-switcher-for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg?hl=en-US
@Jay, Thanks for the notice. You're right, I am using Mac and the page lets me download the iso file.
The procedure finishes running and says "Success" after it runs the Powershell script which starts the actual update. This means there's no way of knowing that the update is running, or whether or not it was successful. Can anyone think of a way to monitor this?>
Instead of downloading 4 GB from the kserver, why not use the Windows 10 update tool (6 MB)? It's available on the same page you linked to by hitting the Update Now button. My script downloads this tool, then runs "#vWorkingDir#\Windows10Upgrade9252.exe /quietinstall /skipeula". It installs in the background, then prompts for a reboot. The reboot took 20 mins on my computer, then a few extra minutes at the login and they are done. It would also be helpful to add a disk space check.
Marc, A+ my man. much easier.
Marc, excellent idea. I prefer downloading the ISO though to larger clients because it only has to download once to the LanCache. The tool would require every machine to download the bits.
Thanks guys for the feedback. @Marc, that's great, I'll add a new version of the script when I have a chance to at least give the option.
Can anyone give an example script of what Marc is talking about?
Here is the basic flow of the script I use:
SendMessage("A Windows 10 Feature Pack has started installing on your computer. When it completes you will be prompted to reboot to complete the install. We recommend delaying this reboot until you go to lunch or go home for the day. The reboot will take around 1/2 hour."
getVariable("Agent Working Directory Path", " ", "vWorkingDir"
exeuteShellCommand("#vWorkingDir#\Windows10Upgrade9252.exe /quietinstall /skipeula"
I tested this on 25 systems at a client over the weekend. It upgraded 15 of them. A few were offline and I'm not sure what happened on the others yet.
Does anybody know how to do a "clean up", like the 1709 procedure does? It'd be nice to free up ~4gb of space.
@Jeremy You can use the same procedure that 1709 does. Or modify the 1709 procedure to use the 1803 files.
Is there a limit on the storage space? I tried to add the 1803 files, but it keeps failing. Currently I have ~4gb of the 1709 files up there. Do I even need the 1709 files any longer? Can I go straight to 1803 on all machines?
Is it possible to force a restart after installation? is it /forcerestart ?
The procedure is supposed to restart the endpoint automatically. The arguments used are /quiet and /auto upgrade which restart the endpoint if the upgrade processes correctly. If it does not it will silently exit and will not restart the endpoint.
@Marc, thanks. Your script has worked on all my endpoints.
I edited the listing to include a file less version of the script using the commands Marc suggested.
Has anyone else found situations where the script appears to have run successfully, but the update doesn't appear to run? There's no indication of anything running or having run in the event logs at all even though the script did run, the ISO was created, etc.
Gavin I have had similar things happen with the fileless version due to hard drive space issues.
I'm having an issue where the ISO won't mount, it successfully downloads the rar. files extracts to an ISO but never seems to mount and execute the install. Anyone else have this issue and any tips on fixing it?
Hey Louis, I don't think I've heard of anyone having the same issue. I suggest troubleshooting the powershell commands on that specific machine. It could also be the lack of disk space. Otherwise I would try the file less version of the procedure that does not require the iso and will download all the required files from Microsoft directly.
Doug, I had to break up my zip parts into 100 MB pieces to get reliable downloads, especially for those on slower connections. Follow the instructions carefully. I would not use RAR parts, but ZIP parts so the rest of the language of the script works. We have also engineered this procedure to update Windows 7 downgrade systems what have a Win 10 bios key. Works perfectly. I'll likely post here as we are all going to need this for the 2020 EOL of Win 7.
don't think it has to do with disk space, system has roughly 50 gb free I could expand it if needed as it's a VM for testing this. That said I am now attempting the upgrade via the fileless script. So far so good it seems to be creating the folders now I will report back with results.
any chance you now of a way to audit for which systems have the Windows 7 downgrade? That was my next project as my company is starting to look towards Win 7 EOL
Thanks in advance
@Jeff, thanks for the feedback, I will most likely only use fileless moving forward if it works for 1809.
@Louis, Keep me in touch so I can help troubleshoot.
@Louis. We're still trying out a few options for getting info on the BIOS key. You can use "wmic path softwarelicensingservice get OA3xOriginalProductKey", but it doesn't tell you what OS its for. I am still looking for a way to validate that key and reveal its product. We've been using ShowKeyPlus (https://github.com/Superfly-Inc/ShowKeyPlus/releases/tag/ShowKeyPlus6594) in the GUI to collect info. We've been finding that if the system's DOM is after Jan 2016, your usually good. Some late 2015's are OK, too. Anything earlier and its usually Win8. You'll need to get a VLK for those and use the /pkey switch on the setup command to upgrade them.
thanks, keep us posted as that is going to be very valuable going into 2019.
Ran the fileless script twice today both successful, second one is rebooting now. I completely missed the fileless version in the original import, so thanks for pointing that out.
As promised. See link at the bottom of this posting for a pair of scripts for upgrading Win 7 to Win 10.
This is broken into two parts. Step One is to download and extract the ISO using PeaZip (procedure also included - sub with your fav command line tool that can extract an ISO) and verify it's complete. Change email steps for the proper SENDTO for your staff. Handy for preparing the files well before your scheduled execution time, especially if the endpoint is on a slow connection.
Second is to execute the install. Schedule with the customer to minimize impact on system availability and any orientation and post install work you'll need to do. Change line 2 to fit your needs and for alternate paths for the executable than the #vAgentConfiguration.agentTempDir# variable. We've found that having a log file is really handy if the install fails. If you decide to run from a server over a UNC path, don't forget to UseCredential and set the machine credentials to some domain creds that have access to the share. Add the /pkey switch for your OpenLicense VLA or retail key. Otherwise, leave out if it has a valid OEM key in BIOS. We've used a combination of ProduKey and ShowKeyPlus to get the BIOS key from each machine and then test it for the Windows Edition.
When using ShowKeyPlus and ProduKey were you able to pull that info back into a Kaseya custom field for report generation?
No. ShowKey Plus doesn't have a CLI. ProduKey does and you can create a script that can pile it onto a network share for you to parse later. You can then open ShowKeyPlus and copy in the Bios key under the "check product key" link at the top of the screen. I'm sure if you're really good at procedures that you can create one that will read the result file, look for the string, and put it in a custom field in the agent. I just haven't had the time to make that one yet. You'd still need to copy and paste the key, so it's hardly worth the effort.
thanks for the quick response, I'd love to figure out how ShowKeyPlus is pulling that info as it might shed light on how we can incorporate the solution into Kaseya.
For your information, I created a new listing to upgrade to 1809. The procedure is file less such as 1803 and is essentially the same except using the new install file.
You can find it here.
Let me know if you guys have any questions or feedback.