none
MDT Build 8443 - Win 10 v1703 Fails at Install Operating System RRS feed

  • Question

  • I have used a Deployment Share for 8 years, going through the many MDT iterations and versions.  But no matter how I use this Deployment Share with Windows 10 I get a failure.  My ADK is 10 v1703 the MDT Build is 8443 and every time the image process fails at the end of "Install Operating System".  From the failed VM I'm trying to image/capture image I can open a command prompt and ping the server perfectly fine.  So it's not networking, it's just something else.

    There is no BDD.LOG and the 1 SMSTS.LOG found at "c:\users\administrator\appdata\local\temp\smstslog" only useful information is what I have below.

    Anybody with ideas on why my Windows 7 images all work for all Task Sequences and the Windows 10 images all fail for all Task Sequences?  I even built another pristine Deployment Share, built the Windows 10 image, used the WIM and imported it into my everyday working MDT 2013 and that Windows 10 image still can't be used.

    Failure Details ...

    FAILURE (5627): -2146498514 0x800F082E: Run DISM.exe
    LiteTouch deployment failed, Return Code = -2147467259 0x80004005
    Failed to run the action: Install Operating System.
    Unknown error (Error: 000015FB; Source: Unknown)
    The execution of the group (install) has failed and the execution has been aborted.  An action failed.
    Operation aborted (Error: 80004004; Source: Windows)
    Failed to run the last action: Install Operating System. Execution of task sequence failed.
    Unknown error (Error: 000015FB, Source: Unknown)
    Task Sequence Engine failed! Code: enExecutionFail
    Task sequence execution failed with error code 80004005
    SetNamedSecurityInfo() failed.
    SetObjectOwner() failed. 0x8007005
    RegQueryValueExW is unsuccessful for Software\Microsoft\SMS\Task Sequence, SMSTSEndProgram
    GetTsRegValue() is unsuccessful. 0x80070002
    Error Task Sequence Manager failed to execute task sequence. Code 0x80004005


    • Edited by GregatChristie Tuesday, October 17, 2017 3:23 PM Fixed a duplicate line.
    Tuesday, October 17, 2017 3:22 PM

Answers

  • I see you're adding a lot of packages. This will break imaging if you apply packages for a different OS than what you're deploying.

    I prefer not to add updates using packages but to build a reference image with the latest patches already install by using Windows update. If you do need to use packages for hotfixes, make sure they are only applied to the applicable OS.

    This guide shows you how to build a Windows 7 reference image and include packages but restrict them to only be applied to Windows 7 - Building a Windows 7 SP1 Reference Image using MDT 2013 Update 2


    If this post is helpful please vote it as Helpful or click Mark for answer.

    • Marked as answer by GregatChristie Thursday, October 19, 2017 6:58 PM
    Wednesday, October 18, 2017 6:56 PM
  • Assuming you are installing a Windows 10 image: according to DISM.logs you are also trying to inject Windows 7 packages (for example KB2533552, https://www.microsoft.com/en-us/download/details.aspx?id=18257) into your image. Aside from taking longer, this is causing several error messages in your DISM.logs (although I do not believe that this is the primary issue which causes your TS to fail). Remember, DISM does not detect the applicability of a package initially, but tries to apply the package and then fails. In addition, as Dan mentioned above, DISM fails to locate some package source files, so you might have outdated entries in your packges folder as well.

    To work around the issue, create separate selection profiles for your Windows 7 and Windows 10 packages (for each supported release, for example "Windows 10 1709 Packages") and then modify your TS to apply packages not from "All packages" selection profile, but from your "Windows 10 1709 Packages" selection profile.

    Try running the OSD after modifying the TS and, should you run into any issues again, post updated BDD.log / DISM.log here.

    Final thought, if you created your Windows 10 TS using an older MDT build, you might want to update unattend.xml to reflect latest changes incorporated into MDT templates.


    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    • Marked as answer by GregatChristie Thursday, October 19, 2017 6:59 PM
    Thursday, October 19, 2017 3:08 PM

All replies

  • Please post your BDD.log and I will take a look. You will find it either in the MININT folder or in the C:\Windows\temp folder

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".


    Tuesday, October 17, 2017 5:55 PM
  • Is this your first time building and deploying Windows 10?

    It's possible that you may need to uninstall all WAIK or ADK iterations your have on your deployment server. You may also want to consider uninstalling MDT. Don't worry your actual deployment share folder remains intact.

    After removing the software and rebooting, then install the latest ADK and MDT. You can open your existing deployment share folder in MDT. Be sure to update the deployment share so that new bootable images are created. 

    My guess is that your system is not using the correct version of WinPE. Also there have been a few iterations of MDT where the templates were updated and required that you create new task sequences in order to get those changes.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, October 17, 2017 7:29 PM
  • When I try "copy c:\windows\temp\deploymentLogs\bdd.log \\MDTServer\MDTBuild" I get an access is denied.  Is there another way to get the file off of the failed PC being imaged?

    Thanks for your assistance,
    Greg


    You may want to check if you have "write" permissions on the share.

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".


    Wednesday, October 18, 2017 7:17 AM
  • Greg, I see you said you've been using MDT for as long as I have. I will say when jumping to new versions or new hardware, it's easy to forget some of the changes we made years ago. The default permissions are different compared to MDT several years ago.

    You might want to borrow Johan's powershell script in his guide Building a Windows 10 v1703 reference image using MDT. You can edit it to add the accounts you use, but it does make it easy to apply or re-apply those permissions to your deployment share.


    If this post is helpful please vote it as Helpful or click Mark for answer.


    • Edited by Dan_Vega Wednesday, October 18, 2017 4:50 PM typo
    Wednesday, October 18, 2017 1:14 PM
  • Greg, I say you said you've been using MDT for as long as I have. I will say when jumping to new versions or new hardware, it's easy to forget some of the changes we made years ago. The default permissions are different compared to MDT several years ago.

    You might want to borrow Johan's powershell script in his guide Building a Windows 10 v1703 reference image using MDT. You can edit it to add the accounts you use, but it does make it easy to apply or re-apply those permissions to your deployment share.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Ran the rights Powershell script from the link above.  Tried the imaging again and so far the same error at the end of Install Operating System for a Windows 10 image.

    Greg

    Wednesday, October 18, 2017 4:43 PM
  • If you can put your bdd.log file on a share site like OneDrive, it'll be helpful to comb through it using the cmtrace log tool.

    If you haven't already, it'll be useful to set the log location in your customsetting.ini

    Example:

    SLShare=\\SERVER\LogFiles$

    That way you can refer to the log files when a deployment is done. The logs have lots of useful info in them. They can be great to refer to for those that have to do asset inventory since the logs contain the serial number and asset tag (if it was set).


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 18, 2017 4:56 PM
  • When I try "copy c:\windows\temp\deploymentLogs\bdd.log \\MDTServer\MDTBuild" I get an access is denied.  Is there another way to get the file off of the failed PC being imaged?

    Thanks for your assistance,
    Greg


    You may want to check if you have "write" permissions on the share.

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".


    I have looked at my permissions, to be safe I've added Everyone, Administrators and Users just to try and cover all my write permission basis.
    Wednesday, October 18, 2017 5:29 PM
  • Please post your BDD.log and I will take a look. You will find it either in the MININT folder or in the C:\Windows\temp folder

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".


    Used the SLShare to grab logs which worked great.  BDD.log attached here, hopefully there are some details in here that help.

    https://1drv.ms/u/s!AkUC_yo2Law27y33dL5atXXC4Dy9

    Thanks again,

    Greg

    Wednesday, October 18, 2017 5:55 PM
  • Is this your first time building and deploying Windows 10?

    It's possible that you may need to uninstall all WAIK or ADK iterations your have on your deployment server. You may also want to consider uninstalling MDT. Don't worry your actual deployment share folder remains intact.

    After removing the software and rebooting, then install the latest ADK and MDT. You can open your existing deployment share folder in MDT. Be sure to update the deployment share so that new bootable images are created. 

    My guess is that your system is not using the correct version of WinPE. Also there have been a few iterations of MDT where the templates were updated and required that you create new task sequences in order to get those changes.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    The WAIK and MDT 2013 are both brand new on the server.  Updated the Deployment Share, completely regenerated the boot images and replaced my boot device with that.  Created a new "Standard Client Task Sequence" and running that TS.  WinPE version being used is 10.0.15063.

    Windows 7 images work great and Windows 10 images fail at the same place every time.

    Wednesday, October 18, 2017 6:24 PM
  • I see you're adding a lot of packages. This will break imaging if you apply packages for a different OS than what you're deploying.

    I prefer not to add updates using packages but to build a reference image with the latest patches already install by using Windows update. If you do need to use packages for hotfixes, make sure they are only applied to the applicable OS.

    This guide shows you how to build a Windows 7 reference image and include packages but restrict them to only be applied to Windows 7 - Building a Windows 7 SP1 Reference Image using MDT 2013 Update 2


    If this post is helpful please vote it as Helpful or click Mark for answer.

    • Marked as answer by GregatChristie Thursday, October 19, 2017 6:58 PM
    Wednesday, October 18, 2017 6:56 PM
  • I'd also suggest injecting drivers using the total control method so that only the drivers needed are injected. This also cuts down your deployment time.

    MDT 2013 Lite Touch Driver Management


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 18, 2017 7:00 PM
  • I see you're adding a lot of packages. This will break imaging if you apply packages for a different OS than what you're deploying.

    I prefer not to add updates using packages but to build a reference image with the latest patches already install by using Windows update. If you do need to use packages for hotfixes, make sure they are only applied to the applicable OS.

    This guide shows you how to build a Windows 7 reference image and include packages but restrict them to only be applied to Windows 7 - Building a Windows 7 SP1 Reference Image using MDT 2013 Update 2


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Just to be certain, I created another new Task Sequence with no modifications except a Pause button.  No packages or updates, tried imaging again and got the same error.  I love the reference image process, that's how we've managed our Windows 7 all of these years.
    Wednesday, October 18, 2017 7:36 PM
  • I'd also suggest injecting drivers using the total control method so that only the drivers needed are injected. This also cuts down your deployment time.

    MDT 2013 Lite Touch Driver Management


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Total oversight the driver profiles had all.  Put it back to Nothing, tried the image process and died on the DISM.exe post Install Operating System.

    I've created a new test server and a new deployment share, Windows 10 created successfully through 3 iterations.  I may have to try and move my Windows 7 WIM's and drivers over to the working new server and move on.

    Wednesday, October 18, 2017 7:43 PM
  • If it makes it easier on you, you can have both deployment shares open in the workbench and copy and paste applications and whatnot to quickly move that stuff over onto the new deployment share.

    But you should build all new task sequences in case there's something wrong with the ones on your previous deployment share.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 18, 2017 8:53 PM
  • If it makes it easier on you, you can have both deployment shares open in the workbench and copy and paste applications and whatnot to quickly move that stuff over onto the new deployment share.

    But you should build all new task sequences in case there's something wrong with the ones on your previous deployment share.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    That's a great idea, I think that's the plan.

    Could you do me a favor and look over my CustomSettings below and let me know if I got any problems in there so I know my new server is in great shape?

    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    _SMSTSORGNAME=Imaging a %TaskSequenceID% with Serial #: %OSDComputerName%
    OSDComputerName=%SerialNumber%

    UserDataLocation=NONE
    OSInstall=Y
    AdminPassword=ADMINPW
    HideShell=NO
    wsusserver=https://sccm12.WSUS.com
    ApplyGPOPack=NO

    ;JoinWorkgroup=WORKGROUP

    SkipDomainMembership=YES
    JoinDomain=<DOMAIN>
    DomainAdmin=administrator
    DomainAdminDomain=<DOMAIN>
    DomainAdminPassword=<PW>

    SkipComputerName=NO
    SkipLocaleSelection=YES
    SkipTimeZone=YES
    TimeZoneName=Central Standard Time
    SkipAdminPassword=Yes
    SkipProductKey=YES
    SkipUserData=YES
    SkipLocaleSelection=YES
    SkipTaskSequence=NO
    SkipBitLocker=YES
    SkipSummary=YES
    SkipRoles=YES
    SkipRearm=YES
    SkipComputerBackup=YES

    EventService=http://SERVERNAME:9800

    SLShare=\\SERVERNAME\Logs


    Wednesday, October 18, 2017 9:01 PM
  • Looks good. It's optional but I like creating a totally separate deployment share that is built purely for creating reference images. You can take a few extra steps of making that share very automated. Normally you want to be the only person with access to that if you're the person responsible for making the image. Then you can have your main share that multiple techs have access to.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 18, 2017 9:19 PM
  • Looks good. It's optional but I like creating a totally separate deployment share that is built purely for creating reference images. You can take a few extra steps of making that share very automated. Normally you want to be the only person with access to that if you're the person responsible for making the image. Then you can have your main share that multiple techs have access to.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Another great idea.  I appreciate all the help the last couple of days.

    Greg

    Wednesday, October 18, 2017 9:25 PM
  • Please post your BDD.log and I will take a look. You will find it either in the MININT folder or in the C:\Windows\temp folder


    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".


    Used the SLShare to grab logs which worked great.  BDD.log attached here, hopefully there are some details in here that help.

    https://1drv.ms/u/s!AkUC_yo2Law27y33dL5atXXC4Dy9

    Thanks again,

    Greg

    Sounds like recreating Windows 10 TS fixed the issue for you. This would also explain what I am seeing in your BDD.log - DISM operation fails as it tries to inject unattend.xml into your offline image. You should be able to find additional information in the DISM log located at X:\windows\Logs\DISM\dism.log

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Thursday, October 19, 2017 8:38 AM
  • Please post your BDD.log and I will take a look. You will find it either in the MININT folder or in the C:\Windows\temp folder


    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".


    Used the SLShare to grab logs which worked great.  BDD.log attached here, hopefully there are some details in here that help.

    https://1drv.ms/u/s!AkUC_yo2Law27y33dL5atXXC4Dy9

    Thanks again,

    Greg

    Sounds like recreating Windows 10 TS fixed the issue for you. This would also explain what I am seeing in your BDD.log - DISM operation fails as it tries to inject unattend.xml into your offline image. You should be able to find additional information in the DISM log located at X:\windows\Logs\DISM\dism.log

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Building a new Server and Deployment Share was not my first choice.  Looking into the DISM log sounds great, there are plenty of errors to view in this log.  I have it added to my OneDrive link.  Any of those errors that might be fixed?

    https://1drv.ms/u/s!AkUC_yo2Law27y33dL5atXXC4Dy9

    Thanks so much for the effort,

    Greg


    Thursday, October 19, 2017 1:28 PM
  • Looks like problems with packages, files not being found or not valid to apply in offline mode. 

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, October 19, 2017 2:03 PM
  • Assuming you are installing a Windows 10 image: according to DISM.logs you are also trying to inject Windows 7 packages (for example KB2533552, https://www.microsoft.com/en-us/download/details.aspx?id=18257) into your image. Aside from taking longer, this is causing several error messages in your DISM.logs (although I do not believe that this is the primary issue which causes your TS to fail). Remember, DISM does not detect the applicability of a package initially, but tries to apply the package and then fails. In addition, as Dan mentioned above, DISM fails to locate some package source files, so you might have outdated entries in your packges folder as well.

    To work around the issue, create separate selection profiles for your Windows 7 and Windows 10 packages (for each supported release, for example "Windows 10 1709 Packages") and then modify your TS to apply packages not from "All packages" selection profile, but from your "Windows 10 1709 Packages" selection profile.

    Try running the OSD after modifying the TS and, should you run into any issues again, post updated BDD.log / DISM.log here.

    Final thought, if you created your Windows 10 TS using an older MDT build, you might want to update unattend.xml to reflect latest changes incorporated into MDT templates.


    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    • Marked as answer by GregatChristie Thursday, October 19, 2017 6:59 PM
    Thursday, October 19, 2017 3:08 PM
  • Assuming you are installing a Windows 10 image: according to DISM.logs you are also trying to inject Windows 7 packages (for example KB2533552, https://www.microsoft.com/en-us/download/details.aspx?id=18257) into your image. Aside from taking longer, this is causing several error messages in your DISM.logs (although I do not believe that this is the primary issue which causes your TS to fail). Remember, DISM does not detect the applicability of a package initially, but tries to apply the package and then fails. In addition, as Dan mentioned above, DISM fails to locate some package source files, so you might have outdated entries in your packges folder as well.

    To work around the issue, create separate selection profiles for your Windows 7 and Windows 10 packages (for each supported release, for example "Windows 10 1709 Packages") and then modify your TS to apply packages not from "All packages" selection profile, but from your "Windows 10 1709 Packages" selection profile.

    Try running the OSD after modifying the TS and, should you run into any issues again, post updated BDD.log / DISM.log here.

    Final thought, if you created your Windows 10 TS using an older MDT build, you might want to update unattend.xml to reflect latest changes incorporated into MDT templates.


    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Turns out I didn't know what Packages were and where they are turned on/off.  Now I know, there were a ton of Windows 7 packages (KB Updates as you mentioned) being applied which would be obvious why that would break Windows 10.  Changed the Package profile drop down choice to Nothing.  First attempt to update my reference Windows 10 image worked.  This must have been done before I started the imaging process.

    I'm fixed, no need to build new Deployment Share or Server.

    Thanks to everybody for giving me so many good ideas and for your patience.

    Greg

    Thursday, October 19, 2017 8:24 PM