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

14 Comments

  • 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
    Jack
    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
    GovGeek
    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!

  • Reply
    Martin
    November 29, 2018 at 3:56 pm

    Hello, I’ve been struggling with this problem for several days – my goal was to upgrade W7 Enterprise to W10 1709 Enterprise directly via WSUS – no SCCM available. It looks like that upgrade installer is having troubles to get the correct product key / edition on some machines (my testing Dell was failing as well). If the installer won’t get info what edition should install (as the upgrade for 1709 contains several editions), it will fail with 0xC1900204.

    Part of setupact.log in failing scenario :

    2018-11-29 22:20:11, Info MOUPG ProductKey: Failed to extract key from Host OS. hr=[0x80070002]

    2018-11-29 22:20:12, Info MOUPG GetProductKeyFromResponse: Attempting to get a product key from the response layer.
    2018-11-29 22:20:12, Info MOUPG GetProductKeyFromResponse: Using automation response.
    2018-11-29 22:20:12, Info MOUPG GetProductKeyFromResponse: Automation response not found.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Looking for product key in Pid.txt file.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Pid.txt file not found.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Looking for product key in Host OS.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Failed to extract key from Host OS. hr=[0x80070002]
    2018-11-29 22:20:12, Info MOUPG ProductKey: Looking for product key in Digital Marker.
    2018-11-29 22:20:12, Info MOUPG ProductKey: No digital marker key found. hr=[0xc004f057]
    2018-11-29 22:20:12, Info MOUPG ProductKey: Looking for EICfg file.
    2018-11-29 22:20:12, Info MOUPG ProductKey: EI.cfg file found.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Validating EI.cfg file.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Extracting data from EI.cfg file.
    2018-11-29 22:20:12, Info MOUPG ProductKey: EI.cfg file did not contain an edition Id.
    2018-11-29 22:20:12, Info MOUPG ProductKey: EI.cfg file contained an install channel.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Matching Install Wim For Exact Editions
    2018-11-29 22:20:12, Info MOUPG ProductKey: Matching Install Wim.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Matching Install Wim: No edition provided, matching all images.
    2018-11-29 22:20:12, Info MOUPG ProductKey: Populating Image info set.
    2018-11-29 22:20:12, Info SPGetWIMImageInfo: No software hive in WIM image index 1; assuming this is data image.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Matching Install Wim: Found [6] matching images.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Valid product key found = [TRUE].
    2018-11-29 22:21:01, Info MOUPG ProductKey: SelectImageIndex: Found multiple matching images. Querying for image index.
    2018-11-29 22:21:01, Info MOUPG ProductKey: SelectImageIndex: Selecting image index from response.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Getting index from response.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Image selection response not found.
    2018-11-29 22:21:01, Info MOUPG ProductKey: SelectImageIndex: Image index not found in response. Selecting image index from SkuLib.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Getting index from SkuLib.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Host OS edition is [Enterprise].
    2018-11-29 22:21:01, Info MOUPG ProductKey: No SkuLib Upgrade edition available.
    2018-11-29 22:21:01, Info MOUPG ProductKey: Matching upgrade edition not found in SkuLib.
    2018-11-29 22:21:01, Error MOUPG CDlpActionProductKeyValidate::SelectImageIndex(1636): Result = 0xC1900215
    2018-11-29 22:21:01, Error MOUPG CDlpActionProductKeyValidate::ExecuteRoutinePkeyValidate(435): Result = 0xC1900215
    2018-11-29 22:21:01, Error MOUPG CDlpActionProductKeyValidate::ExecuteRoutine(376): Result = 0xC1900215

    As I don’t have SCCM, I had to cheat a little and “mimic” the SCCM logic – once the Windows Update started with upgrade installation, I’ve quickly copied prepared pid.txt with generic KMS install key for W10 Enterprise to the C:\$WINDOWS.~BT\Sources folder. That did the trick :

    2018-11-29 22:27:10, Info MOUPG GetProductKeyFromResponse: Attempting to get a product key from the response layer.
    2018-11-29 22:27:10, Info MOUPG GetProductKeyFromResponse: Using automation response.
    2018-11-29 22:27:10, Info MOUPG GetProductKeyFromResponse: Automation response not found.
    2018-11-29 22:27:10, Info MOUPG ProductKey: Looking for product key in Pid.txt file.
    2018-11-29 22:27:10, Info MOUPG ProductKey: Product key found in Pid.txt file.
    2018-11-29 22:27:10, Info MOUPG ProductKey: Validating Product Key for Image.
    2018-11-29 22:27:10, Info MOUPG ProductKey: Populating Image info set.
    2018-11-29 22:27:10, Info SPGetWIMImageInfo: No software hive in WIM image index 1; assuming this is data image.
    2018-11-29 22:28:08, Info SPValidateProductKey: Calling PidGenX
    2018-11-29 22:28:09, Info MOUPG ProductKey: Product key using pkey edition = [Enterprise].
    2018-11-29 22:28:09, Info MOUPG ProductKey: Matching Install Wim For Exact Editions
    2018-11-29 22:28:09, Info MOUPG ProductKey: Matching Install Wim.
    2018-11-29 22:28:09, Info MOUPG ProductKey: Matching Install Wim: Found [1] matching images.
    2018-11-29 22:28:09, Info MOUPG ProductKey: Extracting Eula
    2018-11-29 22:28:14, Info MOUPG ProductKey: Product key was successfully validated.
    2018-11-29 22:28:14, Info MOUPG ProductKey: Product EditionID = Enterprise
    2018-11-29 22:28:14, Info MOUPG ProductKey: Product InstallChannel = Volume
    2018-11-29 22:28:14, Info MOUPG ProductKey: Eula = C:\$WINDOWS.~BT\Sources\Panther_s_3DC4.tmp
    2018-11-29 22:28:14, Info MOUPG ProductKey: Valid product key found = [TRUE].
    2018-11-29 22:28:14, Info MOUPG ProductKey: SelectImageIndex: Only one image found. Selecting default.

    I know it’s far from perfect and definitely not usable in larger environments, but hopefully it can save time for other affected guys without SCCM at their hands.

    Last but not least – thank you Adam for this article, it was really helpful.

  • Reply
    ARTHUR BUCIONE
    February 7, 2019 at 12:22 pm

    Same issue with 1803 upgrade in place. I will try your solution and see if it works! Thank you!

  • Reply
    TRon
    February 18, 2019 at 10:30 am

    Well, that helped a lot. I had been having the same issue, and had narrowed it down to the OS Index list causing the problem, but hadn’t thought to try using the KMS key. Put in the key and everything worked first time. Successfully upgraded Win7.64 to Win10.64-b1809.

  • Comment

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

    4,463