‘Dynamic’ Settings per Task Sequence in MDT 2010 through Coding

*Update (Oct 2011) – Added known bug and workaround that is fairly important to know about (having code for applicationsXXX and then deselecting all through UI will not actually deselect)*

When using MDT 2010 through the LiteTouch deployment wizard, it can prove to be a pain when you remember how much you wish you could set values depending on what the user has clicked. This was one of the things that bothered me to no end. I have looked around, but there wasn’t quite the answer I was looking for.

First off, know that there are few things to clarify first. There are already well documented solutions for deployments on how to do this. Johan Arwidmark has  good article on this. The downside is this will not work on the wizard, as all ‘value sections’ are calculated ONLY when the wizard is first started. Secondly, there is a hack you may want to try, after a brief look, it looks simpler to implement which is a plus, however redoes the entire initialization. Not a bad approach, but I figured I could attempt to make it run without the redundancy. So far my code has held up through initial tests so I’m posting what I have so far here.

An Overview of How this Works

[Settings]
Priority=DynamicID, Default
Properties=DynamicTasks

[DynamicID]
DynamicTasks=WIN7_001,INSTALLPROGS

[Dynamic_INSTALLPROGS]
AreaCode=520
Applications1={2ef19b8a-b3c3-438a-91d6-b1162c2856ae}
Applications2={ed925194-4233-4029-a4f6-d9e2162d27a1}

[Dynamic_WIN7_001]
AreaCode=614

1. First the code grabs the info from [DynamicID] as it would normally do, as it is treated like any other section provided in the Priority property.
2. When parsing [DynamicID] the code would normally treat this as a literal value. However, my code will come into action when it detects a section named ‘DynamicID’. I hook into the code when this happens and it will look into DynamicTasks a special way.
3. It runs through DynamicTasks, and will parse the values separated by commas.
4. It then looks for sections Prefixed ‘Dynamic_’ that end with the above value. If found, it works through any properties, and keeps them in a pending list. After the prefix, I list the names of two task sequence IDs (INSTALLPROGS, and WIN7_001). The suffix, being the sequence ID, is what is used to determine which tasks to assign the new values to.
5. Once the code senses TaskSequenceID changing, it checks to see if there are any variables bound to the ID, and overrides the original values.

Do note, unlike default behavior where some variables are set in stone upon first write, the custom code will force the value regardless. For variables in the form of lists (such as Applications1, Applications2, etc) that are being overridden, the entire array is wiped out, and set again — this is by design. So do not try to only have ‘Application9’ only thinking it will adjust just a single item. I believe at this time this behavior is the best of choices.

The Code Needed

ZTIGather.wsf (v1.0) (difference from MDT original)
ZTIUtility.vbs (v1.1 June 7 2011) (difference from MDT original)

Previous Versions:

ZTIUtility.vbs (v1.0) (difference from original)

The code contains modifications to two files within the MDT Scripts folder. One being ZTIGather.wsf and the other ZTIUtility.vbs. Any code changes I applied were surrounded with a comment beginning with MM: Mike Morawski. I would post the code inline here however it is a good sized page and has multiple insertion points (even though the code is in three general locations).

Be sure to update any boot images/CD’s being used (these files are pushed there when creating media!). The only case where a rebuild is not needed is if people are running litetouch via the network.

Known Bugs

• Not so much a bug, just hasn’t been implemented: After selecting a task and defaults are overridden, if the back button is pressed, the defaults don’t come back. This can be worked around for now by declaring any values that may not come back in every grouping in customsettings.ini. Implementing this shouldn’t be hard at all if there is demand for such behavior.
• (10/24/11) Deselecting ALL applications will not cause the Applications variable to be cleared the way the MDT code works (if it sees nothing selected, it leaves the variable alone, instead of clearing it out) if some apps were selected through code. Easy way around this is to create an invisible application that does nothing so something is always within the Applications variable. I found this workaround very easy so I left it like that rather than adjusting the code at this point in time.

Updates

• (3/21/2011) – Added code. Added bug section.
• (6/7/2011) – Code update to fix bug. Bug: Values would be changed properly according to task, however in task sequences with multiple gathers, if dynamic values were changed in wizard, they would go back to the dynamic values set in customsettings.ini. See Code section below for update. Version 1.1 uploaded.
• (10/24/11) – Added known bug for ApplicationsXXX and simple workaround.