none
Life of task sequence variables, including custom ones MDT 2012 upd 1 RRS feed

  • Question

  • I am trying to get my head around the use and lifetime of task sequence variables, particularly OSDComputername and a couple of custom ones.  These seem to be arbitrarily available or not, and I cannot seem to locate a definitive answer.  This article was suggested as a possible topic, but does not seem to address this issue in the context of MDT--I cannot find an option to "disable 64 bit redirection."

    I am building a custom 64 bit Win 7 image in a 64 bit environment on a 64 bit VM.

    In CS.ini, I set OSDComputername to a suggested name, providing most of the text to which I add a sequential number in the wizard.  The wizard sets (overrides) the initial computer name as expected.  I use two custom properties, declared in CS.ini, named mdtUserName and ModelAlias.  The former is based on OSDComputername and is the basis for creating a user account in the last steps of the TS.  The latter is used to rationalize %model%, which is munged on Lenovo laptops, in order to manage driver selection.

    In searching for answers it has been suggested in several articles that TS variables should last through the lifetime of the deployment, and I thought that by explicit declaration in the Properties section of CS.ini this would certainly be true.  The log reflects the fact that these are added as new custom properties.  So far I have not tested ModelAlias, but mdtUserName certainly does not persist; its value is empty when accessed in a later TS step.  It is also suggested that modifying TS variables in a TS step would produce results only for that step or phase, depending on who wrote the article.  My question is, how do I set a custom property, or TS variable, so that its value persists throughout the TS?  Or should I be setting it immediately before use?

    Using a standard TS template, I set my variables in two separate scripts as the first two steps of the Preinstall group.  Within the ztiutility wrapper template, this is my workhorse code (for mdtUserName):

        oEnvironment.Item("OSDComputerName")=lcase(oEnvironment.Item("OSDComputerName"))
        oEnvironment.Item("mdtUserName")=mid(oEnvironment.Item("OSDComputerName"),6)

    For ModelAlias, I use the script from this article as the basis.  I have not tested this on real hardware yet, but I have a feeling that this will not work either.  Can anyone shed some light on this?

    Tuesday, April 29, 2014 3:21 PM

Answers

  • Any custom variable defined in the cs.ini file *should* be available through the end of the MDT lifecycle, including State Restore.

    You can always check variables.dat to confirm that the variable is defined, if so, then check your code to ensure you are reading it correctly.


    Keith Garner - keithga.wordpress.com

    • Marked as answer by BigPurpleDick Wednesday, April 30, 2014 10:05 PM
    Wednesday, April 30, 2014 4:08 PM
    Moderator

All replies

  • To answer your question, the value of a properties lasts the lifecycle of the task sequence. Now to cover your issue, are you sure that a value is actually being set to mdtUserName? Where is your script running from? Are you declaring your the property in your customsettings.ini file?

    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, April 30, 2014 2:32 AM
  • You might want to refer to your customsettings.ini at each gather step that you can find in your task sequence. This forces MDT to look at the cs.ini again and again.

    Perhaps this solves the issue you have.


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, April 30, 2014 9:13 AM
  • To answer your question, the value of a properties lasts the lifecycle of the task sequence. Now to cover your issue, are you sure that a value is actually being set to mdtUserName? Where is your script running from? Are you declaring your the property in your customsettings.ini file?

    "I use two custom properties, declared in CS.ini, named mdtUserName and ModelAlias."

    "Using a standard TS template, I set my variables in two separate scripts as the first two steps of the Preinstall group."

    The log shows that mdtUserName is set correctly.

    I attempt to reference mdtUserName in a script as the last step of Custom Tasks in State Restore.  There are errors in the log that says the property is empty.

    I am rebuilding my image for other reasons and will try this again so I have fresh logs.  I'll add some debugging statements to my scripts.

    Wednesday, April 30, 2014 3:52 PM
  • You might want to refer to your customsettings.ini at each gather step that you can find in your task sequence. This forces MDT to look at the cs.ini again and again.


    I considered this, but I'm afraid that if I do this, my OSDComputername will be overwritten with my standard value, rather than keeping the one captured in the Wizard.
    Wednesday, April 30, 2014 3:54 PM
  • Any custom variable defined in the cs.ini file *should* be available through the end of the MDT lifecycle, including State Restore.

    You can always check variables.dat to confirm that the variable is defined, if so, then check your code to ensure you are reading it correctly.


    Keith Garner - keithga.wordpress.com

    • Marked as answer by BigPurpleDick Wednesday, April 30, 2014 10:05 PM
    Wednesday, April 30, 2014 4:08 PM
    Moderator
  • Long story short, the task sequence variables do survive through the TS as expected.

    One thing that made me question the TS variable list is that the VARIABLES.DAT file left after the failed deployment (but before clicking on Finish) does not contain my custom ones or OSDComputername.

    Also, I did have a couple of coding errors and once I fixed those, my deployment went through to the end, working as intended.

    Thanks for taking a look and your advice, Keith.  I'm giving you the answer credit.



    • Edited by BigPurpleDick Wednesday, April 30, 2014 10:25 PM Clarification
    Wednesday, April 30, 2014 10:01 PM