Advertising a Task Sequence to a User
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.
6 Comments »
Leave a Reply
-
Recent Visitors
Subscribe
Recent Comments
-
The Realm of the Verbal Processor 
We’ve been doing this by using last logged on or top user reverse queries to give us the computer name. Put the user in an AD Security (or mail-enabled security) group, use a query-based collection with the preset advertisement, and after AD Discovery, it finds the user’s computer, puts in in the collection, and deployment happens–we have mail-enabled groups for most of our specialized groups of employees, so, using that method, it’s easy to deploy something to “all accountants”, for instance–without having to know WHICH computer a specific accountant uses. Issue is, you have to wait on the Discovery (daily, for us). Also, whatever method is used to bring in the computer, I’m also trying to figure out a way that, upon successful install, the computer is automatically removed from the collection. We’ve also looked at giving our Help Desk limited SCCM console rights to do direct membership additions.
I’m wondering though (in our enviroment, while HW inventory is daily, SW is only allowed weekly) if DCM might be a better way to do this. Setup a DCM-based method to look for a file or something, the presence of which triggers the install (then the tail-end of the TS will need to delete the file or something). A specific folder on each computer could be setup for DCM to look at, then, if something is desired to be installed, the Help Desk can run a script to drop off a named file into the folder, which is then picked up by DCM.
[…] After some investigating online I found a couple of different ways of doing this ranging from using a forced advertisement that copies an anonymous EXE file to the users computer and then have a…, to the way I’m going to show […]
Pingback by Targeting computers based on user group memberships | intrntpirate | August 25, 2010
What I did in our environment is to use the ManagedBy field to add computers to AD groups and deploy to their *primary* computer. This is limited to environments where users don’t have multiple computers, but it works fine and is direct, as long as you have the proper AD field properly configured when the computer is installed.
see below for more info and examples
http://brpo.spaces.live.com/blog/cns!25A2E9EE5C828DD6!125.entry
brgds
bruno
Getting user discovery data then doing a subeselect query with user resource (logon) in system resource (logon). you can easily populate applications to specific machines this way. Our users are only in a collection if A . their name is in an allow group – B . they dont have the application in their add/remove – therefore once they do have the application and the inverntory is taken the following day they fall out the collection and are then not advertised the program. The only issue we have is if users use a spare machine and install specific software on it. However to combat that we have another collection to say if a user is not in the Allow (specific app) group and does have x in add/remove then populate. rather than force an uninstall we monitor that manually just incase.
What I’m considering is:
– Advertise authorization packages via AD user groups. These are standard SCCM packages that will place a flag on the system.
– Advertise the optional Win7 task sequences to all Win7 systems. The ones that don’t go to everyone will check the flag.
This system will require the user to first authorize if necessary and then launch the program.
Jim Riekse
Just thought I’d share how I am doing this…
I am using a custom webservice to manipulate sccm actions (like the maik koster webservice). I advertise a .wsf script to a collection of our helpdesk users, which does the following: gets name of local machine, adds that computer name to a collection that has our task sequences advertised, then refresh machine policies on the local computer… this is assigned at logon (so it runs wherever a helpdesk tech logs in). within a few minutes, they will get the TS advert popup and can refresh the computer if they want, or they can ignore it and go about their business. I then advertise another .wsf to the collection of helpdesk users which removes the local computer from the TS collection, and refreshes local machine policies… this is assigned at logoff, so within a few minutes of the helpdesk tech logging off of the computer, the TS is no longer advertised… so no normal user can accidentily reimage their machine :)