I thought i'd write up a quicky blog post on using the ConfigMgr Task Sequence to deploy Software Packages, and reveal select parts of the functionality available to you to accomplish the task.
Open up your ConfigMgr console, navigate to the Operating System Deployment node and right click "Task Sequences"
1. Select “Create a new custom task sequence”
2. Give it a name
3. Don’t choose a boot package
4. Bring the new Task Sequence up in the Task Sequence Editor
Here we go, useful options available to you are:
Run Command Line
Connect to Network Folder
The other categories deal with Disks, User State, Images, Drivers and Settings and most are OSD specific and not much use when deploying Software.
So, those three commands under the General category don’t seem much do they? But these puppies give you a lot of control and ability over your package execution.
Here’s a breakdown of the abilities each of these commands gives you:
Run Command Line
Command line can contain NT BATCH statements, but is a bit limited in that the script has to sit on one line. Easy enough if you can use | and &/&&, and other command line tricks to achieve the end result. It can be an executable, a script or any extension that has an association mapped to an application on the client.
“Start in” is an absolute path to the file system on the client, or relative to the Distribution Point.
Cough, that just gave the game away. Yes, relative to the Distribution Point, meaning you can run scripts that reside in a package that is assigned to a Distribution Point. This is powerful in itself. You could have a “Management Scripts” package and just load it up with scripts\executables et al, and you can now invoke any of these tools from your toolkit. I’ve worked for many a company that has a stash of scripts and tools on a shared area that are both for engineers and used in deployments. Maybe it’s time to copy these in to a ConfigMgr package.
In Configuration Manager R2 you can specify the credentials that are used to launch the Command Line. That’s something I remember a colleague in a past company complained was missing in the jump from SMS 2.0 to SMS2003 (Token nod to Etienne @ BNP), sure this will make him happy now J
Note: If you want to capture output from a program you need to prefix the command with CMD.EXE /C
Pretty straight-forward, you select an existing Package and Program and execute it as part of the Task Sequence. You can execute multiple applications here, but being stuck in my ways I like to separate out the software installations in to separate steps. Essentially, so I can control error codes per execution, whether a failure is OK or if the Task Sequence should abort (drop out/exit).
Connect to Network Folder
Typical behavior you’d expect from Windows Explorer Map Network Drive function. Provide the Path, choose the Drive letter and supply the credentials to map the connection with.
Now it’s time to add another layer of complexity and thus, control, and introduce the Options tab that is available for all activities in the Task Sequence.
Firstly you can Enable\Disable a step, and as this is all Policy based the switching on and off or even modifying the Task Sequence is done pretty quick as it only depends on a policy update being applied to the MP’s and this replicates quickly.
You also can “Continue on error” which is very handy for hopping over steps that could fail but are not critical to the entire Task Sequence.
The Task Sequence provides you with very limited conditional evaluation methods. You have limited conditional evaluation at hand with the trusty IF statement. Limited in that it meets evaluation criteria based on All, Any or None of the conditions evaluating as positive\negative. No complex IF statements here, but enough control to do some fancy tricks in this space.
The conditions are:
Task Sequence Variable (limited usefulness really)
Operating system Version
Now this certainly isn’t a scripting engine, so I don’t expect much functionality along those lines. But it does give us enough juice to do some interesting things with the installation of a product and its dependencies, even setting up the stage in readiness for the deployment is made simple using the above methods. And once you’ve setup your Task Sequence you can advertise it like you would a Program in a Package to any amount of Clients.
Comparing the Task Sequence as a Software Deployment method with the traditional Software Deployment method, you can see that we now have an additional tool in our toolset for managing these deployments.
Going forward, I’d really like the ConfigMgr Developers to shine some love on this aspect of the product. Make it a bit more robust by allowing me to do string manipulation, let me manipulate data from the output of command lines or existing data repositories (LOG, TXT, CSV, etc). Allow me to query WMI\File System\Registry etc and put that data in to a string that I can evaluate on, rather than defining what I expect to see then evaluating it for positive\false.
This could become a real monster aspect of the ConfigMgr product, and give the Application deployment teams far more control over the deployment than they already have using the traditional Software Deployment feature.
Grow this area out please Microsoft!
This article was rushed out on a lunch break, it’s really only there to pique your interest and perhaps motivate you in to thinking of using Task Sequences for more than rebuilding OS’s. The amount of SMS administrators I come across, that when I talk about this stuff their eyes light up as if they have figured out how many black holes CERN will introduce to our planet when they switch on the Ring of Death! And hence why I thought I’d take the time out between munching on a sandwich to tap furiously on my keyboard to bring this to you.
Always happy to hear horror\success stories, or anything related to Software Deployments using Task Sequences! So ping me an email or comment on my blog J