locked
Powershell commands to change operating system image in task sequence RRS feed

  • Question

  • Hello,

    I am looking for a way to script changing a task sequence to use a different OS image file. So far the only thing I can find using the powershell MDT module is the "import-mdttasksequence" command, but it looks like that can only create a whole new task sequence.

    My end goal is to automate our master image builds  and the last step is to take the captured master wim file, import it into the Operating Systems folder, and then update the associated custom image task sequence to use that new OS image. With "import-mdttasksequence" I have to create a new task sequence with a new ID, when I already have one present that would be easier to just update to point to a different OS image. I do not see anyway to edit task sequence steps using the powershell module.

    Is this possible? Maybe using Get-Item to get the OS GUID and then editing the task sequence XML file directly?

    MDT 2013
    Server 2008 R2

    Regards,
    Darren

    Thursday, December 18, 2014 8:10 PM

Answers

  • Hi Darren,

    If I understand correctly, you can use the same name for the captured WIM file? Then you can just copy it to the operating systems and it will be picked up by your TS.

    I've found this thread on the forums that probably has your solution in it.

    From that thread:

    --------------------------

    I now capture to the Captures folder and name the WIM file after the task sequence ID. So for example, my "Update Windows 8 General Purpose" task sequence with ID "8_GP" now creates "\\server\DeploymentShare$\Captures\8_GP.wim"

    In the Scripts folder on the deployment share I created "Relocate.cmd" with the following contents:

    MOVE /Y "%DEPLOYDRIVE%\Captures\%1.wim" "%DEPLOYDRIVE%\Operating Systems\%1"
    And finally, I added a step at the end of my task sequences that runs this custom command (no Start in value defined):
    cmd /c %SCRIPTROOT%\relocate.cmd %TaskSequenceID%

    This works great and MDT does in fact recognize the changed .wim file in Operating Systems and copies it to linked deployment shares, so no worries there.

    -------------

    Hope this helps.

    • Marked as answer by dlofstedt Monday, December 22, 2014 8:14 PM
    Friday, December 19, 2014 10:46 AM

All replies

  • It's pretty typical to have at least two task sequences, a build and capture TS to create an image and a deployment TS that will install the captured image, install additional apps, and so on. Other than being "easier," is there a business need for wanting to use just one TS for everything?

    -Nick O.

    Thursday, December 18, 2014 8:39 PM
  • Hello Nick,

    Yes, I do have a build and capture TS (master image) and then a deployment TS that will install the captured image (I call it the custom deployment TS). I am trying to automate that exact process. When the build and capture TS is done, I script importing the captured wim into the deployment workbench operating systems and then I have another script that builds a new custom deployment TS to deploy the captured image.

    I am trying to make this a repeatable process, and what happens the second time around is I end up with an old custom TS and a new custom TS and the only difference between them is the OS image file used and the TS ID. So I would have to delete the old one. I would rather have a way to just change the OS Image in the existing TS and increment the version number of the TS. This would let me keep the TS IDs the same every time for the custom TS, which simplifies my scripting a lot.

    Thank you,

    Darren

    Thursday, December 18, 2014 8:57 PM
  • Hi Darren,

    If I understand correctly, you can use the same name for the captured WIM file? Then you can just copy it to the operating systems and it will be picked up by your TS.

    I've found this thread on the forums that probably has your solution in it.

    From that thread:

    --------------------------

    I now capture to the Captures folder and name the WIM file after the task sequence ID. So for example, my "Update Windows 8 General Purpose" task sequence with ID "8_GP" now creates "\\server\DeploymentShare$\Captures\8_GP.wim"

    In the Scripts folder on the deployment share I created "Relocate.cmd" with the following contents:

    MOVE /Y "%DEPLOYDRIVE%\Captures\%1.wim" "%DEPLOYDRIVE%\Operating Systems\%1"
    And finally, I added a step at the end of my task sequences that runs this custom command (no Start in value defined):
    cmd /c %SCRIPTROOT%\relocate.cmd %TaskSequenceID%

    This works great and MDT does in fact recognize the changed .wim file in Operating Systems and copies it to linked deployment shares, so no worries there.

    -------------

    Hope this helps.

    • Marked as answer by dlofstedt Monday, December 22, 2014 8:14 PM
    Friday, December 19, 2014 10:46 AM
  • Thanks Leon,

    That makes total sense. I am currently using a different wim file name every time, but I can change that.

    Regards,

    Darren

    Monday, December 22, 2014 8:14 PM
  • Copying a captured wim file on top of a "regular" wim file should work in some scenarios, be aware if the Operating System contains multiple "SKU's" like Server, or some retail builds. Enterprise shoudl be OK.

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, December 23, 2014 4:56 AM
  • Sorry to bump an old thread. I noticed one small issue with overwriting the wim file in the MDT operating systems folder. The properties that MDT has for that operating system are not updated. That information is only populated when MDT reads the wim file metadata during the import.

    I noticed this when trying to check what Windows 10 Build was currently on MDT and noticed the build number in the Operating System properties was different than what was being deployed.

    If I had to do this again I would script it so that the Operating System was deleted/imported and the task sequence was deleted/imported every time. However, overwriting the wim file is much easier and I am still satisfied with that solution.

    ~ Darren

    Thursday, April 21, 2016 7:10 AM