Coalesce noncontinuous and/or unjoined lists into a single sequential variable list in ConfigMgr OSD Deployments
Wow, great title. What does it mean?
Well, yesterday I was watching a couple of the recorded sessions of last weeks MMS. One of them was held by Michael Niehaus about dynamic Deployments and he mentioned a problem you might experience mainly in ConfigMgr OSD using collection variables and presented a solution in form of a script that exists already in MDT. As I wasn’t able to find much information about this I try to summarize this in case somebody else not being able to attend his session runs into this problem. So the idea, content and solution has mainly been “stolen” from Michael 😉
MDT (and OSD as well) are able to use lists for certain tasks like installing applications or packages. But these lists are handled in a slightly specific way. MDT/OSD expect each entry of the list in the format ListNameXXX while ListName is the name of the list itself and XXX is a three digit number starting at 001 and need to continuously increment by 1 (e.g. PACKAGES001, PACKAGES002, PACKAGES003,…). If there is a gap between two entries (e.g. PACKAGES001, PACKAGES002, PACKAGES004,…) it would stop iterating the list at that point.
The Problem
Let’s assume you are configuring what packages shall be installed during the Deployment by using Computer-/Collectionvariables. That might be easy if you have just one collection you use for this, but can become really tricky if you have several collections where computers can have different combinations of membership to these collections. How can you make sure that you don’t have any duplicates or gaps and still have a valid list of all packages you would like to install?
The Solution
There is a small script in MDT called ZTICoalesce.wsf that is able to take such a “list” and create a new list out of it with sequential entries following the mentioned schema. And even more it can also coalesce several lists into one single list.
The script is using a pattern to identify the lists it shall use. This can be a simple pattern like a part of the name or even a more complex regular expression pattern. As it’s main usage is to fix problems when installing packages it is using the pattern “Packages” as default and would so coalesce all lists that contain the pattern “Packages” (except one with the exact same name as the pattern) into the list “PACKAGES”. You can configure the pattern and the Target List by setting the properties “CoalescePattern” and “CoalesceTarget” before you execute the script.
With this in mind, we can go ahead and can be more creative when adding such variables. We could even create a “list” per collection so we can make sure these are unique and sequential (well, actually they don’t even need to be sequential). We just need to make sure we have a common identifier as part of the name (stick to something with “packages” to keep it simple) and then during the Deployment we just call the ZTICoalesce.wsf script to join all these lists into a single sequential variable list that can be used by the “Install Software” step.
As a short example, we assume we have two collections. “CollectionA” has the following Collection variables assigned
12 CollectionA_Packages=XYZ00001:ProgramACollectionA_Packages=XYZ00003:ProgramB
and “CollectionB” has
123 CollectionB_Packages=XYZ00005:ProgramCCollectionB_Packages=XYZ00006:ProgramDCollectionB_Packages=XYZ00007:ProgramE
Now we call “ZTICoalesce.wsf” and it creates us a nice list of
12345 PACKAGES001=XYZ00001:ProgramAPACKAGES002=XYZ00003:ProgramBPACKAGES003=XYZ00005:ProgramCPACKAGES004=XYZ00006:ProgramDPACKAGES005=XYZ00007:ProgramE
that can easily be consumed by the “Install Software” step.
Another interesting part here is, that MDT is making it’s own variables visible in the SCCM Task Sequence environment. So you would even be able to coalesce “lists” from MDT with “lists” from SCCM. It becomes a bit tricky if you need to ensure a certain order of the lists themselves as it is just iterating through all items of the SCCM Task Sequence environment. But some testing led me to the assumption that it is ordered alphabetically.
Recent Comments