Monday, 19 November 2012

Using MDT Monitoring with Config Manager Task Sequences - PART 2


Been a long while inbetween posts - had some study (MS Private Cloud) and been a bit busy with work. But - here is some additional information around using MDT Monitoring with Configuration Manager.
Part one works fine, until the machine is restarted, then the monitoring will effectively halt.
What I wanted to do, is instead of having an additional Task Sequence step after every reboot, have a task that will run on system startup. That way every reboot will restart the monitoring.
My ideal situation was as below :
  • use startnet.cmd in winpe to start the monitoring
  • use an async command in the unattend.xml to run schtasks to create a scheduled task
  • use task sequence step to clean up the scheduled task
However, I ran into all kinds of problems.
Firstly, no matter what I attempted I could not get the monitoring script to run (and function as expected) running from WinPE using startnet.cmd. The script would start, the logging would identify that a step had changed, but the webservice would not fire an event. Now, normally i would work around this and modify the monitoring script to just call the event service with the relevant parameters. BUT - I wanted this to be as much 'out of the box' as possible, no super tweaks or hacks to how the MDT monitoring works.
So instead, I remained with a TS step that runs initially to start the monitoring (As per part 1). This works like a charm.

The second issue I had was actually setting up a scheduled task.
I tried using setupcomplete.cmd - but what I didnt know was that this gets created with a commandline to run the OSD TS. So my change would continuously get overwritten. (But hey, at least I learnt something!)
Secondly i tried adding the relevant command to unattend.xml. However, this would never create the scheduled task. Unsure why exactly, and to be honest I didnt trouble myself too much over it. (PS If anyone has gotten this to work, certainly let me know via the comments!)
So, what else? Well I went with the tried and true TS step. I added an additional step after the Setup Windows and Config Mgr step in my task sequence, that would run the below script to set up the task :

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("Wscript.Shell")
if not objFSO.FolderExists("C:\Windows\Setup\Scripts") then
 objFSO.CreateFolder "C:\Windows\Setup\Scripts"
end if
path = objFSO.GetParentFolderName(Wscript.ScriptFullName)
objFSO.COpyFile path &"\*.*", "C:\Windows\Setup\Scripts\" , TRUE
strTaskName = "Monitor"
strCommandLine = "C:\Windows\Setup\Scripts\ZTIMonitor.wsf"
wshShell.Run "schtasks /create /tn " & strTaskName & " /tr " & strCommandLine & " /sc onstart /RU SYSTEM" , 1 ,TRUE

WshShell.Run "cmd /c " & """START wscript C:\Windows\Setup\Scripts\ZTIMonitor.wsf""" ,1 

I DO realise that I was a little over zealous with the script copying (really only need ZTIGather, ZTIUtility, ZTIDataAccess and the ZTIMonitor script created in part one) You can also add a line in there to re-enable the DaRT remote control executable as well, to fire up your remote control again.

This set up a scheduled task, on system startup to run the ZTIMonitor.

Elegant? Not at all.
Functional? Yeah, pretty much!

The last thing remaining is to remove the "Monitor" Scheduled task at the end of the TS. Another TS Step (run command line) will do this.

Just to spell it out further here, im not giving anyone a complete end to end solution here - its more showing you what I have done, and giving people some ideas that perhaps they might not have thought of on their own. Think of it as us collaborating on an idea :)

So in conclusion I got the MDT monitoring system to work with a Config Mgr task sequence, with 3 extra TS Steps. I'm happy about that. Now next plan, is to actually make it useful!
Future posts will describe my attempts to use this monitoring service to write events to a DB and monitor using a simple ASP.NET page.

Friday, 2 November 2012

Using MDT Monitoring with Config Manager Task Sequences - PART 1

Wow, first post!

So, im not going to muck around with hellos, introductions etc etc. Lets get straight into it!

I've been pretty interested in MDT 2012s new monitoring feature, pretty useful feature straight out of the box. However, seems that this will only provide information on MDT Task Sequence steps. Great if you are solely using MDT for your deployments, not so useful if you are using MDT integrated with ConfigMgr, and your own custom ConfigMgr task sequences.
I wanted to find a way to monitor a Config Manager task sequence using the MDT monitoring web service, with no modifications whatsoever.

First of all, there is one big negative point with MDT monitoring, that is the fact that its not historical. It will tell you where your deployments are at at that point in time, but information around the past events isnt retained. In my opinion, this makes using it as your OSD monitoring solution a little flawed. Generally you will want historical info, the full picture of your OSDs as it were.

For this post I am going to go over how I got the MDT monitoring working for Config Manager task sequences. Future posts will describe how to use this process to get the info into your own monitoring solution.

So - Lets begin...

If you do not know how the MDT monitoring feature works, i would STRONGLY recommend you check out the MDT Monitoring Deep Dives by OSD guru Maik Koster.
Also check out MDT Monitoring Info
Troubleshooting MDT Monitoring both by MDT Master Michael Niehaus.

Done your background reading? Great!

SCCM Task sequences are not aware of the MDT monitoring service, meaning that every step being run is not actually communicating to the web service. That makes sense. The challenge is, how to monitor a running task sequence and pass info back to MDT?

The easiest way (IMO -if you see something easier definitely let me know via the comments) that I could see to do this was to monitor the current task sequence step. Every time the TS step changes, fire an event to the web service.
I did this by monitoring the  _SMSTSNextInstructionPointer TS variable. This contains a pointer to the current step. When the value of this changes, I fire off an event. See below for the script.


So essentially what we are doing here is :
  • Creating a GUID (unique identifier required to track a job)
  • Specifying the MDT event service name (this might not be needed if you have this in your customsettings.ini)
  • Comparing the value of _SMSTSNextInstructionPointer to its last value. If its different, running the CreateEvent method from ZTIUtility.vbs
  • Looping FOREVER...(or at least until a reboot :) )

There are a couple of things to be aware of here..

At present, a Toolkit Package/Gather needs to be run ahead of the monitoring starting. I am working on a way to get this running from step 1, will update this when that work is complete)
Everytime a reboot occurs, the monitoring needs to be restarted. (Again, i'm trying to find a way to autostart this to make it a bit more resilient)

The instructions for getting this working are below:
  1. Save above script (place this in the Scripts folder of your MDT package. Im using the name "ZTIMonitor.wsf"
  2. Edit your existing task sequence - place a new run command line step below your Use Toolkit/ Gather steps.
  3. The command line to run is : cmd /c START %scriptroot%\ZTIMonitor.wsf
  4. Copy this step to run after every reboot your TS performs.
  5. Save your TS
  6. Run an OSD, and you should see your monitoring events appearing in MDT Deployment Workbench once the monitoring step is hit.

This works very well for my test lab - usual stuff applies here about testing this yourself, i'm not responsible for any data loss , yadda yadda yadda. The blog name isn't poorlycoded for nothing ;) Please drop me a line if you want more info or things arent working as expected.

Thanks for reading!