Making a ConfigMgr Task Sequence Available to a User Collection

A recently had a requirement to bundle a number of applications together into a few different task sequences to make available to a user collection.  After a bit of research, I discovered that this is a pretty common question, and that there is no built-in method to make this available.  Below, I’ll walk through how I was able to accomplish the task using a the task sequence, an application, and a bit of PowerShell.

First, a huge shout out to Ryan Ephgrave.  I’ve talked about Ryan before in my blog (MMS Day 2, MMS Day 3, MMS Day 4, and Stop Using the Pipeline in PowerShell), and he’s helped me once again with Run a Task Sequence in the App Catalog.  I plagiarized a lot of his process and a bit of his PS to get this working.  Where my requirements differed from Ryan were:

  • I need to be able to re-run a task sequence (as I’m using them for application bundles and not for an OS), so I can’t leave the flag file behind.
  • I need users to be able to re-run a bundle, so I can’t leave the flag file behind forever, but long enough so that ConfigMgr knows it was successful.
  • I need my PowerShell script to be reusable for a number of task sequences, so I don’t want to embed it into the script itself.
  • I need to be able to run multiple bundles, so I needed dynamic flag/log files (else having one would force the others to show installed).
  • I need to deploy based on the task sequence ID and not the deployment ID.

Setting up your Task Sequence

First I need to setup my bundle.  For this example, I’m just installing four applications.  This is setup the exact way any other task sequence is setup.  Here is what one of mine look like:

Next, I deploy this task sequence to any possible computer it could run on, but with a run time that’s far off into the future.  I’ve setup my deployment with the following important criteria:

  • Target collection is All Windows 10 Systems (but since we’re “hiding” it, it won’t actually show on all those systems!).
  • The action is Install and the Purpose is Available (not required!).
  • Most important, the deployment does not become available until 12/30/2033 – the last date allowed by Configuration Manager.
  • I download content only when needed by the running task sequence.

After this is created, you’ll want to get the Package ID for this Task Sequence.  This can be found in the console if you enable it, as I show here:

At this stage, we have a task sequence that’s made available to all Windows 10 systems, but it won’t actually show up for another 15 years.

Setting up the PowerShell Script

Edit: Sept 11, 2018: An earlier version of this post uses the Advertisement ID for the log file name.  The better practice is to use the same Package ID we’re using for everything else – we shouldn’t care how it was deployed, it’s all the same task sequence.

Next up is the PowerShell script, which we’ll then use for our application.  First, the code:

I’d like to share what the non-obvious lines of code here does, if you don’t care, you can feel free to skip this list:

  • Lines 8 – 37 setup a new PowerShell type that we can use to later mark a file as needing to be deleted (or more accurately, “moved to null”).  Credit to The Scripting Guys for this bit of code.
  • Lines 39 through 48 query the CCM_Scheduler_ScheduledMessage class to find the task sequence that we deployed to all Windows 10 systems (based on the Task Sequence ID).  It then changes the active time from 2033 back to a date in the past.
  • Lines 50 – 57 query the CCM_SoftwareDistribution class to change the advertisements ActiveTime, set it to mandatory and to always rerun.
  • Line 59 is used to clear out any old log file from the last time this was run.
  • Lines 61 – 72 triggers the advertisement to run.  If the advertisement doesn’t run, this will fail and will not move on to the following steps.
  • Lines 74 – 76 create a flag file in the Windows directory that we’ll use later so that ConfigMgr knows if the installation was a success.  It then marks the file to be deleted at next boot.

Now, go put this PS1 file in whatever source folder you use for your applications.

Setting up the Application

As our final step, we tie these two things together with an application.  Create an application the same way you normally would.  Key aspects here are:

  • Content location is wherever you’re saving your PS1 file created earlier.
  • Your Installation Program will look like this, where TST0001 is replace with the Package ID you captured earlier.
  • The detection method should be a File search in the path %WINDIR% for TS_TST0001.LOG (where again, TST0001 is replaced with the Package ID of the task sequence).

Other than that, you can set whatever type of requirements you’d like, similar to any other application.  Once this is setup, you can deploy the application to your user collection (a test one first, of course!) and once policy updates the users you deploy to should be able to run the Application from the Software Center.  Once run, the bundle will show “installed” until the user reboots and the log file goes away.  At that time they’ll be able to run it again if necessary.

Other Thoughts

First, if you have a better way of doing this, please let me know in the comments – I’d love to be able to build bundles of applications for certain groups and deploy them, and I don’t want to run through with the hack of stringing applications together with dependencies.  Second, remember that your PS1 is reusable!  When you setup your next task sequence, just create a new application and change out the Package ID (in both the command line and detection script) and you’re ready to rock.

FacebooktwitterredditpinterestlinkedinmailFacebooktwitterredditpinterestlinkedinmail

2 Comments

  1. Hi. I’ve followed the method you detailed but am unable to get it to work. The log file always states the following,

    Exception calling “TriggerSchedule” : “Not found ”
    At C:\WINDOWS\ccmcache\25\ProBook-4X0G3-BIOSUpdate-01-33-R1.ps1:72 char:2
    + [Void]$SMSwmi.TriggerSchedule($ScheduleID)
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WMIMethodException

    The Package ID of the task sequence is correct.

    Reply
    • Hi Dean, have you deployed the task sequence to the system and refreshed the machine policy (or given it enough time to update it on its own)?

      Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.