none
Windows 10 - Wrong OS Version for captured image

    Question

  • Hi there experts

    Today i noticed some strange Information in the ConfigMgr Console. I've got a Build and Capture Task-Sequence, which creates a Reference Image for Windows 10 Enterprise x64.

    When i Import the generated WIM File into ConfigMgr the following OS Version is shown in the Operating System Images Node.

    From my Point of view the Version should be something like "10.0..." and not "6.2..." which would be Windows 8???

    Deployment works without any problems, just noticed this. Anyone around seen the same issue?

    Environment: ConfigMgr 2012 R2 SP1 CU1


    Best regards, Simon



    Thursday, August 13, 2015 12:04 PM

Answers

All replies

  • Hi,

    Interesting I am seeing the correct version, did you install the Windows ADK? Are there more indexes in the .Wim file imported?

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Thursday, August 13, 2015 12:31 PM
  • ADK for Windows 10 ist installed on all Site Servers including the Boot Images with Version: 10.0.10240.16384.

    There is only 1 Index in the WIM.


    Best regards, Simon

    Thursday, August 13, 2015 12:56 PM
  • I am seeing the exact same issue but have not determined the cause as of yet.

    Thursday, September 3, 2015 7:51 PM
  • I am also seeing this issue.  It is a problem for the offline servicing of the image: the system presents only Windows 8 updates.

    The "Build and Capture" of "Windows 10 Pro" using a Windows 8.1 based PXE and task sequence boot image (ADK 8.1) gives the correct OS version.  When I retried this with a Windows 10 based PXE and task sequence boot image (ADK 10), I got the same wrong OS Version.  So it's probably an ADK 10 issue.


    • Edited by en001 Monday, September 7, 2015 8:54 AM New Build&Capture test with ADK10 based boot image
    Friday, September 4, 2015 12:58 PM
  • having the same problem, any resolution?

    observation - When I import the extracted ISO to the Software Library > Operating Systems > Operating System Upgrade Packages it shows version 10 but when I captured it then it shows version 6.2

    • Edited by jamicon Monday, October 5, 2015 12:59 PM
    Monday, October 5, 2015 12:51 PM
  • We are also getting this exact same issue.

    Our Windows 7 and Windows 8.1 Captures are both OK, it is only the Windows 10 Capture image being identified as OS 6.2.10240.16384

    This is a new build of SCCM 2012 R2 SP 1.

    Is there an update/hotfix for this anywhere?

    If I find a solution I'll reply to update...

    Tuesday, October 6, 2015 3:14 PM
  • We are having the same problem here.  OS version is reporting 6.2.10240.16384 even though we are using Win10.  Still haven't found a fix for this yet.  If I do I'll post it here.
    Friday, October 9, 2015 11:35 AM
  • I am also seeing this issue.  It is a problem for the offline servicing of the image: the system presents only Windows 8 updates.



    There's a hot fix for the Offline Updates : https://support.microsoft.com/en-us/kb/3089193

    Benoit Lecours | Blog: System Center Dudes

    Friday, October 9, 2015 12:54 PM
  • As said here this issue has nothing to do with the linked hotfix.

    Here we have the Problem that either Configuration Manager thinks that the Windows 10 Image is a Windows 8 Image or the Windows 10 Image presents itself as a Windows 8 Image (Syprep / Capture related issue).

    The result is that Configuration Manager provides Windows 8 Updates when performing Offline Image Servicing:


    Simon Dettling | msitproblog.com | @SimonDettling


    Friday, October 9, 2015 1:03 PM
  • As said here this has nothing to do with the linked hotfix. Here we have the Problem that Configuration Manager thinks that the Windows 10 Image is a Windows 8 Image and so provides Windows 8 Updates.

    Simon Dettling | msitproblog.com | @SimonDettling

    Correct but en001 was also mentionning Offline update in his reply.

    Benoit Lecours | Blog: System Center Dudes

    Friday, October 9, 2015 1:11 PM
  • Has anyone already opened a call @Microsoft?

    We are running into the same issue at two customers.

    Wednesday, October 14, 2015 6:33 AM
  • I don't know if anyone opened a call, but I know that the product group is aware of that behavior.

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, October 14, 2015 6:49 AM
  • Thanks for your fast response. So, the issue is still addressed and we will hope for a solution.

    I found another article, that the issue only exists during caputre of SCCM, not in MDT
    https://keithga.wordpress.com/2015/08/27/mdt-uberbug10-win10-os-capture-using-sccm-is-not-supported/

    This document shows, that this situation exists, if the sysprep is running in system context. If you run sysprep in users context, everything works fine

    Wednesday, October 14, 2015 7:20 AM
  • I got some feedback from a collegue that MS has a internal post about the issue
    They are talking about, that the problem is already fixed in a future build of SCCM.

    At the moment, it is not clear if this build is a vNext build or an SCCM 2012 CU/SP

    For my customer it is necessary to fix it in 2012 for a W10 Rollout. So, if it will not fixed in 2012, I will open a ticket to request a hotfix.

    I will give you some information, if a solution is available

    Wednesday, October 21, 2015 7:09 AM
  • Thanks for the Feedback!

    Simon Dettling | msitproblog.com | @SimonDettling

    Wednesday, October 21, 2015 7:11 AM
  • any update on this?
    Tuesday, November 3, 2015 2:12 PM
  • Some small informations are available.

    The issue is fixed in next SCCM Version. It is possible, that the fix is also available in the coming CU for SCCM 2012, but not sure. We are waiting for the CU to check the hotfixes inside. If the issue is not fixed there, we are further thinking to open a MS call.

    Sorry, but there is still no solution available

    Tuesday, November 3, 2015 4:06 PM
  • According to the release notes of the newly released CU2, this should be fixed :)

    https://support.microsoft.com/en-us/kb/3100144


    Simon Dettling | msitproblog.com | @SimonDettling


    Tuesday, November 10, 2015 6:22 PM
  • Nope, not solved.

    I upgraded to CU2 and problem still exists.

    Thursday, November 12, 2015 1:44 PM
  • Have you updated your Bootimages you are using inside your capture TaskSequence?
    Monday, November 16, 2015 3:09 PM
  • Not sure what the boot images and TS have to do with scheduled updates on the Windows 10 image but I'm all ears :-)

    Yes, here is the version I'm using in my TS:

    Thanks for your reply

    Wednesday, November 18, 2015 1:13 PM
  • The bootimages themselves are most likely irrelevant, but updating them (=update DPs) after installing CU2 ensures that the latest (=CU2) is injected and that makes a difference.

    Torsten Meringer | http://www.mssccmfaq.de


    Wednesday, November 18, 2015 1:32 PM
  • ok, thanks. I should have thought about that :-)

    I'll do it tonight and get back to you ok.

    Thanks again!

    Wednesday, November 18, 2015 3:31 PM
  • I had the same issue. I found I had to delete and re-capture all my images to fix the issue. (after applying CU2)
    • Edited by bcehr Thursday, November 19, 2015 3:17 PM
    Wednesday, November 18, 2015 11:26 PM
  • I'm thinking that you are right, what a pain in the butt!

    I updated all the DP's like Torsten aid but that didn't make any difference.

    I'm happy with my image so I'll just add the software updates in the TS instead of this tool.

    What a bummer!

    Thursday, November 19, 2015 12:42 PM
  • The Problem here seems to be in the Capture Process. To really solve this you need to Create a new Reference-Image using Build and Capture with the updated Boot Image, after CU2 applied, as bcehr confirmed.

    Simon Dettling | msitproblog.com | @SimonDettling

    Thursday, November 19, 2015 1:00 PM
  • Yes I think we can all agree on that however isn't this what CU's are for... This is MS screw up, they should fix it.

    Thursday, November 19, 2015 4:27 PM
  • Yes I think we can all agree on that however isn't this what CU's are for... This is MS screw up, they should fix it.


    Please read my post above or the post from bcehr. You need to recapture your Image!

    Simon Dettling | msitproblog.com | @SimonDettling

    Friday, November 20, 2015 2:22 PM
  • I tested it by in my environment where the initial issue exists, too.

    After applying the CU2, Updating my boot images, build&capture a new image, integrate the new one in the console, the version is correct and updates also can be served offline by the gui.
    So, the problem is fixed for me and the CU does what it should do

    • Proposed as answer by MDeffner Monday, November 30, 2015 9:19 AM
    Wednesday, November 25, 2015 9:01 AM
  • For me the CU2 works perfectly and the Version issue is fixed also in our environment.
    Thursday, November 26, 2015 2:02 PM
  • I second the solution: after CU2, update Win10 Boot Image on the DPs, rerun B&C (of course if not using PXE, update your boot media too after the boot image update): problem gone.

    Btw. The information is there in the CU2 article... we really should read more carefully the release notes (including myself :-) ).


    • Edited by cgsilver Friday, November 27, 2015 1:21 PM format
    Friday, November 27, 2015 1:21 PM
  • waited for release 1511 to capture new image, getting ...4005 error when running sysprep.

    done a hundred of these but no go with Win 10 capture.

    Tuesday, January 5, 2016 4:40 PM
  • This happened to me when using 1511 capture media. Not sure what is going on here.
    Monday, February 8, 2016 1:35 PM