Finding the unfindable – Automate the “Run” click in dpjobmgr

So… while I was waiting for a friend this morning for a hangout session, I was thinking of all the pain that content distribution has given me. I have looked all over the place for a way to actually start dp jobs via powershell/wmi however no one seems to have documented a method at all (at least I can’t seem to find one online) so decided to jump on to find a way to script running of jobs via dp job manager myself. If you have a look at dp job manager you can see that when you right click on a job and select run, It appears to trigger job execution by modifying WMI properties rather than invoking a dedicated method which is interesting and a little unexpected.  

 Basically when you right click a job and select run, it modifies properties of the distribution job behind the scenes.
What it looks like it does is:
ReStartTime is set to a date in the past which signals that the job is eligible to be picked up again.
DynamicOrder is updated to a low number (like 1), pushing the job to the top of the queue.
These changes are made via WMI calls to the SMS_DistributionJob class. Once updated, the PkgXferMgr component on the site server detects the job as ready and begins processing it — effectively “running” it.
So the Run action is really just a way of reprioritizing and reactivating a queued job using WMI.

After figuring this out, I decided to try something out.
If you grab the job, set the restart time ad dynamic order, it should kick off the jobs immediately. 

Do I have to keep saying this? DON’T RUN SCRIPTS IN PRODUCTION ENVIRONMENTS, ESPECIALLY FROM SOME RANDOM PERSON ONLINE. TRUST YOUR OWN RESEARCH AND TEST IN TEST!!!!! IF YOU DON’T KNOW WHAT YOUR SITE CODE IS, YOU PROBABLY SHOULDN’T BE TOUCHING ANY OF THIS! THIS IS GOING AGAINST HOW MS WANT YOU TO DO THINGS! USE THE TOOL HOW IT SHOULD BE USED! I AM A STRANGER ON THE INTERNET AND I LIKE PLAYING WITH MY OWN TOYS TO FIND HOW IT WORKS BEFORE DOING ANYTHING POTENTIALLY DAMAGING!!! THERE MAY BE UNINTENDED CONSEQUENCES AS I AM JUST PLAYING AROUND WITH THINGS!!! Backing up before making changes is always advised, this is not endorsed by Microsoft at all.

Now that I have that out of the way:

$sitecode = "YourSiteCode" $namespace = "root\SMS\site_$sitecode" $distributionpoint = "YourDPNameHere" $jobs = get-WmiObject -Namespace $namespace -Query "SELECT * FROM SMS_DistributionJob WHERE NalPath LIKE '%$distributionpoint%'" foreach($job in $jobs){     $job.ReStartTime = [System.Management.ManagementDateTimeConverter]::ToDmtfDateTime((Get-Date).AddDays(-2))     $job.DynamicOrder = 1  # Or whatever order you want     $job.Put() }

Now lets see….. YES! Success! The highlighted jobs are all jobs for a specific distribution point.

What this means for us:

We can now look at automating the start of jobs for source dp’s to push content through faster and we have a way to trigger jobs at will without waiting for the job manager.

You can play around with WMI filters to target exactly what you want.

(Yes, I tested running it in test first)

Given it goes off of restart timer and dynamic order, we can also do some magical things around reorganising what jobs run so we can smack out small jobs first and such. Wouldn’t be hard to add some queries in to grab size and such.

lets see……. another cheesy goodbye line: Until next time. May your jobs run fast and your logs stay clean 🙂