none
[SOLVED] Diskpart Convert Operation Results in: Unable to find the SMS Task Sequencer. The deployment will not proceed. RRS feed

  • Question

  • Apparently, converting a disk [from MBR] to GPT via diskpart will result in an "Unable to find the SMS Task Sequencer.  The deployment will not proceed." error when the machine boots into Windows.

    Steps to Reproduce:

    1) Create a new Standard Client Task Sequence to install Win 7 x64 SP1 Enterprise.

    2) Edit your TS to run the following command prior to the 'Format and Partition Disk' step:

    • cmd.exe /c diskpart /s "%SCRIPTROOT%\diskpart.script"

    3) Create a new text file with the following contents:

    • sel dis 0
    • clean
    • convert gpt noerr
    • exit

    4) Save the file as "diskpart.script" in the 'Scripts' directory of the DeploymentShare

    5) Image the machine: After the WIM is laid down, DISM runs and the system restarts.

    6) OS detects hardware, injects drivers etc. and restarts.

    7) Eventually it gets into Windows and fails with: "Unable to find the SMS Task Sequencer.  The deployment will not proceed."

    Optional: Set your DriverGroup and update the 'Inject Driver' step.  (Note: Don't do too much - want this as barebones as possible.)


    I can reproduce across several models [albeit all form the same manufacturer], a Hyper-V VM and it doesn't seem to matter if I convert it back to MBR after converting it to GPT.

    I'm in Chicago this week attending Ignite, and I can reproduce this in the hands on & instructor led labs, during a Win10 deployment; and they're using MDT 2013 Update 1.   o_O

    Is this normal and expected behavior?
    Does anyone have the bandwidth to test?
    Thoughts?





    • Edited by JuliusPIV Monday, May 18, 2015 6:50 PM
    Tuesday, May 5, 2015 9:14 PM

Answers

  • Thanks for the call today Mayank Sharma5!

    So here's an update, just so everyone else is aware:

    The process is failing because the 'Tools' folder is missing from C:\_SMSTaskSequence, so some ZTI/LTI script isn't firing off or completing successfully.  [Note: I don't know which script is responsible for that but I don't have the bandwidth to dive into that.]

    This error is not limited to diskpart convert operations but also in cases where one is manually creating partitions, like situations where one wants to dual boot (or retain data on another partition on the disk).  In those cases, most don't use the baked in 'Format and Partition Disk' step and instead use either a script or a series of Task Sequence steps that will do the following:

    1. Create a second/third partition
    2. Format it with NTFS
    3. Label the drive
    4. Install Windows on the new partition.
    5. Update the system partition


    This process works fine in MDT 2010, but ceased functioning in MDT 2012 and beyond, including MDT 2013 Update 1 as I discovered at Microsoft Ignite 2015.

    Having said all that, Mayank suggested the process below:

    • After the existing 'Format and Partition Disk' step, create a 'Run Command Line' step to do the diskpart clean operation
    • Create another 'Format and Partition Disk' step after that.
    • It should look something like this:


    HOWEVER, after adding that to a test Task Sequence, the Task Sequence failed when running the 'Inject Drivers' step failing with a 'Path not Found 76' error.



    Adding the '/debug:true' switch to the Inject Drivers step (via the ts.xml) didn't reveal any new information requiring a deeper analysis.  Our DriverGroup is set via CustomSettings.ini and we're not using a selection profile.

    Here's a quick deep dive on what I discovered and if you don't care for this, go to the end for the proposed solution:

    1. When booting into WinPE, running diskpart, volume 0 of disk 0 is assigned the letter "C"
    2. After the 'Format and Partition Disk' step, lis vol shows the volume letter has changed to "V"
    3. Then the diskpart script executes, which simply cleans the disk then converts to gpt, leaving no volumes.
    4. Finally, the second 'Format and Partition Disk' step executes and lis vol shows the volume letter changes again to W.

    Here's a screenshot of diskpart for each of those steps:


    And while I cannot prove this by way of a log or script logic, therein lies the problem:  Changing the drive letter to something other than V seems to be the source of the 'Inject Drivers' step, and potentially any subsequent scripts that execute, which more than likely is what ultimately results in the "Unable to find the SMS Task Sequencer.  The deployment will not proceed." error that started this whole mishigas.
    I have to assume that either one or more Task Sequence environment variables aren't getting updated, or, something is hard coded to look for V.

    Note: I hate loose ends and not knowing root cause.  So while I really would love to get to the bottom of this, I'm slammed this week and already stretched pretty thin and can't dedicate much more time on figuring this out.  If someone wants to carry that torch, I'm sure some folks at Microsoft might appreciate the legwork.



    Proposed Solution:
    To work through this new problem, and ultimately getting it resolved in our environment, I ended up modifying the diskpart script as such (emphasis added for new steps):

    sel dis 0
    clean
    convert gpt
    cre par pri
    format quick fs=ntfs label="OSDisk"
    assign letter="C"
    exit


    Keeping everything the same, and just updating the diskpart script, this results in the following drive letter changes: C -> V -> C -> V

    From there, the files that need to be in C:\_SMSTaskSequence get copied, 'Inject Drivers' step completes successfully and the machines image successfully.

    All of this work was done on a test Task Sequence that only installed stock vanilla Windows 7 to eliminate the possibility that something we customized broke it.  This vanilla TS previously failed but is now working soo..

    Now we test "fo' realz":

    1. Encrypted a machine
    2. Verified the machine was locked: rebooted, bootguard loads, Symantec login prompt appears
    3. Verified the MBR is pwned by Symantec
    4. Ran the development copy of our production task sequence, which has the above changes
    5. Image completed successfully.

    I imaged 5 unencrypted machines, one of which was a VM, successfully.  I think we're in the clear!

    Now I just need to submit a change request to merge my changes into the production TS and we'll be all set!



    References:

    https://social.technet.microsoft.com/Forums/en-US/76c87da6-a050-4679-92a5-da670481b535/dual-boot-macs-fail-sms-task-sequencer-after-upgrading-to-mdt2012?forum=mdt

    https://social.technet.microsoft.com/Forums/en-US/1036deca-bd04-4fe2-aaec-2c17bb86a63f/mdt-and-macs-running-bootcamp-worked-in-mdt-2010-now-does-not-in-mdt-2012?forum=mdt



    Monday, May 18, 2015 2:46 PM

All replies

  • Can you post the logs to some public sharing site (Onedrive.com or something).  Or better yet file a connect bug with your logs zipped up and attached.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, May 5, 2015 9:43 PM
    Moderator
  • Can you post the logs to some public sharing site (Onedrive.com or something).  Or better yet file a connect bug with your logs zipped up and attached.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Logs are here: http://1drv.ms/1H10JbY

    I opened a case, but not a bug report.  I was seeking validation that others could reproduce it and it wasn't just a 'me' thing. 

    Wednesday, May 6, 2015 2:43 PM
  • if you plan to convert mbr to gpt, you can try third party software AOMEI Partition Assistant. it is able to help users to convert mbr to gpt without  any data loss.

    To be clear: The goal isn't to convert from gpt to mbr or mbr to gpt without losing data.  That's actually irrelevant here.  I'm more focused on "Is this expected MDT Task Sequence behavior when performing a convert operation?"

    However, having said that, I do appreciate you sharing that product for others who may be looking for something that's able to do just as you described.

    Wednesday, May 6, 2015 2:51 PM
  • I'm curious, why are you trying to convert instead of formatting GPT when GPT is necessary? 
    Wednesday, May 6, 2015 3:17 PM
  • If it isn't being ran in ZTIDiskpart.wsf and ZTIDiskUtility.vbs then I wouldn't expect MDT to know what to do with that.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, May 6, 2015 6:20 PM
    Moderator
  • I'm curious, why are you trying to convert instead of formatting GPT when GPT is necessary? 

    Well, I think the partition type is a red herring as it doesn't [seem] matter if I'm going from MBR to GPT and letting ZTIDiskPart do its thing OR converting back to MBR (from GPT) before ZTIDiskPart does it thing.

    Wednesday, May 6, 2015 7:29 PM
  • If it isn't being ran in ZTIDiskpart.wsf and ZTIDiskUtility.vbs then I wouldn't expect MDT to know what to do with that.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Sorry if I seem dense, but I don't know that I'm following you 100% here:
    Why would performing diskpart actions before the 'Format and Partition Disk' step create problems?

    For what its worth, I've gone as far as:

    1. Duplicating the 'Format and Partition Disk' step
    2. Duplicating the script that step calls, ZTIDiskPart.wsf
    3. Search for: oUtility.RunCommandWrite oExec, "CLEAN"
    4. Add a new line after that to convert the disk to GPT:
      oUtility.RunCommandWrite oExec, "CONVERT GPT NOERR"

    So effectively my modified ZTIDiskPart.wsf is:

    1. cleaning the disk which is a stock action
    2. convert the disk to GPT immediately after the 'clean' which is my *only* modification
    3. later around line 364 the script convert its back to MBR which is a stock action based on existing logic

    Does that make sense?


    I just finished BRK3310 and am going to head into one of the labs to reproduce in their VM environment and take a photo of the Task Sequence step, the script and the result.

    Cheers and thanks


    • Edited by JuliusPIV Wednesday, May 6, 2015 7:49 PM
    Wednesday, May 6, 2015 7:46 PM
  • Logs would still be helpful.  If for some reason we gather and GPT is what we expect and then when we get to the Diskpart steps MBR is what we find that could create unpredictable results.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, May 6, 2015 8:27 PM
    Moderator
  • Logs would still be helpful.  If for some reason we gather and GPT is what we expect and then when we get to the Diskpart steps MBR is what we find that could create unpredictable results.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    I uploaded logs from my personal virtual environment to my OneDrive earlier today few posts up.

    The disks are all MBR to begin with, then I'm converting it to GPT, then later (if I'm following the logic correctly) ZTIDiskPart is converting it back to MBR.  However, even if I do MBR > GPT > MBR (as part of my script) it still creates this problem.



    I'm in the Hands-On Labs area doing lab HOL3876.

    Focusing primarily on the MDT TS, I made the following changes:


    From there, booted the LiteTouch media, installed Win10 and eventually it failed:

    Doesn't matter if going from Windows 7 to Windows 7, Windows 7 to Windows 10 or Windows 8.1 to Windows 10 using MDT 2013 or MDT 2013 Update 1.  It fails and I don't understand why.

    I wish I could get the logs from the virtual environment, but that's not possible.  You - or anyone else for that matter - should be able to reproduce this in your environment as it does not appear to be specific to my environment.



    • Edited by JuliusPIV Wednesday, May 6, 2015 9:21 PM
    Wednesday, May 6, 2015 9:00 PM
  • Sorry I meant to say SMSTS.log also.

    I am volunteering my time (MCC just means I volunteer time not that I am MSFT or something)and I do believe you are able to get this to break.  I just don't understand why it is necessary unless it solves some problem and even then I don't understand the problem solved.  I guess I don't see any value in testing this if there is no reason for the step.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.






    Wednesday, May 6, 2015 9:29 PM
    Moderator
  • Sorry I meant to say SMSTS.log also.

    I am volunteering my time (MCC just means I volunteer time not that I am MSFT or something)and I do believe you are able to get this to break.  I just don't understand why it is necessary unless it solves some problem and even then I don't understand the problem solved.  I guess I don't see any value in testing this if there is no reason for the step.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Well first of all, let me say thank you on behalf of myself and thousands of others (at least) for your efforts!  Its so incredibly helpful to have a second pair of eyes on things like this and to have access to resources to even if its just a sounding board.
    So again, Thank you!

    Whoops: Sorry about the smsts.log!

    The answer to 'why this is important to us':

    • We use Symantec Encryption Desktop (aka PGP) in our environment

    • As such, we've added the PGP WDE driver into our boot image so that loaded so that we can mange encrypted drives not just for emergency situations but also as part of our departed user backup process. 

    • Everything seemed to be working fine, except I noticed that after laying down the WIM and the machine is restarted, it simply boots to a prompt that says 'bootguard' in the upper left corner and sits there.

    • PGP has its own bootloader called bootguard, which sits in the MBR, that is invoked when the machine starts so that the user can unlock it.

    • Symantec's answer to the bootguard prompt was to "wipe the MBR before imaging" or to update the MBR after laying down the image, both of which is what I thought MDT did by default, but that clearly wasn't working which prompted me to try different things.

    • Well as it turns out, the PGP WDE driver has a feature which prevents you from modifying the MBR/sector 0.
      (I already posted about this issue elsewhere and you were kind enough to help there as well!)

    • The only known reliable workaround/solution I've found is to convert from MBR to GPT [then back to MBR].

    • Although successful, that step creates a new challenge by breaking the Task Sequence for some yet to be determined reason.

    To date, Symantec has not been able to provide a mechanism to get around this protection.

    My final thoughts were to either:

    • remove the driver from the boot media and load it manually via a step in the Task Sequence when we need to recover or manage an encrypted disk; OR

    • unload the driver via a step in the Task Sequence when doing an OSD.

    Both of these have proven challenging and with my gearing up for Ignite, I didn't have time to get very far into either.




    • Edited by JuliusPIV Thursday, May 7, 2015 8:14 PM
    Thursday, May 7, 2015 12:51 AM
  • Oh this makes so much more sense now.  This just became much more interesting. :) If I have some time tomorrow I will dig deeper into this.  I suspect the change causes something that the scripts were never intended to handle so they handle them in some wrong way.  I suspect that mbr->gpt->mbr toggle will have to happen before we even get into a task sequence.  Although it might be interesting to have a separate pre-TS that just does the toggle.  I will try to make time.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Thursday, May 7, 2015 7:43 AM
    Moderator
  • :) yea - its kind of complicated and sort of an unusual scenario.

    Anything you can offer is greatly appreciated!



    Just to confirm, this doesn't work:

    • Edited by JuliusPIV Thursday, May 7, 2015 8:35 PM
    Thursday, May 7, 2015 8:15 PM
  • Hi Julius,

    Can you add 'format and partition disk' step before calling you script and then call it again after calling the script (to actually format it.)


    Mayank Sharma Support Engineer at Microsoft working in Enterprise Platform Support.

    Sunday, May 17, 2015 1:45 PM
  • Thanks for the call today Mayank Sharma5!

    So here's an update, just so everyone else is aware:

    The process is failing because the 'Tools' folder is missing from C:\_SMSTaskSequence, so some ZTI/LTI script isn't firing off or completing successfully.  [Note: I don't know which script is responsible for that but I don't have the bandwidth to dive into that.]

    This error is not limited to diskpart convert operations but also in cases where one is manually creating partitions, like situations where one wants to dual boot (or retain data on another partition on the disk).  In those cases, most don't use the baked in 'Format and Partition Disk' step and instead use either a script or a series of Task Sequence steps that will do the following:

    1. Create a second/third partition
    2. Format it with NTFS
    3. Label the drive
    4. Install Windows on the new partition.
    5. Update the system partition


    This process works fine in MDT 2010, but ceased functioning in MDT 2012 and beyond, including MDT 2013 Update 1 as I discovered at Microsoft Ignite 2015.

    Having said all that, Mayank suggested the process below:

    • After the existing 'Format and Partition Disk' step, create a 'Run Command Line' step to do the diskpart clean operation
    • Create another 'Format and Partition Disk' step after that.
    • It should look something like this:


    HOWEVER, after adding that to a test Task Sequence, the Task Sequence failed when running the 'Inject Drivers' step failing with a 'Path not Found 76' error.



    Adding the '/debug:true' switch to the Inject Drivers step (via the ts.xml) didn't reveal any new information requiring a deeper analysis.  Our DriverGroup is set via CustomSettings.ini and we're not using a selection profile.

    Here's a quick deep dive on what I discovered and if you don't care for this, go to the end for the proposed solution:

    1. When booting into WinPE, running diskpart, volume 0 of disk 0 is assigned the letter "C"
    2. After the 'Format and Partition Disk' step, lis vol shows the volume letter has changed to "V"
    3. Then the diskpart script executes, which simply cleans the disk then converts to gpt, leaving no volumes.
    4. Finally, the second 'Format and Partition Disk' step executes and lis vol shows the volume letter changes again to W.

    Here's a screenshot of diskpart for each of those steps:


    And while I cannot prove this by way of a log or script logic, therein lies the problem:  Changing the drive letter to something other than V seems to be the source of the 'Inject Drivers' step, and potentially any subsequent scripts that execute, which more than likely is what ultimately results in the "Unable to find the SMS Task Sequencer.  The deployment will not proceed." error that started this whole mishigas.
    I have to assume that either one or more Task Sequence environment variables aren't getting updated, or, something is hard coded to look for V.

    Note: I hate loose ends and not knowing root cause.  So while I really would love to get to the bottom of this, I'm slammed this week and already stretched pretty thin and can't dedicate much more time on figuring this out.  If someone wants to carry that torch, I'm sure some folks at Microsoft might appreciate the legwork.



    Proposed Solution:
    To work through this new problem, and ultimately getting it resolved in our environment, I ended up modifying the diskpart script as such (emphasis added for new steps):

    sel dis 0
    clean
    convert gpt
    cre par pri
    format quick fs=ntfs label="OSDisk"
    assign letter="C"
    exit


    Keeping everything the same, and just updating the diskpart script, this results in the following drive letter changes: C -> V -> C -> V

    From there, the files that need to be in C:\_SMSTaskSequence get copied, 'Inject Drivers' step completes successfully and the machines image successfully.

    All of this work was done on a test Task Sequence that only installed stock vanilla Windows 7 to eliminate the possibility that something we customized broke it.  This vanilla TS previously failed but is now working soo..

    Now we test "fo' realz":

    1. Encrypted a machine
    2. Verified the machine was locked: rebooted, bootguard loads, Symantec login prompt appears
    3. Verified the MBR is pwned by Symantec
    4. Ran the development copy of our production task sequence, which has the above changes
    5. Image completed successfully.

    I imaged 5 unencrypted machines, one of which was a VM, successfully.  I think we're in the clear!

    Now I just need to submit a change request to merge my changes into the production TS and we'll be all set!



    References:

    https://social.technet.microsoft.com/Forums/en-US/76c87da6-a050-4679-92a5-da670481b535/dual-boot-macs-fail-sms-task-sequencer-after-upgrading-to-mdt2012?forum=mdt

    https://social.technet.microsoft.com/Forums/en-US/1036deca-bd04-4fe2-aaec-2c17bb86a63f/mdt-and-macs-running-bootcamp-worked-in-mdt-2010-now-does-not-in-mdt-2012?forum=mdt



    Monday, May 18, 2015 2:46 PM