Windows 10 October 2018 Update
Upgrade Win 10 to October 2018 (1809)
Upgrade Win 10 to October 2018 (1809)
This agent procedure will upgrade Windows 10 to October 2018 update (Build 1809.)
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.
The whole process takes between 45 minutes and 2 hours until the workstation can be used again.
It is recommended to have at least 20GB free on the endpoint before running the procedure, otherwise the procedure could fail without giving any error message.
This listing does not require to upload any files. It will download a file directly form Microsoft to perform the upgrade.
We suggest researching the potential impacts of these update(s) to your systems prior to deployment as 1809 has been known to cause BSOD in some environments.
Here is a Webinar we made about how to help the upgrade process and what to watch for before hand.
Windows 10 October 2018 Update has no reviews.
You can change the command line to add a /NoReboot so you can better control the reboot (i.e. prompt the user what's going to happen). Note this only affects the first reboot. That makes sense, as the user has no idea something is going on prior to the first reboot. After the first reboot, the system is going through setup so it's obvious what's happening, and the subsequent reboots don't impact a user as they can't work.
Microsoft docs say:
/NoReboot
Instructs Windows Setup not to restart the computer after the down-level phase of Windows Setup completes. The /noreboot option enables you to execute additional commands before Windows restarts. This option suppresses only the first reboot. The option does not suppress subsequent reboots. For example:
Setup /noreboot
David,
Thank you very much for the reply and yes I meant the first reboot. Just want to make sure I get this right, do I add it between /skipeula and /auto upgrade :
#vAgentConfiguration.agentTempDir#\Windows10Upgrade9252.exe /quietinstall /skipeula /auto upgrade /copylogs #vAgentConfiguration.agentTempDir#\logs
Or between executeShellCommand and scheduleProcedure steps?
Thanks
between /skipeula and /auto upgrade should be fine... it needs to be on that command line
You'll have to add some checking to determine when the reboot needs to occur, then trigger the reboot warning to your user. Of course, you could "assume" the initial process will take X minutes and just do the reboot after. That's uglier than heck.
I haven't looked to determine what to parse out of the log, or if there is an errorlevel status returned that would be your trigger for doing the reboot. Shouldn't be hard to determine.
Course you could turn this on it's head and just run thru the process if the machine does NOT have a logged in user, and if it does, just pop up a message asking the user to logoff when they are done so you can run the update. Then schedule the update to run again in 30 minutes. It'll keep looping and rescheduling every 30 minutes if a user is logged in, and if not then the update will fire off. Let it reboot as it wants to since no one is logged in, no one will care.
Hi, What would I need to add to this script for it to pull from a UNC path as opposed to downloading it from the internet?
Hey @Andy.
I would recommend taking a look at the discussions in these 2 listings as a lot of customers shared the way they modified the procedures for their network/environment.
https://automationexchange.kaseya.com/products/443
https://automationexchange.kaseya.com/products/492
Has anyone encountered the confirmation screen for driver issues while running 1809? I premarily use HP laptops and workstations and have a confirmation screen that I must click 'confirm' on due to a possible xxx driver problem (audio driver I believe). I've used a modified version of your script here for the last 3 major updates, but wonder Is there anyway to suppress this confirmation?
I see this procedure uses /skipeula but I don't see that listed in the Setup Command Docs from Microsoft, does it function the same way as the /ShowOOBE none flag/switch or should I include that as well?
Is there an updated script for 1903?
Hello.
actually Windows10Upgrade9252.exe updates to 1903 so this procedure works just fine. for 1903 upgrades if you don't get 1903 when using Windows10Upgrade9252.exe. you machine is not yet ready for 1903.
thanks Andreas, I shall test this out.
Tried the procedure on about 5 machines and it did absolutely nothing. Shows completed in Kaseya but did absolutely nothing on the desktops.
I've tried this on 3 machines and all of them worked. the full procedure takes close to 3 hours.. it reboot in 3 hours
I ran it on about 450 machines with about a 75% success rate. It does take several hours to run and there are many factors on why it might not upgrade (incompatible apps, disk space, etc...) Overall this uses the most practical/streamlined method for upgrading.
I let it run over night. So it had roughly 12 hours. Morning comes around and Kaseya showed it ran successfully. I ran winver after that on these PCs and it still showed 1803. Run manual updates and it finds 1809 and installs without issue. So I can say something is not working as intended.
I had to update the download link for 1903.
https://go.microsoft.com/fwlink/?LinkID=799445
Other than that, this script does work, and has worked even for 1809. If it fails, then there is an incompatibility issue on the machine (drivers, apps, HDD space etc) which unfortunately will not record, but you can check the install logs. The script itself completes fast, but if you check your processes, the Windows Upgrader is in fact working. Can take anywhere between 45 minutes, to 3 hours to complete the installation and reboot.
Rocky,
A problem that I had was that I had forgotten to go into the options to type "YES" when scheduling the task since it asks if a restore point has been created. If you don't do that in the scheduler, it will do nothing.
I agree with Mike, I have run this on around 100 computers and most do upgrade, possibly around 80%, but a few do absolutely nothing but not due to a fault of this script, this script is amazing.
Actually Ken you are supposed to type True from what I can tell. Ryan it has failed now on about 10 PCs I have. So if it is not the script it is Kaseya. Machines have no issues updating themselves. The script shows it completes fine but does absolutely nothing on the PC.
You could also edit the script and remove the prompt asking if you created a restore point.
Good point Ken, I forgot to mention I stripped that out of this script and changed the location of where everything was located instead of the working directory. I also updated it to let the script reboot if the user wasn't active and if they were it would do the upgrade but wouldn't reboot.
Rocky, once you kick the script off, check the process on the machine and check if Windows10Upgrade ( i think thats the name) is running. If it is, then its not Kaseya, nor the script. If it still doesnt upgrade with that process running, then the machines are not compatible.
Nicholas if the machines were not compatible it wouldn't work through manual updates.
So it is either the script or Kaseya. Considering it is the only procedure I have that doesn't work......
Edit the URL with this one then.
https://go.microsoft.com/fwlink/?LinkID=799445
I updated about 15 machines today to 1903.
I just want to chime in and say that I downloaded and executed this for the first time ever today, on one specific computer. The script shows successful (no errors). I watched the available disk space go down by 4GB, and I saw the kworking directory sprout new Windows 1809 files. But, eventually it just stopped doing anything. I let it sit for about three hours, and then I noticed when I clicked Start, I saw "Update and Restart" or "Update and Shutdown". This is new, so the script clearly did something. I clicked "Update and Restart", and during boot, Windows ABSOLUTELY was upgrading something. It took about ten minutes (it's an SSD, so it's fast).
But that's where my success ends. After logon, winver still shows 1803, so I'm not sure whatever this script did was ultimately successful.
Ken lost me at "yes". I only see options to enter "True" to confirm a backup has been done. I ran this a few months ago on my own computer and it worked. Running it now for a client and it does nothing as far as upgrading, although i see it had downloaded the Windows10 update assistant and i can even see it starting to run in Task Manager. Somewhere along the line it just stops and never completes the upgrades. Systems have plenty of resources and are compatible. In fact, if i circle back and run the same exact commands from the systems locally and manually, the entire process works fine and the systems upgrade. So I don't necessarily agree with some of the posts that suggest endpoint issues if it doesn't run. Could be in some cases, but in my case there's no logical reason for it failing, otherwise the commands would have failed when running manually. One thing is certain, the logging switch doesn't seem to work and is not writing, so we get no clues as to when it breaks. I have a call pending with the author next week, will post what i find. Good discussion!
Hey guys,
Thanks for all the feedback. Like mentioned sometimes the script will run "successfully" but the upgrade won't finish. From what I've experienced this is usually (but not always) due to some incompatibilities from Windows or some 3rd party apps. The best solution I found was to run the upgrade manually, it should give you an error message which will tell you what went wrong. There is a switch included to write the output in a logs but it does not seem to work correctly as I don't always get populated by the tool.
Also, like mentioned by some of you guys, I added this "True" check just to be safe, but feel free to remove it as well as the if statement so that you don't have to supervise the script.
So Todd, I am not alone in this and it sounds like this is a script issue. I look forward to hearing how that call goes. Ultimately I think I am going to have to enable automatic updates across my organization as Kaseya cannot update Windows 10 properly.
FYI - It does not work with Enterprise.
Not using Enterprise just Pro.
I have use the script as well and have positive results with it.. I currently just created a second one for the 1903 update and running it on my machine.. I wish there was a way to get the download locally and pull from a fileshare to help speed up the process of the download.. But in the interim, this script does work as advertised..
Buster it doesn't sound like it is working for everyone.
Buster it doesn't sound like it is working for everyone.
@Buster you could use older version of the procedure and use the ISO instead of the media creation tools. The ISO could then be spread out over the network instead of having to be downloaded from each agent.
I can confirm it works on both enterprise and pro. Make sure UAC is disabled and remove the prompt. Update the URL link like i mentioned in a earlier post. I can assure this script works. I updated 15 machines, both pro and enterprise just fine today (to 1903).
I can share my modified script tomorrow to anyone who wants it. Disables uac, downloads upgrader and installs, cleans up all files after, then disables win defender.
I also updated 900 win10 endpoints to 1809 using this script
Hard to blame the Kaseya script when it is just downloading a Microsoft executable and then running it with switches. If the file is downloaded to your working directory or wherever you have it place the file, then the script is working. Try running the exe manually so you can see why it is failing.
Hi Nicholas,
Yes, I would love your modified script.
I prefer a script that accommodates as many scenarios as possible.
Dhaval
Can't get it to work on 1 of 10 machines. You are also modifying the script telling the script is the problem.
@art hit the nail on the head...
I am blaming the software management module. Why do we need a procedure when that should be able to update our machines. It cannot do it, fault or no fault, it cannot update our machines automatically. So honestly its time to use a different process entirely.
Nicholas,
I would like your modified script as well. Will this re-enable UAC after the update?
Brandon, you can just add a line to reenable it. Its just a regedit. I did it as precaution. The only failures ive seen have been incompatible machines due to drivers, apps, or hdd space. Ill see if i can upload it tomorrow. Im out.
I don't think it's a script issue, it's really simple if you dig into it. Some MS voodoo going on IMHO. Bob, what's the logic on not working on Enterprise? Is that your experience or a known fact? The client i'm testing on just happens to be Enterprise, but again you have to keep in mind that the SAME EXACT lines of code run manually work just fine, start to finish, upgrade successful. So not sure the logic on why it "doesn't work with Enterprise". It's just a simple script, should be nothing in Enterprise to keep it from running. Remember, with the script i'm getting the update files downloaded, and update assistant starts running in Task Manager, so the script seems to work and at least start something. The update process just peters out. I don't think that's a script problem, gotta be some other oddness that might vary from case to case. Lot of factors can be involved in any install/upgrade.
I agree with Art, it doesn't do much besides download the upgrade assistant and runs it with some flags. In ideal conditions, the script runs fine on hundreds of machines. The script also calls another script for "cleaning up" the upgrade files, although I haven't seen this be an issue, you could try increasing the time from 180 to like 280 minutes this way it doesn't try to clean up the upgrade files while it's trying to upgrade. Unfortunately, there's no great way of knowing when to schedule the script as the upgrade could take 30 min to several hours.
Hey Rocky
Do you mean the patch management module?
I do kinda agree with you and I personally believe Kaseya Patch module should do it.
Considering how big a deal Windows 10 version upgrade is, I think Kaseya themselves should make some effort and either do a foolproof agent procedure or a built-in facility.
If anyone knows Kaseya the best, it is Kaseya themselves.
In the mean time, us admins got to get our hands dirty with scripts and things like the old days.
BTW, although off topic a little bit, I only know Kaseya as the RMM tool that has its own scripting engine. No other RMM tool I know has it. Everyone else expects you to use powershell or vbscript or good old batch files so there is that.
Dhaval
For guys wanting prompts for reboots, I think this process is extensive and you really don't want to do it during working hours anyway. We schedule maintenance along with patch management overnight so might as well do this at the same time.
Used this script for the first time last night. Main issue for us is that it doesn't have any kind of build number so it updates the machine all the way to 1903 which has a ton of issues right now and we don't want anyone going above 1809 which is what is required for Intune / Bitlocker.
Here is was my process to have the updates stop at 1809
1.Tested the procedure and it updated successfully from 1803 to 1903.
2.Set a feature update deferral GPO and set to semi-annual channel, defer 60 days. Set locally on machine
3.Ran the procedure again and it tried using the files it downloaded before for 1903.
4.Cancelled and deleted those files in c:\windows10upgrade and ran procedure again.
5.Started downloading 1809.
6.Installed 1809.
7.Created GPO for update deferral and applied to auth users.
You can confirm the update is taking effect in ResMon, it will say the file name which contains the build number so you can tell which version its trying to install.
Hope this helps those having issues with pushing all the way to 1903
Nicholas, can you send to me?
Dhaval,
We moved away from patch management to software management which is Kaseya's new flagship update module.
I'll agree with @Nicholas about having UAC turned down (Never Notify), if it isn't already. Should be a procedure already in your Core folder to do just that. Works fine on Pro/Enterprise for us.
Hi Guys, thought I would chime in on this.
I used this script (or at least a modified version) to update around 500 machines to 1809 about a month back. I agree with the comments regarding the Software Management Module (which replaces the patch module) this 100% should help to upgrade feature updates. Unfortunately, it doesn’t, and on at least the SAAS platform is absolutely rubbish and has created no end of problems for us over the past few months. But that’s a different story.
We experienced the same mixed results using the procedure. Sometimes machines would upgrade without issues, others it would be down to an incompatibility issue with software on the machine, and at other times we just had no clue why it wasn’t upgrading. Mostly a manual upgrade fixed the issue, and even more confusingly most of the time the manual upgrade would run where the script had failed, usually without any indication of a warning or that something wasn’t working correctly. The tricky part was diagnosis, I never managed to get the logging working correctly. As it’s been pointed out it’s just a command line switch on the upgrade file, so that’s probably more down to Microsoft issue than Kaseya.
In the end I modified the script to use an upgrade ISO instead of downloading the windows update exe and draining bandwidth. I found this method far more reliable than the original script as well. I downloaded the ISO from the Microsoft website, (you need jump through a few hoops to get it), but it is available.
We have probably around a 50% split of workstations and Laptops. For workstations I had a separate script to copy the ISO from file server and for laptops I pointed the download to come directly from the Microsoft website. This seemed to be the most reliable method for us.
Anyway, we are now looking at upgrading to 1903 in the next few months. I have installed the new Windows Update For Business group policy admx and set all our workstations to delay feature updates for 365 days so we have more control over when we upgrade (automatically through Microsoft was just far to problematic). I have also started to link our workstations back to the Windows Analytics Update and Compliance module and Update readiness module so we can get a better understanding of problematic machines. Hopefully this time we will be a bit more prepared! Interested to know what others are dong regarding a feature update strategy.
I am doing the same as you. I have downloaded the ISO file. and running the setupt.exe /auto upgrade etc etc. with supress reboot. and made a small "app" that tells the user when the machine is ready to restart. and they restart the machine. and the reboot takes around 5-10 minutes to finish up the update.
But at the end of the installation KAV is creating a bsod just before the hello we are getting everything ready etc etc starts. so when it's 100% I get PAGE FAULT IN NONPAGED AREA ntfs.sys. and then it restarts and finish up the hello welcome etc, and it's all good. But If I uninstall KAV first there is no bsod and all is good. I use KAV version 10.3.3.275
Andy, can you provide a copy of your script showing the part for using the ISO instead of the download
Sure, for the file-less basically had Kaseya copy the ISO off the file server into the kworking directory using the below script then run a power shell scipt to mount the ISO and run with relevant parameters:
Script:
Sure, for the file-less basically had Kaseya copy the ISO off the backup server using the below script then run a power shell:
For the file less:
<Procedure name="Windows Upgrade (UNC) Jersey 1809" treePres="3" id="2142470099" folderId="555542968285988" treeFullPath="myProcedures - xxx@xxx.com.Windows 10 Upgrade">
<Body description="">
<Statement name="GetVariable" continueOnFail="false">
<Parameter xsi:type="EnumParameter" name="VariableType" value="Prompt" />
<Parameter xsi:type="StringParameter" name="SourceContent" value="Type "True" to ensure a backup or restore point of the endpoint was performed" />
<Parameter xsi:type="StringParameter" name="VariableName" value="test" />
</Statement>
<If description="">
<Condition name="CheckVariable">
<Parameter xsi:type="StringParameter" name="VariableName" value="#test#" />
<Parameter xsi:type="EnumParameter" name="Condition" value="Equals" />
<Parameter xsi:type="StringParameter" name="Value" value="True" />
</Condition>
<Then>
<Statement name="ExecuteShellCommand" continueOnFail="false">
<Parameter xsi:type="StringParameter" name="Command" value="robocopy /xc /xn /xo \\fileserver\Upgrade\ c:\kworking" />
<Parameter xsi:type="EnumParameter" name="ExecuteAccount" value="System" />
<Parameter xsi:type="BooleanParameter" name="Is64Bit" value="False" />
</Statement>
<Statement name="Execute Powershell Command (64-bit, Run As System)" continueOnFail="false">
<Parameter xsi:type="StringParameter" name="Parameter1" value="c:\kworking\upgrade.ps1" />
<Parameter xsi:type="StringParameter" name="Parameter2" value="" />
<Parameter xsi:type="StringParameter" name="Parameter3" value="False" />
</Statement>
</Then>
</If>
</Body>
</Procedure>
PowerShell Script:
$mountResult = Mount-DiskImage C:\kworking\Windows1809.iso -PassThru
$driveLetter = ($mountResult | Get-Volume).DriveLetter
$setup = join-path -path ${driveletter}: -childpath setup.exe
& $setup /quiet /auto upgrade /Compat IgnoreWarning /DynamicUpdate disable /CopyLogs C:\kworking\w10updatelog.log
For the File less Script I had to use a link from the Microsoft website. It expires after 24 hours so the below won’t work. To get the URL you need to log on in to the download site in compatibility view as a non windows device (e.g Ipad) Then you are able to copy and use the full link. There are plenty of tutorials online how to do this. In the future I’m going to upload the ISO to a FTP server and have our clients download from there as using this method meant i had t change link every night!
<?xml version="1.0" encoding="utf-8"?>
<ScriptExport xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.kaseya.com/vsa/2008/12/Scripting">
<Procedure name="Windows Upgrade (Fileless) 1809" treePres="3" id="1068905976" folderId="555542968285988" treeFullPath="myProcedures - xxx@xxx.com.Windows 10 Upgrade">
<Body description="">
<Statement name="GetVariable" continueOnFail="false">
<Parameter xsi:type="EnumParameter" name="VariableType" value="Prompt" />
<Parameter xsi:type="StringParameter" name="SourceContent" value="Type "True" to ensure a backup or restore point of the endpoint was performed" />
<Parameter xsi:type="StringParameter" name="VariableName" value="test" />
</Statement>
<If description="">
<Condition name="CheckVariable">
<Parameter xsi:type="StringParameter" name="VariableName" value="#test#" />
<Parameter xsi:type="EnumParameter" name="Condition" value="Equals" />
<Parameter xsi:type="StringParameter" name="Value" value="True" />
</Condition>
<Then>
<Statement name="GetURL" continueOnFail="false">
<Parameter xsi:type="StringParameter" name="URL" value="https://download.microsoft.com/download/9/4/E/94E04254-741B-4316-B1DF-8CAEDF2DF16C/Windows10Upgrade9252.exe" />
<Parameter xsi:type="StringParameter" name="ResponseFileName" value="#vAgentConfiguration.agentTempDir#\Windows10Upgrade9252.exe" />
<Parameter xsi:type="BooleanParameter" name="WaitComplete" value="True" />
</Statement>
<Statement name="ExecuteShellCommand" continueOnFail="false">
<Parameter xsi:type="StringParameter" name="Command" value="#vAgentConfiguration.agentTempDir#\Windows10Upgrade9252.exe /quietinstall /skipeula /auto upgrade /copylogs #vAgentConfiguration.agentTempDir#\logs" />
<Parameter xsi:type="EnumParameter" name="ExecuteAccount" value="System" />
<Parameter xsi:type="BooleanParameter" name="Is64Bit" value="False" />
</Statement>
<Statement name="ScheduleScript" continueOnFail="false">
<Parameter xsi:type="StringParameter" name="ScriptName" value="1310283224" />
<Parameter xsi:type="StringParameter" name="TimeDelay" value="180" />
<Parameter xsi:type="StringParameter" name="MachineID" value="" />
</Statement>
</Then>
</If>
</Body>
</Procedure>
</ScriptExport>
Sorry correction to the above, first script is for the file copy, second is the file less
Andy, an you send the XML.. I get error messages when i try to do the import.. Feel free to send me an email to bdavis@lineagelogistics.com
Thanks
The fileless works great with desktops computers, but I don't know why for laptops is not working. Even if I use"run now" button
Hello All,
Looking through this I'm looking if someone can share the XML file that will upgrade straight to 1903.
Hi Juan. I updated the file less URL part of the script.
If you want, write to me : fernando_valbuena@jambrina.com I will send the script
I noticed the for some computers does not work and the reason is Intel® Rapid Storage Technology is not updated.
Keep that windows driver update so the script runs ok
I've tried using the /noreboot argument in the procedure, but the update assistant reboots anyways.
I've also tried using /norestart.
Anyone have any tips?
@Alexander Kim
I've come across the same problem.
When the script is complete it reboots, but when you use /norestart the user is propted with a popup that the pc will restart in 30 minutes (they can skip it they want). Since you run the cript as system, it won't show the user anyting.
If you run the script as user, it does as expected, it shows the user a promt, urging them to restart.
If you like to have the script, e-mail me on jblankestijn(at)vanessenict(dot)nl
I've also added a few steps to disable UAC during procedure execution.
Hello All,
Is there a way to have Reboot prompts implemented during this process? So far it just reboots the pc when needed, but i would like to have some reboot notifications prompts.
Thanks