none
MDT Deploy TS installing OS twice. RRS feed

  • Question

  • I have a few Task Sequences and after I updated my image, I got an error trying to generate a CLG Catalog File. I completely deleted and recreated my Capture and my Deploy TS. Now, it installs drivers, the OS, goes to DISM using the unattend, then goes back to Running action: Install OS. My other TS's are working fine. Any ideas?
    Once it completes the 2nd install of the OS (which runs really fast), it just sits there at 100% and the log shows over and over 100% entries.
    • Edited by the1rickster Tuesday, July 19, 2016 1:30 PM more info
    Tuesday, July 19, 2016 1:29 PM

Answers

  • This is due to having Patches being applied during your TS. Dism your updates into the base Image, then turn off your apply (or whatever you called your patches in TS)

    • Proposed as answer by KOdell4771 Sunday, November 13, 2016 5:15 PM
    • Marked as answer by the1rickster Thursday, March 9, 2017 5:08 PM
    Sunday, November 13, 2016 5:15 PM
  • I'll recap my issue from the top... What I was experiencing was the Deploy Task Sequence running Apply OS a second time. The first time, it took its regular time to deploy the OS. The 2nd time, it flew by really quickly, but when it got to 100% (the 2nd time around), it sat there at 100% until I killed it. I could see the log changing while it was running, 100%.....100%....100%....a new line entry in the log, endlessly. It would never get past this. I deleted the WIM, the Capture TS, the Deploy TS, the Unattend. Sigh. I rebuilt it all and recaptured and redeployed it and it worked. I had another image do this once in the past and this was the only solution. Once it mapped the drive to get the image, it did, and a whole 2nd time as well. Just a glitch I would say but a huge hassle to redo the whole thing.
    • Marked as answer by the1rickster Saturday, November 19, 2016 10:05 PM
    Monday, November 14, 2016 9:31 PM

All replies

  • I have never paid attention to my builds but I have recently noticed that my Windows 10 builds (MDT2013 U2 and latest ADK) exhibits this also (however, my builds run to completion successfully).  My Windows 7 builds (running MDT2012 and W8.1 ADK) do not.

    • Proposed as answer by KOdell4771 Sunday, November 13, 2016 5:18 PM
    Wednesday, July 27, 2016 4:00 PM
  • Yes, I have only one Deploy that does this, my other task sequences do not install the OS twice. I can't figure out where its coming from to tell it to do so. I've completely removed and recreated the Sysprep/Capture and the Deploy TS and recaptured my VM as well. All of my other tasks sequences perform normally.
    Wednesday, July 27, 2016 5:39 PM
  • When you say that your builds run to completion, you mean your Deploys?
    Also, you said your Windows 7 do not. Meaning, they do not complete or they do not have this issue. I'm taking it that Win7 does not run the OS install twice. Its the strangest thing, and only on one TS.
    Wednesday, July 27, 2016 5:56 PM
  • I meant my Win 7 builds do not run OS install twice.  I reviewed the bdd.log file from all the builds and saw something that may be a hint about what is going on.  My Win 7 build has a captured .wim file.  When the build runs, no unattend.xml is seen being applied.  My win 10 builds are straight MS source files and the unattend.xml is clearly applied.  Maybe having the unattend.xml applied to source files forces the second pass of the OS install.

    Wednesday, July 27, 2016 7:35 PM
  • Did you get any further with this? I'm trying to do a simple Win10 reference image capture and it cycles through the OS TS section twice...
    • Proposed as answer by KOdell4771 Sunday, November 13, 2016 5:18 PM
    Thursday, November 10, 2016 2:17 AM
  • I had a similar issue when i didn't delete/move the existing capture file from the deployment share capture folder.

    My Mdt capture task sequence appended the new capture to the existing image at index 2

    I then encountered an error generating the catalog file i cant remember exactly it was an exception about the a key already being associated if i remember correctly.

    I was apply a fix to my image with dism by deleting  the existing image index and renaming the image and re imported into mdt ok.

    In the end I rebuilt the image and recaptured then imported into mdt.

    • Proposed as answer by KOdell4771 Sunday, November 13, 2016 5:13 PM
    • Unproposed as answer by KOdell4771 Sunday, November 13, 2016 5:13 PM
    Thursday, November 10, 2016 10:33 AM
  • This is due to having Patches being applied during your TS. Dism your updates into the base Image, then turn off your apply (or whatever you called your patches in TS)

    • Proposed as answer by KOdell4771 Sunday, November 13, 2016 5:15 PM
    • Marked as answer by the1rickster Thursday, March 9, 2017 5:08 PM
    Sunday, November 13, 2016 5:15 PM
  • This is due to having Patches being applied during your TS. Dism your updates into the base Image, then turn off your apply (or whatever you called your patches in TS)

    That isn't 100% correct.  The second install OS step is applying the unattend (which does have the patches called out).

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Sunday, November 13, 2016 9:51 PM
    Moderator
  • fair enough BUT.

    What happen it you try disabling this once. Then image. Do you get OS re-run?

    Monday, November 14, 2016 8:25 PM
  • I don't see any reason to disable applying the unattend.  The interesting thing here would be to look at the dism log and see why it is hanging.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Monday, November 14, 2016 9:12 PM
    Moderator
  • I'll recap my issue from the top... What I was experiencing was the Deploy Task Sequence running Apply OS a second time. The first time, it took its regular time to deploy the OS. The 2nd time, it flew by really quickly, but when it got to 100% (the 2nd time around), it sat there at 100% until I killed it. I could see the log changing while it was running, 100%.....100%....100%....a new line entry in the log, endlessly. It would never get past this. I deleted the WIM, the Capture TS, the Deploy TS, the Unattend. Sigh. I rebuilt it all and recaptured and redeployed it and it worked. I had another image do this once in the past and this was the only solution. Once it mapped the drive to get the image, it did, and a whole 2nd time as well. Just a glitch I would say but a huge hassle to redo the whole thing.
    • Marked as answer by the1rickster Saturday, November 19, 2016 10:05 PM
    Monday, November 14, 2016 9:31 PM
  • This is why I said, Dism all your updates into the wim. Then use this wim during deployment and don't use MDT to apply updates. This causes the 2 passes during the installation process.

    If this didn't work, I would have asked to look at logs.

    BUT glad to hear it's working now.

    Monday, November 14, 2016 9:54 PM
  • Thanks. I don't apply any updates when I capture or deploy. It only has happened recently. We only get patches by manually running LanDesk patches from the desktop as the user.
    Monday, November 14, 2016 9:58 PM
  • I'll recap my issue from the top... What I was experiencing was the Deploy Task Sequence running Apply OS a second time. The first time, it took its regular time to deploy the OS. The 2nd time, it flew by really quickly, but when it got to 100% (the 2nd time around), it sat there at 100% until I killed it. I could see the log changing while it was running, 100%.....100%....100%....a new line entry in the log, endlessly. It would never get past this. I deleted the WIM, the Capture TS, the Deploy TS, the Unattend. Sigh. I rebuilt it all and recaptured and redeployed it and it worked. I had another image do this once in the past and this was the only solution. Once it mapped the drive to get the image, it did, and a whole 2nd time as well. Just a glitch I would say but a huge hassle to redo the whole thing.
    If your capture is corrupt as this would indicate then you would get stuck when DISM is applying the unattend.  MDT is still not installing the OS twice though.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Sunday, November 20, 2016 3:18 AM
    Moderator
  • The only solution I've found for this scenario when it arises is just to rerun the Capture and place the new WIM into the TS. When I check the log while it's running, it installs the OS, about 20 mins. Then it doesn't get to DISM. It installs the OS. This time about 1 minute or so. The log shows....a whole new section of OS install. It never states this when the TS runs correctly. The log shows 100%....100%....100%.... over and over and never ends. So, I kill it.

    I have to recapture or rebuild but sometimes its just what you have to do.

    Sunday, November 20, 2016 1:33 PM
  • If you look at the smsts.log it will show dism being ran. Then if you look at the dism log it will show that it is hung on some step.

    Many questions such as where do I find logs and what logs are interesting are found in: MDT TechNet Forum - FAQ & Getting Started Guide Please take the time to read it. Also if you don't post logs your problem won't be easily solved.

    Sunday, November 20, 2016 11:28 PM
    Moderator
  • This is due to having Patches being applied during your TS. Dism your updates into the base Image, then turn off your apply (or whatever you called your patches in TS)


    I made the same experience. I disabled der "Apply Patches" step in the Task Sequence and the OS Install only runs once.
    Wednesday, March 8, 2017 11:56 AM
  • This issue is not happening because the unattend is running. It is actually, literally applying the OS a second time. It happens only on a few TS's I have....the others do not do this. Disabling the Apply Patches did stop the 2nd OS install (and the unattend behaves normally). Since this post I had a 2nd TS do the same, and now both are running normally again after disabling the Apply Patches. It never happened to either TS before, but for some reason have started doing this. So glad its better again. The log shows a full OS install, then another full install to 100%....100%....100%....endlessly. Thanks for the tip!
    Thursday, March 9, 2017 5:13 PM