This post is just a slightly different spin on the typical "how-to" article concept, and comes with a slight twist: I'm not giving the code away. I find it more fun to follow a treasure map and find the goodies at the end. So I will guide you through the process and you can connect the dots. If you're half-way decent at scripting and know how to make a table in a database you should be fine. If not, there are plenty of web sites you can scour to get help.
It's sleeting and snowing outside today and will continue through the night. Yesterday, it was 68 F and I was on a bike ride in shorts and a t-shirt. I still have a light sunburn to remind me it wasn't a dream. After a glass of wine I'm ready to get all verbose on yo ass, so you've been warned. Enjoy. :)
Since most of Configuration Manager is accessible, and manageable, from "under-the-hood" using command-line and API features, it makes it really nice to build a "kit" to suit your own needs. This is just one such "kit". Apologies for the "icky-looking" formatting, but Google seems to have put Blogger on hold while it focuses on Drive updates. Hopefully they'll come around to improving Blogger editing tools soon.
The GoalTo be able to run a Configuration Manager Advertisement on a remote computer at-will, using a web browser as the interface. This makes it possible access and use the capability from anywhere you have access to a web browser and sufficient permissions to invoke the process. More on that last part later. The benefits are slim, but include not having to install anything on any computer where you wish to leverage this feature. You can remote in from home and use it. Open it on your phone or tablet, and use it, and so on.
- System Center Configuration Manager 2007 or 2012
- An Active Directory environment
- A computer running Windows 7, 8.x, Server 2008 R2 or Server 2012 (or higher)
- A database (preferably SQL Server, but SQL Express will just fine)
- A little scripting
- A little time and coffee
The way a "re-run" request works is actually a bit odd, but it makes senses once you think it through. Basically, an Advertisement has properties you can configure regarding re-run behavior, but they can be overridden in certain situations. In short, you capture the current "rerunBehavior" setting, replace it with "always" (as in always let it be re-run), run it again, and then set it back to the original setting.
This requires you to have an account within the SCCM environment (site) that allows you to create and/or modify Advertisements and their settings. If not, stop right here and take care of that or switch into a lab environment where you have more control over things. Actually, I should say here: Do this in a lab or "non-production" environment before you try it in the real production environment. Okay, back to the cooking show...
The Building Blocks - Part 1: The Database Side
- Create a new Database and create a Table inside of it. I chose the name "SCCMTools" for the database name, and "ClientActions" for the table name. If you already have a database to play with (hopefully SQL Server or SQL Server Express), you can simply add a new table (see step 2)
- The Table should have some basic fields. I've suggested a few below:
- ID (to identify the unique row. I prefer making this an Integer value, and assigning it as the primary key and also making it a Identity(1,1) setting, akin to the old MS-Access "autonumber" fields. This should be NOT NULL of course)
- ComputerName (to identify the computer on which the advertisement will be launched. This can be a Varchar or nVarchar data type, but only has to be as long as your longest client computer name. Generally, the default of 50 is fine. This should be NOT NULL)
- AdvID (to identify the Configuration Manager Advertisement ID. This can also be a Varchar or nVarchar value and should be NOT NULL. The length is always going to be less than 12 chars due to the format of Site Code + 5 chars = 8 but you never know)
- DateAdded (to record when you submitted the request. This should be a SmallDateTime value, but that's up to you. NOT NULL also)
- AddedBy (to record who added it; in case you share this with others. In most cases this will contain a user account name (aka sAMAccountName value). This is an optional field, but should be Varchar or nVarchar and NOT NULL if you're going to use it at all).
- ResultCode (to record the exit code or result value from your attempt to re-run the Advertisement on each computer. This should be NULL and could be an Integer value).
- DateProcessed (to record when the request was actually completed. Since this won't contain a value until the request is processed, this can be left as a NULL column)
As a sample, assuming your SCCM Site code is "ABC" and the remote computer which has already run a given advertisement is named "12345DT", your table row might look like this:
DateAdded: 2014-03-03 20:07:01AddedBy: dstein
DateAdded: 2014-03-03 20:07:01AddedBy: dstein
Part 2 - The Electric Web Side Boogaloo
This is where you put some rubber to the electronic pavement. You can build this with whatever web platform/language/toolkit you prefer. The only basic needs are that it must support interfacing with the database and the Configuration Manager site Management Point server via WMI/SWBEM scripting. If you are comfortable with .NET and use the framework tools to connect and interact that, have a blast. It doesn't matter as long as it works for you.
I would recommend Visual Studio Web Express, or Visual Studio (full-blown) if you have access to it. However, if Java, PHP or Ruby is your thing, go for it.
The web code is simple and all it really needs to provide is few files/pages as follows:
- A "home" page of some sort (so you can put a picture of your cat or dog and a spiffy looking logo thing), and include links to...
- A list / table report that shows current table entries. This is important to see what has already been completed and what is still waiting to be run.
- A "new request" form for submitting, well, a new request. It should include a box (or even better: a drop-down list) to specify the target computer (or computers), as well as a box (or still even more better: a drop-down list) to specify the Advertisement to re-run on the selected computer(s).
- Optional pages/files for inserting the request records, or deleting pending requests (which haven't yet been processed, obviously).
- Feel free to go nuts. Maybe add files to truncate or clear table entries, batch update rows, etc. It's your baby, raise however you want.
Part 3 - The 12-Cylinder Engine with NOS
Okay, that's a little excessive, but this is really where it all "happens".
This is actually a combination of two things: A script that performs the actual operation, and a scheduled task the repeatedly checks the database for pending requests, and then runs those pending requests through the script process. The actual process is as follows, and it's not complicated, trust me:
- Query the database table for rows, using something like "Select * from ClientActions WHERE DateProcessed IS NULL".
- Loop through the recordset (do-while or do-until, etc.), and for each record grab the "ComputerName" and "AdvID" values.
- Pass those two values to the script, and run that script under a context which has access into both the SCCM site and the remote client desktop. It needs local admin rights (or something suitable enough to allow it to invoke COM operations remotely) and that means you may need to tinker with firewall stuff, but you already knew that, right? Mmmhmmm. Okay.
- The script connects to the remote client computer, does it's thing, and if the exit code (return/result value) is 0 (zero, or "success", etc.) update the matching table row to enter the current Date/Time into the "DateProcessed" column.
- Capturing the exit or result code is very important. This is why I suggested the ResultCode" column earlier. It allows you to capture the successes and failures as well. If you just have a "DateProcessed" value, you can't really distinguish successes from failures.
If you need some pointers for making the script processor part, here are just a few links that I found by entering "re-run SCCM advertisement script" in a Google or Bing search:
- Need more?
Baking Time - 2 - 4 Hours
Okay, sooner if your brain is a microwave and you've consumed some caffeine.
Fetch a computer from your SCCM environment and get a list of the Advertisements it has already run. Identify one of the Advertisements which can be re-run on it without causing any harm to the computer. You might want to make a fake or shell package that just runs a script to create a log file on the client. Something to demonstrate it was run once and that will leave a trace when it's run again afterwards.
Using the computer name and the Advertisement ID value, enter that information into your database table using your web form. It's okay if you just directly edit the table using something like SQL Server Management Studio, or the database tools in Visual Studio. It's just nice to test it all together if you can.
Place the script in a folder on a computer where you intend to host it for future use. Use that computer to configure the scheduled task, along with the credentials to run the script itself, and save it.
Run the scheduled task. This will help you verify the following:
- The script can connect to the database and obtain records
- The script can connect to the remote client computer
- The script can modify the Advertisement properties for re-run behavior
- The script can invoke the SCCM client agent actions to re-run the Advertisement
- The script can update the matching rows in the database table to indicate completion
- The script can do all of this under the security context by which the task scheduler is invoking it
Now, it's time for a desert. Post a comment to let me know how this works out for you?