I had a fun little task this week…do the impossible with ConfigMgr…make a Task Sequence advertisement applicable to a user. Now…Task Sequences were originally designed for Operating System Deployment, and as such they can only be advertised to a computer account…not a user account. But…there are certain applications that we need to install via a Custom Task Sequence. (For example…SQL 2005 Client Tools or Visual Studio 2008. In both cases, the service pack can’t be slipstreamed into the install, so it must be installed separately.)
Now in most instances, I want the service desk to be able to deploy software, but I don’t want to give them access to the ConfigMgr console. One of the easiest ways to accomplish this is by allowing them to modify an AD group for SW deployment. That works well…except that for an app that is installed via a task sequence, they will have to remember to add a computer account (that they will have to hunt down) instead of the user account. I would much prefer that their process is the same for all software…just add the user account. So…here is my criteria:
- App is installed via a Custom Task Sequence
- A task sequence can only be advertised to a computer account
- All software is advertised to collections based on AD user groups
- Want to maintain the same process
How can I accomplish this? Well…let’s separate the two parts of the process and tackle it differently. The two parts are:
- The service desk does (add a user to an AD group)
- The software gets deployed to the computer that the user is logged into.
Let’s come back to #1 and look at #2 first. There isn’t a special setting/switch/etc to make it possible to advertise a task sequence to a user account. That advertisement still has to be targeted at a computer. Now…what are the ways that I can get a computer account into a ConfigMgr collection? There are several:
- Direct membership – with ConfigMgr console access, I can simply add the computer account to the collection.
- Query based – which can be based on any number of things. Common ways of doing this are:
- Subselect query – a query to determine all systems that don’t have the software – then install it.
- AD group/OU/etc membership.
- HW/SW inventory – something in inventory that can be used to trigger the installation.
Now…of those options, we can rule out the direct membership option because I don’t want the service desk to have console access. I can also rule out the subselect, because this is not software that all users should have…it is more specific. I’m also ruling out the AD group membership, because I still want the service desk to only be concerned with adding USER accounts to the AD group. That leaves me with inventory…which gives me options for how to get around my limitation.
What are things that inventory is already grabbing for me…or that I can modify it to grab? I could modify the HW inventory to grab custom registry keys. Or…depending on how I have SW inventory set, I can use it to tell me if certain files exist. By default, all EXEs are inventoried. That is my opening…
What I CAN do is advertise a vbscript to a user or user group. That vbscript does nothing more than create a text file…with an EXE extension that will be picked up by SW inventory. Now…I don’t want to wait for the next inventory cycle, so I can have the vbscript also kick that off for me. So…the script simply writes a file and kicks off inventory.
My task sequence is targeted at a collection that targets computers that have a certain EXE file. This solves my issue. I can now have the service desk add a user to a group. This triggers an advertisement (mandatory and silent) that runs a vbscript that creates an EXE file and triggers the SW inventory. Because the EXE file will then be part of the inventory for the computer account, I can now create another collection/advertisement to target the installation of the software to computers that have the EXE created by the vbscript.
Is it elegant…no. Does it scale…that may be questionable. Does it work…it actually works quite well. Is it fast…not really…but depending on how frequently user and machine policy refresh, I can still get it to the user in a reasonable time frame.