Partager via

Steps to resolve error 0xc1800118

  • Article

(Alternative title: "Help, I followed the steps provided earlier and I'm still seeing failures!"

This applies to anyone who missed KB 3159706 when it was offered as a hotfix to Windows Server 2012/R2, and who subsequently enabled synching of Upgrades in their environment before patching WSUS.  The Upgrades that were likely downloaded most recently happen to be for the Windows 10 1607 feature update, but the steps referenced could be modified to suit a different set of content.)

In this scenario, WSUS has downloaded content that it cannot use.  Because parsing only happens once, and WSUS does not know what “Upgrades” are without having installed KB 3159706, it incorrectly identifies the upgrade as a quality update and saves it to the SUSDB (and managed clients) as such.  This will cause any future deployment of this content to fail until the patch is applied, unusable content is purged, and WSUS properly syncs the information.

If the symptom seems familiar, it is because the guidance for KB3095113 addresses a similar class of issue.  The steps detailed in that post are sufficient for repairing a WSUS that has downloaded unencrypted feature updates, but encrypted content involves a few more steps in order to fully clean your WSUS and its affected clients.  For information on why Upgrades are now being encrypted, please refer to our earlier blog post.

Full coverage of error 0xc1800118 (and how to clean your environment after downloading unsupported encrypted Upgrades to WSUS) can be found in KB 3194588, which was created to help address these failures in the wild.  Feel free to share questions and feedback for that KB by using the comments section for this post.  Finally, several folks shared some PowerShell advice in the comments section for the post regarding KB3095113: you may find it worthwhile to review that if the steps published do not quite fit your needs.

Comments

  • Anonymous
    September 21, 2016
    Hi,Based on Article KB 3159706, there is some weird stuff about the SubDB SQL commandsdeclare @NotNeededFiles table (FileDigest binary(20) UNIQUE); insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%14393%.esd' except select FileDigest from tbFileForRevision);deletefrom tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles)delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)That deletefrom is obvious but I mean query part(select FileDigest from tbFile where FileName like '%14393%.esd' except select FileDigest from tbFileForRevision);The whole query result 0 rows affected If there is that "except select FileDigest from tbFileForRevision" part includedWhat I am missing or doing wrong?
    • Anonymous
      September 21, 2016
      Nevermind.I have to use also$s = Get-WsusServer$1607Updates = $s.SearchUpdates(“versio 1607”)$1607Updates | foreach { $.Decline() }$1607Updates | foreach { $s.DeleteUpdate($.Id.UpdateId) }Because finnish :)
      • Anonymous
        September 22, 2016
        Great point, Poison Dwarf: the search query that we specify is in English, so you'll need to translate to whatever language your WSUS is configured to use. Thanks for sharing!
      • Anonymous
        September 23, 2016
        In my Case, i had to use:$s = Get-WsusServer$1607Updates = $s.SearchUpdates(“version [Release]”)$1607Updates | foreach { $.Decline() }$1607Updates | foreach { $s.DeleteUpdate($.Id.UpdateId) }There were 372 Updates with this Name inside.In my Case, the German Version does not show the name correctlyThe Updates were named like this, when i opened the SCCM Mangement Console (German):Funktionsupdate für Windows 10 Enterprise, Version [Release], [Sprachencode]After enable Upgrades classification, I deleted the files in the Database with:declare @NotNeededFiles table (FileDigest binary(20) UNIQUE); insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%14393%.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)I checked the Database with step 1 -> Total Result is 0The Upgrade to 1607 is now working :)
        • Anonymous
          September 26, 2016
          Great news, Oliver. We're also updating the KB with a note that the guidance is for English OS installations, to help prevent confusion from this.
      • Anonymous
        April 06, 2017
        The comment has been removed
        • Anonymous
          May 05, 2017
          You have a typo in your SearchUpdates query: "versio" should be "version". Did you enter it this way into PowerShell, as well?
    • Anonymous
      October 03, 2016
      I have the same problem as Poison Dwarf.This query (select FileDigest from tbFile where FileName like '%14393%.esd' except select FileDigest from tbFileForRevision) result is 0 rows affected.But if i run query: select TotalResults = Count(*)from tbFilewhere (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like '%14393%.esd' and IsEncrypted = 0)Result is: TotalResults 48.What is wrong?
      • Anonymous
        October 28, 2016
        Have you managed to resolve the issue. Our environment has the exact same issue and the SQL Query does not delete the entries.But if i run query:select TotalResults = Count(*)from tbFilewhere (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like ‘%14393%.esd’ and IsEncrypted = 0)Result is: TotalResults 32Then after following KB3194588 the entries are still present.
        • Anonymous
          May 05, 2017
          The query does not delete the entries. It only detects whether you have feature updates (Upgrades) that have been synched without the needed decryption keys. Once identified, those rows must be manually deleted from the SQL or WID database. Simply deleting them via PowerShell will not remove the decryption key information, and thus will not resolve the issue.
  • Anonymous
    September 22, 2016
    The sql codes in https://support.microsoft.com/en-us/kb/3194588 is not correct, it's possible have it ?
    • Anonymous
      September 22, 2016
      We did have a typo in the first draft (changes should go live later today): "deletefrom" should be "delete from". Did you notice any other errors?Also, some formatting oddities showed up on some browsers after the initial publish; we're working those out, as well.
      • Anonymous
        September 26, 2016
        declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);+ declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);+ ~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (FileDigest:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException
        • Anonymous
          September 26, 2016
          Okay, i figured it out, its not powershell, its sql. :)
  • Anonymous
    September 23, 2016
    YES, finally. This has solved my issues with WSUS and SCCM 2012 1606 deploying the anniversary update.
    • Anonymous
      September 26, 2016
      Glad we could help, Jon!
  • Anonymous
    September 23, 2016
    Just for fun, I ran the query in KB3194588. The results are below:Changed database context to 'SUSDB'.TotalResults------------ 0Next, I did this --> del %windir%\SoftwareDistribution\DataStore*on the client PC, after stopping the service.The PC's download other updates like defender updates and cumulative updates to 1511. When trying to download the feature update to 1607, it just sets at 0% downloading. Any help with this issue would be appreciated.Thanks.
    • Anonymous
      September 26, 2016
      Please post this in our TechNet forum to get assistance from the community as well as our support staff. Without seeing your client logs, I couldn't tell you exactly what's going on here.
  • Anonymous
    September 25, 2016
    How do I run this script on 2012R2 if I don't have SQL management studio..?
    • Anonymous
      September 26, 2016
      There is a free version of SQL Management Studio (Express) that you can use. With that said, we acknowledge this is a painful workaround; better solutions are coming, but we wanted to get this guidance out there for the DIY crowd.
  • Anonymous
    September 26, 2016
    Out of curiosity: Why do we need to delete the datastore to get this working?
    • Anonymous
      September 26, 2016
      The client will not update the metadata for any files it has already downloaded. Both it and WSUS have long assumed that metadata never changed, so this was no issue. What's different now is that an unpatched WSUS will essentially save different metadata (and so will the client). After patching, the metadata will remain the same, so the problem persists. You have to purge the incomplete files after enabling the scenario in order to repair it.
      • Anonymous
        September 26, 2016
        Hello,I make a big error, I deleted from tbFile all FileName like ‘%14393%.esd’ without exclude FileDigest from tbFileForRevision.Now all clients do not see Windows 10 1607 update anymore.I try a wsusutil /reset, I also reapprove 1607 update... WSUS redownload the file but select * from tbFile where FileName like ‘%14393%.esd’ return 0 records.How can I solve this?Thanks
      • Anonymous
        September 27, 2016
        Finally I solved the problem.Using the powershell command (change "version" with my localization) now WSUS redownload 1607 update:$s = Get-WsusServer$1607Updates = $s.SearchUpdates(“versione 1607”)$1607Updates | foreach { $.Decline() }$1607Updates | foreach { $s.DeleteUpdate($.Id.UpdateId) }Thanks for this best post!
  • Anonymous
    October 03, 2016
    Thank you, Support guys, for updating https://support.microsoft.com/en-us/kb/3194588Do you think, is this workaround ready for worldwide deployment, or should we wait some more time?Thank You, Amarok
    • Anonymous
      October 07, 2016
      The comment has been removed
      • Anonymous
        December 13, 2016
        Any news about upcoming hotfix? We realy don`t want to install SSMS on our WSUS (also DC) server. Thank you.
  • Anonymous
    October 03, 2016
    The comment has been removed
    • Anonymous
      October 07, 2016
      The comment has been removed
      • Anonymous
        November 04, 2016
        Steve - I have no clue how to access the local database to find out if it is in a bad state or not... Are we still looking at the global fix coming out around Thanksgiving?
        • Anonymous
          November 04, 2016
          So if we did this correctly, my TotalResults show 496. So is this considered "bad" and I need to move on to other steps?
        • Anonymous
          May 05, 2017
          Sadly, we ran into shipping complications that I'll detail in a separate blog post, and we were unable to get this convenience fix out last year. Most of the administrators were able to self-repair by downloading SQL Management Studio (free software) and connecting to the SUSDB that way. For those that are still in pain, we're looking at ways to repair this without requiring you to get your hands in the database.
      • Anonymous
        November 10, 2016
        I think you are using an internal database with your WSUS. I have the exact same problem.Where can we found the workaround for an internal WSUS Datatbase?
      • Anonymous
        January 05, 2017
        The comment has been removed
      • Anonymous
        March 06, 2017
        Was there ever a less painful, post-Thanksgiving solution / workaround offered?
  • Anonymous
    October 04, 2016
    The query to detect if WSUS is in a bad state on KB3194588 returns 0 for me so it is in a good state yet still seeing 0xc1800118 on clients in UpdateHandler.log. I have tried to delete %windir%\SoftwareDistribution\DataStore* incase a previous bad download or something might have been the cause I also cleared %windir%\ccmcache and it seemed to work however I am not getting 0xc190012f in the WUAHandler.log after rebooting. No idea what this error is, not much info on the web about it other than people experiencing it.
    • Anonymous
      October 07, 2016
      Please post this in the TechNet forum so that it can be properly discussed. If your WSUS is not in a bad state, then all that remains is to make sure your client is healthy. Sounds like there might be one more step to getting that particular result.
  • Anonymous
    October 04, 2016
    The comment has been removed
    • Anonymous
      October 07, 2016
      The issue is that you've synched content to WSUS before installing KB3159706 (and following the manual steps). Patching the client is fine, and your suggestion is a good one, but it alone cannot prevent this error.
  • Anonymous
    October 06, 2016
    Hi, We have encountered this issue and can verify that deleting the datastore contents on a client machine fixes the issue (and the upgrade proceeds without error). But can you verify what other action is recommended on the server? The WSUS database is not in a bad state.We don't want to have to delete the datastore contents on every machine. Thanks
    • Anonymous
      October 07, 2016
      If your WSUS is not in a bad state, then you need delete nothing. Getting upgrades to proceed without error is the goal: if you're there, then you're done.
      • Anonymous
        October 09, 2016
        Thanks Steve, so the answer is "we need to delete the %windir%\SoftwareDistribution\DataStore*" on every machine before proceeding? Manual intervention is required for every upgrade?
        • Anonymous
          October 13, 2016
          Luke,I hope your results are different but deleting the data store on the PC make no difference for me.
          • Anonymous
            October 13, 2016
            Same here. I have verified my WSUS database is in a good state. I can successfully update my workstations to 1607 ONLY IF I REIMAGE THEM! I have 200 or so workstations that have Win10 on them already and I still keep getting the error. I even deleted the DataStore as outlined in the KB article. Still nothing. Only way I can get it to work is by reimaging them to our Win10 RTM image.
  • Anonymous
    October 11, 2016
    Hello,id like to report sth not directly connected to blog entry, however its a bit annoying:WSUS keeps reporting my AU systems with version .187, even tho tehy are already quite higher (in this case, .321).any hints on whats going on? is it common problem or i can solve it somehow?http://i.imgur.com/t2DwhUq.png
    • Anonymous
      May 05, 2017
      This is actually a bug in the WSUS console that does not update the revision number when a new update is installed. Major, Minor, and Build versions will always be correct, but Revision might not be.
  • Anonymous
    November 28, 2016
    Any timeline/updates on the availability of an easier fix for this, rather than having to connect to the Windows Internal DB?
  • Anonymous
    December 07, 2016
    Hi,I ran a query as below and total result = 0.select TotalResults = Count(*)from tbFilewhere (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like ‘%14393%.esd’ and IsEncrypted = 0)I have already performed the manual steps as described on article KB 3159706 but no luck. Windows 10 machines fail to upgrade. WSUS errror report:- (Unable to Find Resource:) ReportingEvent.Client.181; Parameters: Feature update to Windows 10 Pro, version 1607, en-us, Retail- Installation Failure: Windows failed to install the following update with error 0x8024200d: Feature update to Windows 10 Pro, version 1607, en-us, Retail- Installation Failure: Windows failed to install the following update with error 0xc1800118: Feature update to Windows 10 Pro, version 1607, en-us, RetailI have also deleted del %windir%\SoftwareDistribution\DataStore* and resync udpates from WSUS but no luck.Is there something that I am missing?
    • Anonymous
      May 05, 2017
      A result = 0 suggests that you do not have the problem described in this post, but your symptoms suggest otherwise. Did you end up figuring this out?
  • Anonymous
    January 02, 2017
    Since this is the last update in WSUS blog and since then Microsoft rolled out new update model for Windows 7/8.1 and nobody on other related blogs cannot answer my question I'm writing it here. Hopefully Steve will be able to answer them.The new update model for Windows 7 says, that every update from now on will be cumulative. So, if every update is cumulate and I approve them in WSUS every month, does this mean that from now on WSUS server needs a lot more disk space?
    • Anonymous
      May 05, 2017
      The WSUS server storage requirements will certainly increase as a result of the cumulative packaging across all platforms. However, it also means that you can safely decline previous cumulative updates (and then clean them up) after approving newer ones, and you won't be missing any needed content.
  • Anonymous
    January 10, 2017
    @Steve Henry [MSFT]Are there any updates to this process? I noticed you mentioned a better method without using SQL Management Studio would have been out around Thanksgiving, but it's January and I'm having a hard time finding it.
    • Anonymous
      May 05, 2017
      Sorry, Todd: this easier way has not been released yet, for reasons that I'll share in a separate blog post. Are you still having trouble getting this to work?
  • Anonymous
    February 07, 2017
    So, there are numerous individual threads about patching WSUS to fix this or that. And this thread just "ends" in October with a promise of a new patch by Thanksgiving 2016 but I don't see a new post about that ever being published?What we need as administrators is a start to finish guide on setting up WSUS on Server 2012 R2 and which patches in which order to load to get it to work successfully with Windows 10 and Server 2016. A similar guide for setting up a 2016 WSUS server would also be nice. I know there are guides out there for setting up WSUS but I can't find one that references the patches needed.Aside from that, why is it so hard to patch a server that is designed to patch our client devices? WSUS should be easier to patch, Period.Sorry for the Rant and Thanks!
    • Anonymous
      May 05, 2017
      Thanks for the suggestion, Steve. Agreed that it would be nice if WSUS were easier to patch; the reason it used to be so simple is that we'd package a new version as a full release, and the product was rarely serviced through Windows updates. Given our new reality and the lessons learned from 2016, we're being extra careful about making additional changes to WSUS.The next update that we ship to WSUS will be cumulative, and will therefore include all the fixes you need. Going forward, it will be much easier to ensure that you're properly patched.
  • Anonymous
    February 17, 2017
    Since I have apply this KB, my Wsus Version is 6.3.9600.18324 but my Wsus Console on my computer (via RSAT) is still 6.3.9600.17477. So I can't do local publishing with Wsus Package Publisher. How can I upgrade my Wsus Console on my computer ?Thanks.
    • Anonymous
      May 05, 2017
      The fix is on the server itself, not in RSAT. As long as you've patched your actual WSUS server, your RSAT operations against it should work fine. Can you describe the local publishing issue in more detail?
  • Anonymous
    April 06, 2017
    Can someone please suggestion on this timeout expired related error.
  • Anonymous
    April 13, 2017
    Hello,Here we go again, after fighting with the 1607 update, same error comes back with the 1703 update in WSUS :2017-04-13 09:53:04, Error MOUPG RecoverCrypto: File is encrypted, but no key was provided.2017-04-13 09:53:04, Error MOUPG CDlpActionRecoverCrypto::DoCrypto(1713): Result = 0xC1800118What to do now ?Thanks.
    • Anonymous
      May 05, 2017
      The comment has been removed
  • Anonymous
    April 18, 2017
    Wondering if the update promised by the author in November was ever released? If so, what is the KB #? Thanks.
    • Anonymous
      May 05, 2017
      The update has not been released yet, but we'll be sure to post the information when it has.
  • Anonymous
    May 09, 2017
    The comment has been removed
    • Anonymous
      May 10, 2017
      The comment has been removed
      • Anonymous
        May 11, 2017
        Thanks for your reply.I've already gone through the painfull process of declining several thousand language packages. Is there a good tutorial on how to properly deploy a new WSUS without declining thousands of language packages? I only need German, English and French. Our infrastructure is pretty heterogeneous so we get updates for a lot of products.ThanksMatt
        • Anonymous
          May 11, 2017
          The comment has been removed
  • Anonymous
    May 19, 2017
    My WSUS reports it is version 6.39600.18228 running on Windows Server 2012 R2. I believe I have I have gone through all the recommended steps to make the decryption piece work including the manual steps. I've queried the database and come up with a "0" when checking for Upgrades that might be downloaded but not registered properly. That includes 1607 and 1703 releases. What I have experienced is that clients with the 1511 build are properly recognizing the 1607 feature upgrade as "needed" (which is approved) and the 1703 feature upgrade as "needed" (which is not approved). As soon as 1607 is installed the clients don't appear to get their updates including cumulative updates from WSUS and 1703 isn't "needed" any longer. They are showing up as being 100% patched. Cumulative updates do install but appear to come from another source (Windows Update?). I changed Group Policy last night to allow CB (was CBB) distribution yesterday and this morning I installed on my workstation. What am I missing preventing WSUS from recognizing the clients need the cumulative updates and 1703? Distribution Optimization is set for BYPASS which I've seen recommended.Is this behavior a result of the WSUS server patch problems over the last year or so or Group Policy?
    • Anonymous
      May 24, 2017
      You might want to read this blog post on Dual Scan to get a better understanding of why your client might be ignoring search results from WSUS after upgrading to 1607. If you follow the workaround mentioned in that post, then you should see your applicability detection return to normal.
  • Anonymous
    May 30, 2017
    The comment has been removed
    • Anonymous
      May 31, 2017
      Yes, WSUS 3.0 (including SP1 and SP2) cannot manage encrypted content. Please deselect the Upgrades classification, and do not expect to successfully sync or deploy this content using that version of WSUS.
  • Anonymous
    June 08, 2017
    The comment has been removed
    • Anonymous
      June 12, 2017
      Your WSUS server does not understand these new columns, which suggests a mismatch between your schema and your database. Please review the post on KB3159706 and follow the manual steps to which it links.
  • Anonymous
    June 27, 2017
    Hi Steve, could you clear something up for me please? in the kb3194588 blog a 'bad state' is indicated by a "TotalResult = 0" is that true? after running the SQL query what should a good result be.. (greater than 0)?? even running through this blog some seem to be taking a "0" result as good.. - many thanks
    • Anonymous
      July 13, 2017
      The logic is a bit confusing. Might be helpful to restate it as "TotalResult = 0" means that you have not successfully identified the updates that are causing issues in your environment. If you're hitting 0xc1800118, then it is surely because of feature updates, and if the SQL query is unable to locate the offending updates, then that is a "bad" result. It might mean that you need to tweak the query--different languages describe the updates differently, for example--to ensure that you successfully locate the update to be deleted from the SUSDB.
  • Anonymous
    July 25, 2017
    I have had this issue also. I have followed the procedure in kb 3194588 to correct it, first with the top WSUS and then with the downstream WSUS. The downstream WSUS is not receiving the DecryptionKey (still NULL). I've repeated the procedure several times on the downstream server.
    • Anonymous
      August 07, 2017
      I have manage to resolve the issue but I saw an ugly side effect. The issue is from the below:$s = Get-WsusServer$1703Updates = $s.SearchUpdates(“version 1703”)$1703Updates | foreach { $.Decline() }$1703Updates | foreach { $s.DeleteUpdate($.Id.UpdateId) }The above will also expire the most recent cumulative update! And the KB article does not seem to be available anymore...
  • Anonymous
    August 24, 2017
    The comment has been removed