none
MDT 2013 Update 1 - Existing TS now errors with DeploymentType="" RRS feed

  • Question

  • I have just updated to MDT 2013u1 on my test system and am in the process of going through my existing Task Sequences and making sure they are all okay before: A. Rolling out the upgrade to my other servers, and B. Delving into Win10.

    One of my TaskSequences that was working fine now fails immediately after the Deployment Wizard Summary page claiming that the DeploymentType="". This is set in the CustomSettings.ini and, looking at the logs, this is correctly set right up to this point and then as soon as I click "Begin", it is set to "". There is nothing in any of the corresponding Database entries that apply and the TaskSequence its self does not specify the DeploymentType.

    I have already had to manually edit 2 scripts to get Application Bundles working and to get past an Unattend.XML parsing error. I'm not very impressed at the amount of breakage in this version, I managed to go from 2010 to 2012u1 without incident.

    Wednesday, August 26, 2015 10:23 AM

Answers

  • There should be no need to set DeploymentType to NEWCOMPUTER in CustomSettings.ini.  It will be set automatically based on the task sequence chosen and where the process is started.  So this is actually by design - you should let MDT set this variable automatically.

    With the last couple of releases prior to MDT 2013 Update 1, this accidentally worked, but with the re-introduction of in-place upgrade support in MDT 2013 Update 1, it does purposely recalculate this.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Thursday, August 27, 2015 3:02 PM

All replies

  • A new version of 2013 U1 is in the works in the next couple of weeks.

    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, August 26, 2015 4:00 PM
    Moderator
  • What value are you setting for DeploymentType in CustomSettings.ini?

    Typically we wouldn't suggest setting this at all, as it is automatically set based on the scenario and the selected task sequence.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Wednesday, August 26, 2015 4:09 PM
  • It is set to "NEWCOMPUTER".

    All of our systems are built from the ground up each time, so I have no need of anything other than a NEWCOMPUTER build, hence setting it in the CS.ini

    I'm unsure where else it would be set, dynamically or otherwise. I'd like to know because I am trying to plan taking our deployment system further and maybe, maybe, trying in-place upgrades.

    I have some testing to do as I've just discovered that if I don't skip any wizard pages, then it works fine, so there must be a different setting that is being skipped that is interacting with the DeploymentType.

    Glad to hear that there is going to be a new version, but if I get all this working, I think I'll stick with the one I know.

    Thursday, August 27, 2015 8:58 AM
  • Right, narrowed it down to skipping the TaskSequence wizard page. I have the correct task sequence ID specified in the Role and if I don't skip the page, but leave the settings as they are populated (i.e have the TaskSequenceID setting pre-populate the page and just click next.) I don't get the error.

    I can only surmise that that the wizard is over writing my DeploymentType if I skip the page. Bug or am I missing something?

    Thursday, August 27, 2015 10:16 AM
  • There should be no need to set DeploymentType to NEWCOMPUTER in CustomSettings.ini.  It will be set automatically based on the task sequence chosen and where the process is started.  So this is actually by design - you should let MDT set this variable automatically.

    With the last couple of releases prior to MDT 2013 Update 1, this accidentally worked, but with the re-introduction of in-place upgrade support in MDT 2013 Update 1, it does purposely recalculate this.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Thursday, August 27, 2015 3:02 PM
  • I have yet to be able to test this, as I have removed the line from my CustomSettings.ini, but now cannot update my boot media as I am getting consistent errors that the WIM file cannot be mounted as a file is in use. The account is a member of the local administrators group, the Workbench is open with elevated rights, I've tried the built-in local admin with the same result. I've used Proc'mon' to unlock the files and it keeps happening. i found a blog that suggested that having the AIK on a non-system drive would help; seemingly not in this case as I uninstalled it and added a data drive to my VM and reinstalled there.

    Monday, August 31, 2015 9:29 AM
  •  By chance do you have McAfee antivirus?  That's the typical culprit with these types of issues.



    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Monday, August 31, 2015 9:33 AM
  • No, it's an isolated VM, so I'm not running AV on it just now.
    Monday, August 31, 2015 9:47 AM
  • I have also been trying the Dism /Cleanup-Wim command, but there are a number of DAT files "in use" by system in a number of the discovered mount directories which I suspect is(are?) the issue.

    Monday, August 31, 2015 10:31 AM
  • The in-use DAT files are probably registry files.  You can probably see them in RegEdit as some extra mounted hives (they'll be fairly obvious).  You can manually close them one by one (select one, close it from the File menu), or you can reboot the machine to close them all.

    It sounds like DISM may be crashing while updating the boot image, which is one of the issues that we're still investigating.  If this happens once, it leave the registry files mounted, which causes problems with subsequent attempts to update the boot image.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Monday, August 31, 2015 10:35 AM
  • OK, can you post a link to where there will be any announcement about the fix for this since this will pretty much stall my development please.

    And thanks for the input.

    Monday, August 31, 2015 11:36 AM