Windows 10 Feature Updates: 0xc1800118 error with WSUS on Server 2016 RRS feed

  • Question

  • Hi all,

    We have a 2012 R2 WSUS server, and I couldn't push any Feature Updates to Windows 10 clients due to the following error:


    I tried many times applying the workaround in the above link, but without success.

    So, I built a new WSUS server on 2016, on the understanding that decryption of Feature Updates is built-in (installed latest 2016 cumulative update just in case!).  Unfortunately, after all that work, I'm getting the same 0xc1800118 error when pushing Feature Updates via the 2016 server (in WindowsUpdate.log on client, getting "Requested file <featureupdatefile>.esd has no decrypt information".  There's already a .esd MIME Type entry in IIS with type 'application/vnd.ms-cab-compressed' (different from the required 'application/octet-stream' entry in Server 2012 R2, but it's there out-of-the-box in Server 2016).

    Running the initial query on the SUSDB WID database (see above link) shows that the database is still in a bad state - returning 52 entries that are encrypted, but without a decryption key.

    Does anyone know how to fix this issue of pushing Windows 10 Feature Updates via WSUS on Windows 2016?

    Many thanks,


    Monday, January 28, 2019 5:00 PM

All replies

  • https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-3-windows-as-a-service-waas-and-group-policy-administrative-templates/

    Use my guide to help you. You DO need to adjust the .esd to use the application/octet-stream in many cases (why it's defaulted to vnd.ms-cab-compressed - not sure, but others have said changing the mimetype works).

    Also, the link you gave above regarding 'bad state' or what I like to call a Dirty Database, is out of date and Microsoft changed the way they did things for the better, and your database will always appear to be 'in a bad state' now. It's not because it is - it's because of what Microsoft changed in 1703 with how they distribute the update.

    Adam Marshall, MCSE: Security
    Microsoft MVP - Windows and Devices for IT

    Tuesday, January 29, 2019 4:38 AM
  • Hi TT1999,

    If the method given by Microsoft does not help you, I found a solution that is different from the link you provided. 
    The specific steps are as follows:

    • 1. Detect whether WSUS is in a bad state. To do this, run the following query on your SUSDB:
          A bad state is indicated by “TotalResults > 0”.
    select TotalResults = Count(*)
    from tbFile
    where (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like '%15063%.esd' and IsEncrypted = 0)


    • 2. If you are using Windows Internal Database (WID) for your SUSDB instaed of SQL database, you need to install SQL Server Management Tools on your WSUS server and connect using following Server Name:


    • 3. If WSUS is in a bad state, do the following steps in the listed order:
          Disable Upgrades classification on local WSUS server (run in PowerShell)
    Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable


    • 4. Delete all update content on the current server belonging to the 1607 release (run in PowerShell)
    $s = Get-WsusServer
    $1607Updates = $s.SearchUpdates(“version 1607”)
    $1607Updates | foreach { $_.Decline() }
    $1607Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }


    • 5. Enable Upgrades classification (run in PowerShell)
    Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification


    • 6. Delete files from tbFile table (run on WSUS database)
    declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);
    insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%15063%.esd'  except select FileDigest from tbFileForRevision);
    delete from tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles)
    delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)


    • 7. Perform full synchronization of WSUS (run in PowerShell)
    $sub = $s.GetSubscription()


    • 8. If the Clients are still failing to pull the update and returning a 0xc1800118 error, follow these steps on every client: (run in CMD)
    net stop bits
    net stop wuauserv
    rd /s /q %windir%\SoftwareDistribution
    net start bits
    net start wuauserv


    • 9. Try updating client computer again. 
    This is a consistent approach to the solution proposed by Microsoft. 
    Links to articles about this method: 

    Reply back with the results would be happy to help.

    Yic Lv

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, January 29, 2019 7:28 AM
  • Hi Yic Lv, and many thanks for your response.

    Running the initial query from your link on the SUSDB database gives a TotalResults figure of 0 (zero).

    As such, I suspect the database is not in a bad state (certainly with regards to Feature Update version 1703, build no 15063).

    Thanks again, and let me know if you have any other ideas.

    Kind regards,


    Tuesday, January 29, 2019 10:19 AM
  • Hi Adam, and thanks v. much for your feedback.

    I've changed the .esd MIME type to application/octet-stream, restarted the 2016 WSUS server, and cleared contents of the %windir%\SoftwareDistribution\DataStore folder on my test Windows 10 machine (stopping wuauserv beforehand, and starting again afterwards).

    However, I still get the following error when manually triggering the Feature Update on the test Windows 10 machine (currently version 1607):

    Feature update to Windows 10 Enterprise, version 1703, en-us x64 - Error 0xc1800118

    WindowsUpdate.log shows the following error:

    Requested file 15063.0.170710-1358.rs2_release_svc_refresh_CLIENTENTERPRISE_VOL_x64fre_en-us.esd has no decrypt information

    Do you have any other ideas as to why this isn't working?

    Many thanks,


    Tuesday, January 29, 2019 10:29 AM
  • Is 1607 RTM or what patch level? (14393.10 or 14393.2759 or something in between?)

    Adam Marshall, MCSE: Security
    Microsoft MVP - Windows and Devices for IT

    Wednesday, January 30, 2019 1:51 AM
  • Thanks Adam. The test machine is build 14393.2724.
    Wednesday, January 30, 2019 9:31 AM
  • ok, so there goes that theory.

    For testing, can it go to 1709 and not 1703? Approve the 1709 and decline the 1703 feature update and see if it works. Clear the SoftwareDistribution folder before checking for updates after you confirm that the 1709 has been fully downloaded.

    Adam Marshall, MCSE: Security
    Microsoft MVP - Windows and Devices for IT

    Wednesday, January 30, 2019 8:14 PM
  • Thanks again Adam.  The 1709 feature update worked fine.

    Is it OK to jump from 1607 to 1709, or am I likely to have problems?

    Wednesday, February 13, 2019 1:56 PM
  • You can go from any Win10 Version to Any future version and you shouldn't have issues. I would suggest going to the latest 1809.

    Adam Marshall, MCSE: Security
    Microsoft MVP - Windows and Devices for IT

    Wednesday, February 13, 2019 2:05 PM