One of our engineers ran this script and it upgraded to 1909.
Yes, we checked 5 more machines and this script is upgrading to 1909.
Guys and Gals,
First, i'm not the author of this script althought we use a similar script ourselves-- the script is pulling what is essentially the MS Update Assistant, which at any given time will upgrade to the latest release, which as of last week is 1909.
There is nothing that i'm aware of to 'fix' in the script that would allow this to act differently as the script relies on the upgrade tool and the upgrade tool will always pull the latest build.
That being said i'm not sure that i've seen any real issues yet with 1909 that would cause me to worry about it over 1903.
The 1909 update is going to be entirely on Microsoft's end. This script just downloads and runs the updater from Microsoft directly. If you could find a link to the 1903 only updater, you could change the script download URL to that.
Failed THEN in step 3 (Line 3)
i am getting above error any suggestions?
Step 3 is downloading the file. There are many things that could be causing this to fail, such as network issues, disk issues, etc. The first thing I'd try is manually opening the URL in the script on a computer that is failing in step 3 and see if it does the download manually.
Is anyone having issues getting the script to run when removing the /quietinstall switch? With the switch on the script executes flawlessly, however when removed I constantly get a Failed THEN in step 4.
Do you not want a quiet install?
Unfortunately it is not feasible in my environment. The quiet install does a forced reboot and I have 24/7 endpoints so there is no "off hours" schedule to do an upgrade.
The forced reboot is a huge issue with installing feature updates this way. Users will get a popup and have about 30 seconds to save anything. I have been battling that since we started using this approach.
Just FYI: Sometimes the failure might be because of some drivers such as "Rapid Storage Technology" driver which you need to update it, or you have some software that are not compatible with Windows 10 such as "Windows Security Essential" which you need to remove it before run this script.
@Matt I've tried both /noreboot and /norestart to suppress an automatic reboot, but haven't had the time to dig into it much. Have you tested either switch to see if it prevent a reboot after the upgrade completes?
If you have 24/7 endpoints how do you do any updates? Major version releases can take an hour to reboot and come back up, so even if it was user-initiated it would still be down for that hour after.
@Adam we use the Software Management for security and important patching. We do not have many 24/7 endpoints so these updates are not the issue. From Kaseya, the /norestart and /noreboot do not work. I have not tested if those flags work outside of Kaseya agent procedures. The agent procedure runs as system so the logged on user does not see the reboot prompt because the process is not running as user. At least that is what I think is happening.
@Matt ah okay.
I just tested by scheduling from Kaseya with /noreboot and /norestart both set - after 15 minutes it hadn't rebooted but the Windows10UpgraderApp.exe process was still running, so it's unclear.
I've moved most of the workflow to powershell at this point. I monitor the install log C:\Windows10Upgrade\upgrader_default.log to get an approximation of the status. Looking at the log I see this line before it stops doing anything -
feasibly you could set up powershell to watch for that line and then kill the upgraderapp and handle reboots manually from there. I tested this manually and it upgraded the machine as expected.
For those commenting about switches not working I wanted to provide some clarification. These are not switches that are "Kaseya switches"; nor are they switches for Windows OS installation media. This is the Windows Update Assistant. Microsoft has no published "switches" I can find for it. We've experimented with this installer for some time and the best option we found was that /warnreboot does function. It however still reboots with or without user interaction to the warning message. We therefore schedule an en masse day and time for all customer PCs or for a one off basis with each user confirm a time where a forced reboot will not be problematic. Not ideal but considering Microsoft has gone out of their way to not make this easy for MSPs, something is better than nothing.
In summary, you can definitely have Kaseya procedures that will honor the /noreboot or /norestart switch. But this is specific to the installer you are using. And in this case the Windows Update Assistant installer is what this procedure is applying switches to and not the actual OS installer. This isn't a scripting issue. It's an issue that the developer didn't account for. ¯\_(ツ)_/¯
I just running this with /quiteinstall /skipeula /auto upgrade
And mine doesn't even reboot so in my case it works fine.
@Jason - do you know what the time frame for reboot is with the /warnreboot? If it is > 30 minutes or allows the end users to postpone, that would be the magic I am looking for. Sure would be nice if the standard windows switches would work for these feature updates.
That executable is always used for the current release, but it does look like it's waiting now that we're on 1909. It was definitely more aggressive about rebooting under 1903. Matt if you haven't tried it since 1909 went general release, maybe try again?
I just used this on 30-Jan-20 and it worked perfect. I used it for a Windows 7 to Windows 10 upgrade. It in fact downloaded and upgraded my PC to Windows 10 1909.
Just used it yesterday (2/5/20) to update 1809 to 1909.
This still works. It just takes a LONG time. I've had some machines take 2 hours and some take 4+ using this script, but it does work. It should run the Windows Upgrade service in the background and then reboot on it's own.
For those who think it’s not working, to troubleshoot, do it on a machine with remote access so u see what’s going on.
remember that the script itself does little, it expects the OS and the installer to work correctly.
The script simply downloads the installer and executes it in a silent sort of mode. The actual process is that the installer downloads the full update and then runs the install. The download alone will take long time and then installer will take another 30 mins at least depending on your hardware and health of the current OS. So give it time, may be configure status alert for the machine so u know it’s rebooting or some other checks like that.
i used this a month ago and it worked as expected. Have plans to use it in Feb/March to do around 150 machine in staggered manner.
We ended up moving away from this. The new Windows 10 ADMX templates offer a pretty handy way to manage the Feature Updates moving forward. https://docs.microsoft.com/en-us/windows/deployment/update/waas-wufb-group-policy
We have tested and had much better results than sending a Feature Update through Kaseya that reboots on users with only a 3-5 second warning. The down side is, it requires end users to reboot but the prompts can be set to nag enough to get the job done.
I had some systems fail to upgrade using this script and the upgrade assistant, but I traced the issue back to a compatibility issue. I found that if you try and do an update from an early build of WIndows 10, 1803 or earlier I believe, it will likely fail. The cause being incompatible features. The Microsoft PDF Printer and XPS Document Writer Features from the early builds of WIndows 10 are not compatible with the current 1903/9 release and cause the update to fail. The two features need to be removed from Windows 10 before the upgrade and can be re-installed again after the upgrade is complete.You can check if this is causing your issue by looking through the logs in the C:\$Windows.~BT\Sources\panther\ folder on the affected system. One of the logs in there will show if something on the system is blocking the upgrade for compatability reasons. This article shows the process: https://www.howtogeek.com/416169/how-to-fix-what-needs-your-attention-windows-10-setup-errors/Once the incompatible features had been removed the upgrade process went through smoothly. If upgrades don't seem to be completing, I would be look for this or similar issues. I've used this process on about 20 systems now and the compatibility of the PDF and XPS features is the only issue I have had.
Peter that's a very good point. This script, in its current version, doesn't do those checks and hence the upgrade will fail. But wouldn't it be great if there was a way to check for incompatible features before upgrade? In simply terms, script could look like
IF such and such features are present
THEN run command to remove those featuers
run upgrade installer
we can even look for specific log file that the error generates and specific content of that file to determine if it failed or not and get an email alert.
One would have thought Microsoft's own damn installer for their own damn OS upgrade would do these checks and allow us a tick to say "just do what you got to do but get this thing upgraded to 1909" but sysadmins have had it easy till now so why not thrown them another challenge.
I checked some of the PCs with upgrade issues and they are having XPS and PDF printer driver issues.
I'm adding these lines to the procedure to disable/enable features before/after the upgrade. I will test this tonight.
Disable-WindowsOptionalFeature -FeatureName "Printing-PrintToPDFServices-Features" -OnlineDisable-WindowsOptionalFeature -FeatureName "Printing-XPSServices-Features" -OnlineEnable-WindowsOptionalFeature -FeatureName "Printing-PrintToPDFServices-Features" -OnlineEnable-WindowsOptionalFeature -FeatureName "Printing-XPSServices-Features" -Online
This script still works and it will upgrade it to the latest version of windows 10.