locked
Windows 10 1703 Deployment RRS feed

  • Question

  • Hi All

    I have a very strange issue, I have SCCM 1702 and I'm trying to install Fresh Windows 10 1703, I'm using the default Install.wim coming with the ISO File.

    the Task sequence only to deploy the OS , the good thing that the SCCM Complete the task sequence but when I go the machine i found that it can't load the OS and it's giving me a blue screen say the following:

    Why Did my PC restart?

    there's a problem that's keeping us from getting your PC ready to use, but we think an update will help get things working again.

    I tried many image even I captured a new one with same , tried the deployment on even a Hyper-V VM also same.

    any advise.


    Ahmed Ali

    Tuesday, May 2, 2017 9:40 AM

Answers

  • the Issue has been Fixed , it was due to some restriction from the Group Policy.

    Ahmed Ali

    • Marked as answer by x Ahmed Ali Wednesday, May 3, 2017 5:39 AM
    Wednesday, May 3, 2017 5:39 AM

All replies

  • Which error Code is displayed on the bluescreen? Any chance that (storage) drivers are missing?

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

    Tuesday, May 2, 2017 11:01 AM
  • Which error Code is displayed on the bluescreen? Any chance that (storage) drivers are missing?

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

    Tuesday, May 2, 2017 11:02 AM
  • The Problem that there is no error Code :) by I noticed something if I removed Joining the Domain Process and make it join Workgroup , the WIndows start normally.

    Ahmed Ali

    Tuesday, May 2, 2017 11:08 AM
  • the Issue has been Fixed , it was due to some restriction from the Group Policy.

    Ahmed Ali

    • Marked as answer by x Ahmed Ali Wednesday, May 3, 2017 5:39 AM
    Wednesday, May 3, 2017 5:39 AM
  • I'm getting this issue as well, what was the restriction in Group Policy?!
    Wednesday, May 3, 2017 6:57 AM
  • I'm having the same issue here. SCCM 1702 and Windows 10 x64 Enterprise 1703 downloaded from Microsoft Volume License website. It's happening with all our hardware models. 
    Thursday, May 4, 2017 6:19 AM
  • Morning Anderson,

    I found that I had the 'Block launching Windows Store apps with Windows Runtime API access from hosted content' enabled in Group Policy. Set it to 'Not Configured' and got it working.

    Hopefully this answer is a bit more helpful to everyone...

    • Proposed as answer by Dalgon Wednesday, January 31, 2018 4:10 PM
    Thursday, May 4, 2017 6:41 AM
  • Hi, Ahmed,

    May I know which Group Policy has restricted it?

    How did you figure that out?

    Thanks,

    hellofly


    Thursday, May 4, 2017 8:19 AM
  • I believe that this error is occurring because the OOBE was essentially rebuilt for v1703; more aspects of it were moved beneath the aegis of the Cloud Experience Host, and the WinJS code that defines the process isn't fully accounting for all previous deployment scenarios.

    This is not a BSOD or anything like that; you should be able to reach an NT AUTHORITY\System command prompt by using the Shift+F10 keyboard combination, although this may depend in part on any policies or image customizations in effect.

    I did a short write-up on my own experience with this error in my comment to my own Reddit thread, with an attached error log entry that seems to precipitate this event. If you check Administrative Events in the event viewer logs (eventvwr.msc @ the command prompt), I suspect you will find an AppHost termination event for the Cloud Experience Host as well, though the stack trace may be different.

    EDIT:

    I think I have tracked my circumstance: as part of a default scripted configuration for VM build-outs, I insert a custom UsrClass.dat registry hive into the Default User Profile before specializing. This hive presets an "IconStreams" value to define icons that are initially shown or hidden in the Notification Area, allowing me to hide the volume icon -- which will have an error badge over a non-"Enhanced Session" connection in the absence of virtual audio hardware -- by default, while affording users the greatest freedom to "find" it or make it visible using interfaces available to non-administrators.

    In recent versions of Windows, the Cloud Experience Host -- which does the user OOBE -- runs under the context of a temporary user, defaultuser0, and a profile is created for this user under C:\Users for this process using normal User Profile Service methods -- which include copying an existing UsrClass.dat file, if present.

    In at least one-third of deployments using Windows 10 v1703, a chain of events will occur when this UsrClass.dat file is present that causes the Cloud Experience Host to choke. Among the things still to be tested is whether this choke is specific to presence of the iconstreams value, or will occur with any UsrClass.dat file placed at that location.

    Thursday, May 4, 2017 5:33 PM
  • Thank you for that!
    What fixed the issue for me was to block all computer Group Polices applied to the Windows 10 machines. I couldn't identify which one was causing the issue though. The funny thing is that the GPOs worked for Windows 10 1607.
    Monday, May 15, 2017 2:39 AM
  • Why Did my PC restart?

    there's a problem that's keeping us from getting your PC ready to use, but we think an update will help get things working again.

    This follows a pattern of design by Microsoft when something inside Windows goes wrong.  You understand from the message that what you wanted to happen didn't.  You don't know what to do about it other than press the Next button and hope for the best.  In this case I tried to load Windows 10 1703 into Hyper-V on Windows 2016 and entered an endless loop back to this message.  

    The solution for me, such as it was, load an older, more stable Windows revision into Hyper-V.  Worked like a champ.

    I'm a veteran of the software wars dating back to the 1970s.  I remember the day when diagnostic messages contained real, actionable information.  Today's messages essentially say "No.  And I won't tell you why or what to do."


    MARK D ROCKMAN

    Sunday, February 4, 2018 9:06 PM
  • I had that problem with a 1709 task sequence on a random basis (MDT TS, 1709 image with 12_2017 patches, SCCM 1710) Although the TS completed successfully, the machine hung in a loop. A relatively easy workaround is to set this reg value:
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE]
    "SkipMachineOOBE"=dword:00000001
    If you enable and start the Remote Registry service and connect by regedit, you can do this manually. Probably also with psexec. Since both is tiresome, I created a little vbscript that is now running at the end of the task sequence. 

    '---------------------------------------------------------------------------
    Dim strKey
    Dim dwValue, nRet

    strKey = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE\SkipMachineOOBE"
    dwValue = 1
    nRet = WriteReg(strKey, dwValue, "REG_DWORD")

    Function WriteReg(strRegPath, dwValue, strRegType)
     
          Dim objRegistry
          Set objRegistry = CreateObject("Wscript.shell")

          nRet = objRegistry.RegWrite(strRegPath, dwValue, strRegType)
          WriteReg = nRet
    End Function
    '---------------------------------------------------------------------------

    In case you see the same problem, copy the code lines to a file called OOBE.vbs, put it in a SCCM package and add a call c:\windows\sysnative\cscript.exe OOBE.vbs (mind that you have to use sysnative when using a 64 bit OS). Finally, insert it into your TS.

    Additional remarks: You may be tempted to add a line <SkipMachineOOBE>true</SkipMachineOOBE> to your unattend.xml. Be aware that there's a statement that this is not recommended (https://msdn.microsoft.com/de-de/library/dn915853(v=vs.85).aspx). I tried before I found this and it didn't even work (the TS was hanging). I also didn't have success with inserting a reboot into full OS between the steps Apply Operating System and Apply Network Settings but this seems to work for others.


    Tuesday, March 13, 2018 10:59 PM
  • Update: The issue was obviously fixed with one of the recent cumulative updates for 1709. So just make sure that a software update step is included in the task sequence and that the update group is assigned to the same collection.
    Wednesday, March 21, 2018 8:46 PM