locked
Win 10 1703 upgrade to 1803 via WSUS RRS feed

  • Question

  • Newly rebuilt WSUS on server 2016.
    Recently inherited the role and the servers where blown away and rebuilt.

    So most of our Win 10 machines are currently 1703, we want to upgrade to 1803.
    None of the machines have registered an interest in the 1803, but want the feature upgrade to 1809.
    Currently the 1803 update is Approved but the 1809 is Unapproved.

    Is there a way we can manipulate the machines to take 1803 and not the latest 1809 that is available.
    We also have a bunch of win 7 machines with appropriate memory and processor to get an upgrade as well.
    They have also registered an interest in 1809 but not 1803.

    do we have to decline 1809 as no testing has been done for it yet on our internal systems.

    Tuesday, December 4, 2018 3:25 AM

All replies

  • Hello,
     
    You want your clients to upgrade to 1803, not 1809, right? Just approve 1803 upgrade, and keep 1809 upgrade unapproved. You do not have to decline 1809 upgrade, but you could if you do not want them to show up in the WSUS console.
     
    You also should enable policy "Do not allow update deferral policies to cause scans against Windows Update" to prevent clients get an upgrade from the internet.

    Hope my answer could help you and look forward to your feedback.
     
    Best Regards,
    Ray

    Please <g class="gr_ gr_15 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar multiReplace" data-gr-id="15" id="15">remember</g> to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Tuesday, December 4, 2018 6:12 AM
  • i thought that would be the case and have approved the update for 1803 for windows 10 machines and also the update for win 7 machines... so far none have registered they need the update under the needed column. while every machine so far have requested the latest 1809 update be them 7 or 10 machines.
    Wednesday, December 5, 2018 3:06 AM
  • Hello,
     
    Sorry for misunderstanding your meaning before. Your issue is that the clients want 1809 rather than 1803, but you want to deploy 1803, not 1809, right?
     
    If there is the latest upgrade in the WSUS, the clients would not want the upgrade for the old version. So you should decline the 1809 upgrade, then check for updates on the client side. I believe they would need 1803 upgrade this time.
     
    Hope my answer could help you and look forward to your feedback.
     
    Best Regards,
    Ray

    Please remember to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, December 5, 2018 5:36 AM
  • Unfortunately you must decline 1809 to get your systems to want 1803 as it supersedes all other versions and Windows 10 wants to be updated to the most current version available. After it's declined, Windows will see 1803 and 'need' it. Since it's already approved, it will start the installation. Make sure you have the ESD mimetype setup - https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-3-windows-as-a-service-waas-and-group-policy-administrative-templates/


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Saturday, December 8, 2018 4:58 PM
  • So boss approved 1809 testing which means i dont need to decline now.. approved the win 10 upgrade and it rolled out fine to my test machines.. approved the win 7 upgrade to win 10 which had computers saying "needed" to my test group and the install is failing.

    I am running Server 2016 and .esd was already in MIME/Types but as "application/vnf.ms-cab-compressed.
    When i look at the error message on the server it say, "(Unable to find resource) ReportingEvent.Client.181

    Sunday, December 9, 2018 9:54 PM
  • Have you run a wsusutil reset? From an Administrative PowerShell prompt:

    "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" Reset

    Leave your WSUS Server alone for a full 24 hours. There are no notifications of when this process is running or finished. The reset will verify that every update metadata row in the WSUS database corresponds to update files stored in the local update file storage location on your WSUS server. If update files are missing or have been corrupted, WSUS downloads the update files again.


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Monday, December 10, 2018 4:46 AM
  • Hello 
     
    Check if the registry key "DisableOSUpgrade" is set to 1, if yes, change it to 0. The key's location: HKEY_LOCAL_MACHINE\SOFTWARE\POLICIES\Microsoft\Windows\WindowsUpdate

    If the key is set to "0", and it still doesn't work, then we may add a registry key AllowOSUpgrade to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\OSUpgrade, create DWORD AllowOSUpgrade, set the value to 1.
     
    I find the following 2 posts for you, please check if they could help you.

    https://social.technet.microsoft.com/Forums/lync/en-US/785dca44-9b04-45b5-b431-2efe6bf9e92b/wsus-win-7-to-win-10-upgrade-not-working?forum=winserverwsus
     
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/fdb1ed67-3199-40f8-9ddb-8d6fe469e101/upgrading-to-windows-10-using-wsus-doesnt-work?forum=winserverwsus
     
    Hope my answer could help you.
     
    Best Regards,
    Ray

    Please remember to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, December 10, 2018 9:44 AM
  • i checked these reg settings yesterday and it made no difference for the updates deployment
    Tuesday, December 11, 2018 12:16 AM
  • Thanks Adam, have run the command and will see what eventuates.. :-)

    do i need to do the same on a downstream WSUS server as well after the 24hours?

    • Edited by mis_super Tuesday, December 11, 2018 12:22 AM
    Tuesday, December 11, 2018 12:19 AM
  • If you have a system that tests working after the reset on the upstream, your downstream 'should' get the files on the next sync. If not, you can run the wsusutil reset on there too.

    Worst case scenario, remove and reinstall WSUS and reattach it to your upstream - assuming it's a replica, this is the easiest way to fix it.

    https://www.ajtek.ca/wsus/how-to-remove-wsus-completely-and-reinstall-it/


    Adam Marshall, MCSE: Security
    https://www.ajtek.ca
    Microsoft MVP - Windows and Devices for IT

    Tuesday, December 11, 2018 1:31 AM
  • The "AllowOSUpgrade" reg key actually did the job for me.

    I have been on forums regarding this the inability to upgrade Win10 builds for a couple of months now and im so happy that i have found a method! Thanks a lot my friend.

    Sunday, January 26, 2020 3:47 PM