locked
Windows 10 Update Fails RRS feed

  • Question

  • SCCM 2012

    We are in the process of updating Windows 7 Enterprise to Windows 10 Enterprise.  I have one machine that is failing the task sequence.  It downloads the files and starts the installation, and then fails.  In the SMSTS.LOG file I see the following entry:

        

    Windows Setup failed with hexadecimal exit code 0xC1900204 (decimal 3247440388). To identify the type of issue, lookup it against the table of known values of Windows Setup errors online.

    I can't find a table of known values of Windows Setup errors, but my research would seem to imply that the machine in question does not meet the minimum system requirements, which I don't believe is actually correct.  I think the machine does meet the minimum requirements.  At the recommendation of my technical lead, I also checked these logs:

         AppDiscovery.log
         AppIntentEval.log
         AppEnforce.log
         PolicyAgent.log
         DCMAgent.log
         CIAgent.log

    None of them show errors referring to the Windows 10 update.  I also ran System File Checker to verify that all the Windows 7 system files are good, and there were no problems detected.  Is there some place else that I should be looking?

    Thanks for any help that you can offer!

    --Tom


    • Edited by thomasm516 Thursday, March 1, 2018 11:30 PM Fixed a typo.
    Thursday, March 1, 2018 11:28 PM

Answers

  • I think we actually have this one resolved.  According to Microsoft, OEMs (Dell, in this case) can embed product keys in the BIOS.  They do this when a machine ships with Windows installed.  So I did a chat with Dell to get more information and this is what the Dell tech indicated:

    "So your question is pertaining to a upgrade from 7 to 10, systems that were not purchased with 10  and downgraded to 7 do not have the Windows 10 product key in the bios and therefore they are correct, it will not update since it does not see a 10 product key."

    A little later in the chat he indicated:

    "So this system was shipped with 7 installed and a 10 license, you can not upgrade and use the 10 license that is imbedded. it is a full license not an upgrade license."

    Not sure his reason for being unable to upgrade is 100% accurate (Seems like a full license should be upgradable), but at least it confirms that there was an embedded key that, for whatever reason, was causing issues.

    There are tools out there that can reveal the OEM product key.  I used some of these in my troubleshooting, but did not fully appreciate the meaning of what the information was telling me at the time.  No endorsements here, but I used OEMKey, RWEverything, ShowKeyPlus, and a PowerShell command that can be found at: https://www.zdnet.com/article/windows-10-tip-find-your-pcs-original-product-key/

    There is also a DOS command that works and is found at:

    https://www.thewindowsclub.com/find-windows-product-key

    VAMT version 2, which you can download from Microsoft, is also useful: https://www.microsoft.com/en-us/download/details.aspx?id=11936

    Microsoft gave us a solution.  In the task sequence, just after the step that disables Bitlocker, we added an OSD Key task.  That task contains a task sequence variable called OSDSetupAdditionalUpgradeOptions, which is set to /pkey NPPR9-FWDCX-D2C8J-H872K-2YT43 (That key was posted here by another individual and also appears on a public Microsoft page, so I don't think there's any harm is showing it here).

    That appears to have resolved the issue.

    Thanks to all who contributed to this discussion.  My understanding of this topic has certainly grown, and I hope that by sharing the solution others will be benefited.

    --Tom

    • Marked as answer by thomasm516 Thursday, July 12, 2018 8:14 PM
    Thursday, July 12, 2018 8:13 PM

All replies

  • First, ConfigMgr 2012 does not support Windows 10; you need to upgrade to ConfigMgr Current Branch.

    For reference on the Windows setup upgrade based error codes, see https://blogs.technet.microsoft.com/mniehaus/2015/08/23/windows-10-pre-upgrade-validation-using-setup-exe/.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Proposed as answer by TorstenMMVP Friday, March 2, 2018 7:34 AM
    Friday, March 2, 2018 1:47 AM
  • Our site admin must have already upgrade to ConfigMgr Current Branch because our Windows 10 upgrades have been working.  I can't ask him because he just left for another job.

    I read that blog post when I first started troubleshooting and in particular I noticed the third bullet point, which is the exact error message I am seeing.  I'm not real adept at tracking down deployment errors yet, and so I have been focusing on digging in to the logs and forgot about the ScanOnly option that the blog post mentions.  I will give that a try.

    --Tom

    Friday, March 2, 2018 3:14 PM
  • Working doesn't mean supported.

    Are you using an upgrade task sequence that has an actual Upgrade Operating System task in it?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, March 2, 2018 3:16 PM
  • Yes.  Here is a screen shot.  I've watched the files download and I don't see any problems with that step, and the logs show that the files all downloaded successfully, and then the task sequence disables BitLocker, so it is getting that far.  It then starts the upgrade but does not finish.  It fails after only a minute or so.

    We are just in our testing phase so have only done a handful of machines.  Just this morning we discovered another machine that is exhibiting the same behavior.  Both machines are Dell OptiPlex 7040s.  The deployment has worked on ac couple of Surface Pro 3 machines, a few OptiPlex 990s, and OptiPlex 9040s, so maybe something with our deployment does not play well with OptiPlex 7040s.

    Here is a bit more of the SMSTS log.  I'm trying to post only the relevant entries, but I'm something of an SCCM newbie, so I may not always know what is relevant.  I can certainly post more if needed.  I have bolded one entry that seems relevant as it implies to me that our upgrade package is good to go.

    Details for image : C:\_SMSTaskSequence\Packages\RV20002B\sources\install.wim
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Index : 3
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Name : Windows 10 Enterprise
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Description : Windows 10 Enterprise
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Size : 16,022,009,955 bytes
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Architecture : x64
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Hal : <undefined>
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Version : 10.0.16299
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    ServicePack Build : 15
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    ServicePack Level : 0
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Edition : Enterprise
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Installation : Client
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    ProductType : WinNT
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    ProductSuite : Terminal Server
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    System Root : WINDOWS
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Directories : 21480
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Files : 107942
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Created : 9/29/2017 - 7:55:22 AM
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Modified : 12/13/2017 - 7:32:07 PM
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Languages :
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
     en-US (Default)
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    The operation completed successfully.
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    The operation completed successfully.
     OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Validating  package for OS upgrade architecture OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Architecture of OS upgrade package is x64 OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Architecture of current OS is x64 OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Architecture of current OS matches architecture of new OS upgrade package. Can continue OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Validating  package for OS upgrade version OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    The version of source OS upgrade package '10.0.16299' is supported to be used in OS upgrade. We can continue OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    No timeout set for Windows Upgrade Setup OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Command line of Windows Setup upgrade: '"C:\_SMSTaskSequence\Packages\RV20002B\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable /compat IgnoreWarning ' OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Command line for extension .EXE is "%1" %* OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Set command line: "C:\_SMSTaskSequence\Packages\RV20002B\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable /compat IgnoreWarning OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Executing command line: "C:\_SMSTaskSequence\Packages\RV20002B\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable /compat IgnoreWarning OSDUpgradeWindows 2/28/2018 2:36:59 PM 9376 (0x24A0)
    Process completed with exit code 3247440388 OSDUpgradeWindows 2/28/2018 2:37:48 PM 9376 (0x24A0)
    Windows Setup completed with exit code hexadecimal 0xC1900204 (decimal 3247440388)  OSDUpgradeWindows 2/28/2018 2:37:48 PM 9376 (0x24A0)
    Saving exit code of Windows upgrade - hexadecimal 0xC1900204 (decimal 3247440388) -  to Task sequence environment variable '_SMSTSOSUpgradeActionReturnCode', as decimal string OSDUpgradeWindows 2/28/2018 2:37:48 PM 9376 (0x24A0)
    Windows Setup failed with hexadecimal exit code 0xC1900204 (decimal 3247440388). To identify the type of issue, lookup it against the table of known values of Windows Setup errors online. OSDUpgradeWindows 2/28/2018 2:37:48 PM 9376 (0x24A0)
    Failing this task sequence step OSDUpgradeWindows 2/28/2018 2:37:48 PM 9376 (0x24A0)

    Thanks for the help on this.  It is greatly appreciated!

    --Tom


    • Edited by thomasm516 Friday, March 2, 2018 7:47 PM Inserted picture of task sequence
    Friday, March 2, 2018 7:42 PM
  • Sorry, not following. The error code above, 0xC1900204 clearly shows an issue with Windows Setup specifically and not ConfigMgr so a ConfigMgr log file isn't going to add any value here. 

    From Michael's blog that error code means "Migration choice (auto upgrade) not available (probably the wrong SKU or architecture)". IOW, whatever you are trying to upgrade from or to is invalid.

    Do the architectures match? 


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, March 2, 2018 7:55 PM
  • I posted that section of the SMSTS log because you had asked if the task sequence was using an actual Upgrade Operating System task.  I wanted to show that it is, and that things were at least getting started.

    I have some new information that has lead me to the same conclusion as you (I wasn't quite there this morning, but I am now).  Working from information in Michael's blog, I copied the installation files from the source folder to the local machine and ran this command:

         start /Wait SETUP.EXE /Auto Upgrade /Quiet /NoReboot /DynamicUpdate Disable /Compat ScanOnly

    The result was -1047526904, which the blog indicates translates into a hex value of C1900208, indicating a hard block resulting from a compatibility issue.  So, clearly there is something going on with that machine that we don't understand yet.

    To answer your question regarding if the architectures match, the OS on the machine is 64-bit Windows 7 Enterprise, and we are upgrading to 64-bit Windows 10 Enterprise.  I have not had time to dig in to it beyond that, but will attempt to dig deeper on Monday.

    One final thing, Michael's blog also mentions the SETUPACT.LOG and SETUPERR.LOG files generated by SETUP.EXE.  I found those in C:\Windows.  The SETUPACT log just has 3 lines indicating that it is launching the command I issued from the command prompt, and the SETUPERR log is empty.

    --Tom


    • Edited by thomasm516 Friday, March 2, 2018 11:45 PM Corrected typo
    Friday, March 2, 2018 11:44 PM
  • We found different SETUPACT.LOG and SETUPERR.LOG files that we had previously missed.  They were located in the C:\$WINDOWS.~BT\Sources\Panther folder.  Based on the contents of those logs I think this is clearly not an SCCM issue, but perhaps someone here has run across this problem and can offer some advice.

    It appears to us like there is a problem with the Windows product key that is on our Windows 7 machines.  Here is what we found in the SetupAct.log file:

    2018-03-02 15:43:12, Info                  MOUPG  ProductKey: Product key found in Host OS.

    2018-03-02 15:43:12, Info                  MOUPG  ProductKey: Populating Image info set.

    2018-03-02 15:43:16, Info                         SPValidateProductKey: Calling PidGenX

    2018-03-02 15:43:17, Error                        CallPidGenX: PidGenX function failed on this product key. (hr = 0x8a010101)

    2018-03-02 15:43:17, Warning                      SPValidateProductKey: Failed to call PidGenX to validate product key

    2018-03-02 15:43:17, Error                 MOUPG  CDlpActionProductKeyValidate::ReportDownlevelInstallChannel(2948): Result = 0x8A010101

    2018-03-02 15:43:17, Error                 MOUPG  ProductKey: Failed to report Host OS channel to telemetry.


    We were able to find the following article that deals with a very similar issue:


    http://www.asquaredozen.com/2018/01/16/windows-7-windows-10-fall-creators-update-1709-place-upgrade-fails-error-0xc1900204-invalid-sku/


    Our new technical lead suggested the following steps to try changing the product key on the machine we are testing with.


    1.Run CMD as administrator
    2.Register new code slmgr.vbs -ipk <New Product Key>
    3.To activate windows after changing the key, type: slmgr.vbs -ato
    4.Reboot and run upgrade again


    The commands completed successfully, but the upgrade still failed when we tried it again.

    It feels like we are on the right track.  We're just not sure how to resolve the issue.  Any advice would be appreciated.

    --Tom

    • Edited by thomasm516 Wednesday, March 7, 2018 11:33 PM Formatting for ease of reading
    Wednesday, March 7, 2018 11:29 PM
  • What product are you using and why aren't you using a KMS?

    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, March 7, 2018 11:55 PM
  • Windows 7 Enterprise.

    We would love to be using a KMS, but I work in an organization where IT operations have been placed in some pretty entrenched silos, and the decision on whether or not to use a KMS is entirely out of our hands.  Admittedly, I am not very familiar with KMS, but based on some brief reading, it seems to rely on DNS, and in my organization DNS is controlled by another agency, so that is out of our hands as well.

    The Windows 7 image was built before I was hired, and the person who built it no longer works here, so I can't really comment on why things are the way they are, I just know this is the situation the organization has landed itself in.  My goal is to resolve the current issue as best I can, and then try to improve our systems and processes moving forward.

    --Tom

    Thursday, March 8, 2018 2:10 PM
  • Sorry, I meant "what product key"? Specifically, which type of key for what SKU of Windows are you specifying in the deployment task sequence (or unattend.xml file) and what type of key for type of Windows SKU was used to activate the Win 7 instance (you should be able to use slmgr.vbs or VAMT to determine this)?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Thursday, March 8, 2018 5:11 PM
  • If you haven't already, try deleting the $WINDOWS.~BT folder before running the upgrade again.

    https://ccmcache.wordpress.com/ | @kevmjohnston

    Thursday, March 8, 2018 5:14 PM
  • Sorry for the delayed reply.  I'm having to balance this with all the other day-to-day things that come up.  I'll dig into that and get back to you as soon as I can.

    --Tom

    Monday, March 12, 2018 8:40 PM
  • Kevin,

    Thanks for chiming in.  I will give that a try and let you know.

    --Tom

    Monday, March 12, 2018 8:41 PM
  • Kevin,

    I gave that a try and the installation failed with the same errors.

    --Tom

    Monday, March 12, 2018 10:25 PM
  • Jason,

    It appears that I was incorrect when I stated that we are not using a KMS.  I ran the slmgr.vbs command and there is a KMS server listed.  I am still learning our environment and that was news to me.  My apologies for that inaccuracy.  The server is owned by another agency so I am not sure that we have any access to that server, but I will try to find out.  I my organization, some of our stuff is hosted by another agency and we may or may not have access, and we host some things on our own servers.

    I only had a few minutes to research so no answer yet to your questions concerning the product keys and SKUs, but I will keep working on it.

    Thanks for the help that you have provided thus far!

    --Tom

    Monday, March 12, 2018 10:32 PM
  • Jason,

    The client machine is running 64-bit Windows 7 Enterprise, and according to VAMT the product key type is GVLK. I have not been able to confirm through SCCM what the deployment is using for the key type and Windows SKU. However, I used VAMT on a laptop that did successfully upgrade to Windows 10, and that machine shows 64-bit Windows 10 Enterprise with a key type of GVLK. So, here is what I believe is the case:

         Client              64-bit     Windows 7 Enterprise       GVLK

         Deployment     64-bit     Windows 10 Enterprise     GVLK

    I'm pretty solid on the client information, but not as solid on the deployment simply because I have not been able to verify it directly in the deployment (Or an unattend.xml file).  In the task sequence, the upgrade operating system step shows a Product Key field that is blank.  I assume this means that it might be in an unattend.xml file as you suggested, but I have not been able to find that file.

    Am I looking at the right place in the task sequence, and where might I find an unattend.xml file?

    --Tom


    • Edited by thomasm516 Monday, March 19, 2018 5:03 PM Added additional information
    Monday, March 19, 2018 4:56 PM
  • The use of the GVLK is good.

    If you can't find an unattend.xml, you may not be supplying one (which is fine).

    You may need to open a support case here. There are a handful of hits when searching the web including http://eddiejackson.net/wp/?p=15898 but not confident those will help or not.

    Media mismatch is my only remaining thought here. I've also seen in some of the web hits that another version of Win 10 may work. What version of Win 10 are you trying to upgrade to?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, March 19, 2018 6:43 PM
  • Here's what the task sequence shows:

    --Tom

    Monday, March 19, 2018 9:49 PM
  • I've had to put this on the back burner for a few days, and I am out of the office all next week, but we are still working on this issue.  I will post more information as we move forward on our troubleshooting.

    --Tom

    Friday, March 30, 2018 4:46 AM
  • Hi, I had this problem and resolved it by adding the Product Key from Microsoft into the 'Upgrade Operating System' task underneath where I selected the edition of Windows 10.
    Product key can be found here: https://docs.microsoft.com/en-us/windows-server/get-started/kmsclientkeys

    I used the one for Windows 10 Enterprise, NPPR9-FWDCX-D2C8J-H872K-2YT43, and once built I ensured it then syncs back to our internal KMS for the correct license.

    Hope this helps,
    Jack

    Thursday, May 31, 2018 10:50 AM
  • Jack,

    Thanks for the response.  It is interesting that this issue has affected only our OptiPlex 7040s.  It occurred to me that I had a laptop that was a successful in-place upgrade to Windows 10, so I ran VAMT on that machine and found the license key ends with 2YT43.  I have been thinking that changing to that product key and then running the in-place upgrade might resolve the issue, but until now I did not know where to find the rest of the product key.  Thanks for posting that link!

    For those who have followed this thread, my apologies for not providing an update for a while, but until recently there was nothing new to report.  Last week a Microsoft Config Manager technician was here. We asked him to look at this issue, and he was initially stumped, but after working through the logs with level 3 support, came to the same conclusion that we had reached--there is a problem with the product key. Unfortunately, he had to leave for the airport before a solution could be identified, and just recommended that we open a ticket with Microsoft. Our technical lead would handle that, so I don't know if a ticket has been opened yet, but I don't think so. I will recommend that we try the key that Jack posted and go from there.

    I will continue to post updates when there is new information to report.  Thanks to all who have contributed to the discussion!

    --Tom

    Tuesday, June 5, 2018 4:23 PM
  • It has been quite some time since I posted an update.  We are still having issues, but have made some progress.  The issue seems to be limited to machines that were imaged and deployed in a certain year, so we are thinking there was some kind of issue with that image.  We have also recently upgraded our Config Manager, and since that upgrade we have had limited success updating some machines by removing the Config Manager client and reinstalling it.  There may also be a correlation with network ports that have port security enabled.  While this has not yet been proven, it is true that all in-place upgrades of machines connected to imaging ports (No port security) have been successful, whereas the majority of machines connected to ports with security enabled have failed the update.

    Our technical lead finally opened a ticket to Microsoft and he is on the phone with them as I type this.  I will continue to post updates as more information becomes available.

    --Tom

    Tuesday, July 10, 2018 7:48 PM
  • I think we actually have this one resolved.  According to Microsoft, OEMs (Dell, in this case) can embed product keys in the BIOS.  They do this when a machine ships with Windows installed.  So I did a chat with Dell to get more information and this is what the Dell tech indicated:

    "So your question is pertaining to a upgrade from 7 to 10, systems that were not purchased with 10  and downgraded to 7 do not have the Windows 10 product key in the bios and therefore they are correct, it will not update since it does not see a 10 product key."

    A little later in the chat he indicated:

    "So this system was shipped with 7 installed and a 10 license, you can not upgrade and use the 10 license that is imbedded. it is a full license not an upgrade license."

    Not sure his reason for being unable to upgrade is 100% accurate (Seems like a full license should be upgradable), but at least it confirms that there was an embedded key that, for whatever reason, was causing issues.

    There are tools out there that can reveal the OEM product key.  I used some of these in my troubleshooting, but did not fully appreciate the meaning of what the information was telling me at the time.  No endorsements here, but I used OEMKey, RWEverything, ShowKeyPlus, and a PowerShell command that can be found at: https://www.zdnet.com/article/windows-10-tip-find-your-pcs-original-product-key/

    There is also a DOS command that works and is found at:

    https://www.thewindowsclub.com/find-windows-product-key

    VAMT version 2, which you can download from Microsoft, is also useful: https://www.microsoft.com/en-us/download/details.aspx?id=11936

    Microsoft gave us a solution.  In the task sequence, just after the step that disables Bitlocker, we added an OSD Key task.  That task contains a task sequence variable called OSDSetupAdditionalUpgradeOptions, which is set to /pkey NPPR9-FWDCX-D2C8J-H872K-2YT43 (That key was posted here by another individual and also appears on a public Microsoft page, so I don't think there's any harm is showing it here).

    That appears to have resolved the issue.

    Thanks to all who contributed to this discussion.  My understanding of this topic has certainly grown, and I hope that by sharing the solution others will be benefited.

    --Tom

    • Marked as answer by thomasm516 Thursday, July 12, 2018 8:14 PM
    Thursday, July 12, 2018 8:13 PM
  • Hey mate, thanks for this answer. It's pretty much what i was looking for. I am experiencing the same issues with the Optiplex 7040 which arrived with Windows 7 on them and failing to upgrade to Windows 10 Enterprise.

    I have tried the OSDSetupAdditionalUpgradeOptions TS variable, but it fails on the smsts.log with this error.

    Command line of Windows Setup upgrade: '"C:\_SMSTaskSequence\Packages\sitecode001BE\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /installdrivers "C:\_SMSTaskSequence\Drivers" /DynamicUpdate Disable /compat IgnoreWarning  /pkey NPPR9-FWDCX-D2C8J-H872K-2YT43'	OSDUpgradeWindows	30/09/2018 12:11:08 PM	3544 (0x0DD8)
    Command line for extension .EXE is "%1" %*	OSDUpgradeWindows	30/09/2018 12:11:08 PM	3544 (0x0DD8)
    Set command line: "C:\_SMSTaskSequence\Packages\sitecode001BE\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /installdrivers "C:\_SMSTaskSequence\Drivers" /DynamicUpdate Disable /compat IgnoreWarning /pkey NPPR9-FWDCX-D2C8J-H872K-2YT43	OSDUpgradeWindows	30/09/2018 12:11:08 PM	3544 (0x0DD8)
    Executing command line: "C:\_SMSTaskSequence\Packages\sitecode001BE\SETUP.EXE" /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe "C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback "C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd" /installdrivers "C:\_SMSTaskSequence\Drivers" /DynamicUpdate Disable /compat IgnoreWarning /pkey NPPR9-FWDCX-D2C8J-H872K-2YT43	OSDUpgradeWindows	30/09/2018 12:11:08 PM	3544 (0x0DD8)
    Process completed with exit code 3247440135	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Windows Setup completed with exit code hexadecimal 0xC1900107 (decimal 3247440135) 	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Saving exit code of Windows upgrade - hexadecimal 0xC1900107 (decimal 3247440135) -  to Task sequence environment variable '_SMSTSOSUpgradeActionReturnCode', as decimal string	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Windows Setup failed with hexadecimal exit code 0xC1900107 (decimal 3247440135). To identify the type of issue, lookup it against the table of known values of Windows Setup errors online.	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Failing this task sequence step	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Enabling TSManager service	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    smstsmgr service startup type is set to automatic	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Enabling CCMExec service	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    CcmExec service startup type is set to automatic	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Setting the client out of provisioning mode	OSDUpgradeWindows	30/09/2018 12:11:28 PM	3544 (0x0DD8)
    Exiting SetClientProvisioningMode 0x00000000	OSDUpgradeWindows	30/09/2018 12:11:36 PM	3544 (0x0DD8)
    upgrade.Run(), HRESULT=80004005 (upgradewindows.cpp,1445)	OSDUpgradeWindows	30/09/2018 12:11:36 PM	3544 (0x0DD8)
    Exiting with code 0x80004005	OSDUpgradeWindows	30/09/2018 12:11:36 PM	3544 (0x0DD8)
    Process completed with exit code 2147500037	TSManager	30/09/2018 12:11:36 PM	4732 (0x127C)
    !--------------------------------------------------------------------------------------------!	TSManager	30/09/2018 12:11:36 PM	4732 (0x127C)
    Failed to run the action: Upgrade Operating System. 
    Unspecified error (Error: 80004005; Source: Windows)	TSManager	30/09/2018 12:11:36 PM	4732 (0x127C)
    Set authenticator in transport	TSManager	30/09/2018 12:11:36 PM	4732 (0x127C)
    Set a global environment variable _SMSTSLastActionRetCode=-2147467259	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Set a global environment variable _SMSTSLastActionSucceeded=false	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Clear local default environment	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Let the parent group (Upgrade the Operating System) decides whether to continue execution	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Let the parent group (Pre-Upgrade Check) decide whether to continue execution	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    The execution of the group (Pre-Upgrade Check) has failed and the execution has been aborted. An action failed.
    Operation aborted (Error: 80004004; Source: Windows)	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Failed to run the last action: Upgrade Operating System. Execution of task sequence failed.
    Unspecified error (Error: 80004005; Source: Windows)	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Set authenticator in transport	TSManager	30/09/2018 12:11:41 PM	4732 (0x127C)
    Task Sequence Engine failed! Code: enExecutionFail	TSManager	30/09/2018 12:26:58 PM	4732 (0x127C)
    ****************************************************************************	TSManager	30/09/2018 12:26:58 PM	4732 (0x127C)
    Task sequence execution failed with error code 80004005	TSManager	30/09/2018 12:26:58 PM	4732 (0x127C)
    

    I have also tried without the TS variable specified above and used the product key tab in the TS, also failed.

    Am I missing something?

    Thanks

    Mahmoud

    Sunday, September 30, 2018 3:27 AM