Windows 7 to Windows 10 Fall Creators Update (1709) In-Place Upgrade Fails with error 0xC1900204 (Invalid Sku)

We have built an SCCM In-Place upgrade task sequence to migrate our enterprise from Windows 7 Enterprise to Windows 10 Enterprise. We have been using the same basic TS for over a year without issues.  With the release of Windows 10 Fall Creators Update (1709), we began having issues upgrading certain devices and were seeing error code 0xC1900204, indicating Invalid SKU.

Windows setup looks at the existing OS, install media and the command line image number to validate that the existing and desired versions are a match and can be upgraded. The new multi-version install media that came with Windows 10 Fall Creators requires more steps (behind the scenes) to make the match and seems to have issues with some systems. I’m not sure how relevant this is, but we are using KMS keys for all of our devices.

Let’s take a look at the setupact.log from a failed client to see some snippets of these steps.

Here we can see the command line that is dynamically generated from the Upgrade Operating System step in your TS (See image at the bottom of this post).

The existing OS is Windows 7 Enterprise.

Here, the installer loops through the image indexes to find the one that matches the index specified in the setup command line.

Finally, we get to the part where we can see the issue.

After digging through this for a bit, I learned some things that I didn’t know. The PidGenX and Digital Marker lines are where I found the root of the problem. I honestly could not find any real useful information about PidGenX, but I believe that it’s a product ID checking utility. For some reason it fails. As I mentioned before, we are using a KMS key, so it’s possible that it has issues communicating to my KMS server, but I’m just not sure.
The Digital Marker on the other hand refers to the OEM SLP in the MSDM ACPI table in UEFI, or the System Locked Preinstallation (SLP) key in the Microsoft Digital Marker (MSDM) in the Advanced Configuration and Power Interface (ACPI) table embedded in the Unified Extensive Firmware Interface (UEFI).

Once I started looking in the right place, I was able to find the Digital Marker on my devices using a tool called RWEvertything with the assistance of this post. I confirmed that my machines all had OEM Professional SLP keys instead of Enterprise (also, it said it on the sticker on the outside of the machine!!).

From there, I contacted Microsoft Premier Support and they suggested adding the KMS key to the Product key field in my TS using the correct KMS key from Microsoft here.

Once I added the KMS key in, the upgrades started working again. While the workaround fixed the issue, I’m just not sure if this is a bug, underlying issue with my environment or just Gremlins. It would be great to know someday.

You Might Also Like


  • Reply
    John Parry
    January 25, 2018 at 5:50 am

    I am having this exact same issue

    • Reply
      Adam Gross
      January 25, 2018 at 6:33 am

      Please try the solution of adding the Microsoft default KMS key that matches your intended version of Windows 10 to your Task Sequence or your Setup command line. I’d love to know how it works out. Feel free to reach out through the site or find me on Twitter @AdamGrossTX if you need help.

      • Reply
        John Parry
        February 5, 2018 at 9:53 am

        that fixed it, many thanks

        • Reply
          Adam Gross
          February 5, 2018 at 10:05 am

          Thanks for the feedback. Glad it worked!

  • Reply
    Aharon L Robinson
    February 22, 2018 at 7:28 pm

    Worked for us as well. Thanks so much!

  • Reply
    Austin WongCarter
    April 20, 2018 at 12:11 pm

    Thanks, This is exactly the problem we are having, trying it now.

  • Reply
    May 31, 2018 at 4:22 am

    Thank you! This worked a treat on the HP G3s we have!

  • Reply
    Thomas McFadden
    June 27, 2018 at 8:15 am

    OMG! I have been searching for this fix for two days! I just could not understand why my upgrade was trying to install Pro rather than Enterprise. Many thanks for this information as it appears to have fixed the 0xC1900204 error for my deployment!

    • Reply
      Russ F-J
      October 5, 2018 at 10:44 am

      Same thing here. Once I added the “generic” key for Win 10 Enterprise to the Upgrade OS step, it got past the PidGenX function error. I’ve reached out to MS to understand why this work-around is necessary as it feels like a bug with the function.

  • Reply
    August 27, 2018 at 9:11 am

    Experiencing same errors on a few Dell machines, upgrades are going well otherwise. How would we replicate this in MDT, because UI for this step is pretty generic and only points to a WIM? I’m guessing the Unattend.xml, but I’m unsure exactly which node to modify. Thanks!

  • Comment

    This site uses Akismet to reduce spam. Learn how your comment data is processed.

    %d bloggers like this: