MDT Monitoring Deep Dive IV – Sending more information

In my post MDT Monitoring Deep Dive II – Consuming the data yourself, I showed you how you can write your own web service, that consumes the MDT monitoring information. The next thing we will cover is, how we can send even more information from MDT and also make use of a pretty hidden feature in this monitoring option I blogged about in the last post.

Send additional information

As we have seen in the last couple of posts, MDT will automatically send some information about the current deployment status to a web service. Which it then uses to monitor the deployment. It covers some basic information like the current step and step name, any errors or warnings, current IP address, etc. But what if we would like to receive more information like ServiceTag/AssetTag for some custom identification, the Task Sequence ID it’s currently running, the deployment method or probably some custom property.

Now as we have created a custom web service, it should be a piece of cake. Just add a new parameter to the “PostSettings” method in the web service, and then add this parameter to the web service call in the ZTIUtility.vbs script.

Well, that works, but you would have to redo this, whenever you want to add a new parameter and also whenever you upgrade or install MDT. While it’s generally a bad idea to change the original MDT files, a single change might be worth the effort, but ending up with multiple versions could create some headache. What I’m going to demonstrate now is a more generic way of adding new properties to our Monitoring.

Let’s start with the MDT part first. The idea here is to create a new MDT List property, that holds a list of all additional properties, that shall be included in the web service call. We can then add them on the fly, even dynamically based on other values. On each web service call, MDT just loops through this list and adds an entry for each property.

For reason of simplicity, I call the list “MonitorProperties”. To define them for our deployment, we just add it to our customsettings.ini:

the “(*)” tells MDT, that this custom property shall be treated as a list. Now we can add a couple properties to this new list

So far nothing really fancy. However, we need to make a small change to the ZTIUtility.vbs, otherwise no additional information will be send. In the ZTIUtility.vbs file, we search for the function called “CreateEvent”. In the second part of the function, it’s preparing the web service call (see This post for details). Just after MDT has prepared all its original information but right before it’s sending them, we add the following lines (in MDT 2012 and MDT 2012 Update 1 insert it at line 404)

It should be pretty self-explaining. It just loops through the list of additional properties and for each property, it just adds the name and the configured value to the URL, which is sent to the web service. With this approach, we can influence what is being sent even during runtime, and it doesn’t have any negative side-effect. If nothing is configured, no changes will be applied.

Updating the web service

Well, this was the MDT side of things. Now we need to consume those additional information. To keep things simple, we make use of the Request.QueryString object. It contains the query string from the requested URL and by this gives us a list of all keys and values that have been sent. Now we create two lists, one with the original MDT properties and one that holds the custom ones. In your own solution, you most probably going to have just one, but for demonstration purposes, it’s a nice way of collecting them.

So all I do is I define a new class that contains all the original MDT properties

Then I can use this class as the parameter of my function, making use of a feature of ASP.Net MVC that maps each key from the query string to a corresponding property. Giving us a single object to work with.

If we use only the default properties, we are done now. To add our custom properties, we could either simply extend the above shown class, or we also make it a bit more generic and keep them in a list. As we need to assemble all parameters for our forwarded call to the original MDT Web service anyway, let’s use it to fill a list with all default properties.

Then we just take the rest and add them to an additional list, that contains our custom properties.

Looks like an ugly way of doing this, but as mentioned before, this is only for demonstration purposes. So the main target is, to just get it working. wlEmoticon-winkingsmile_2303958F1

Now we would need to store or use this information somehow. In the next post, we will create a small database, that stores this information for further usage and also gives us the same information like the workbench in a web page.


Returning Settings back to the Client

To finalize this post, we want to add the “GetSettings” function to our demo web service. As mentioned in my last post, it’s being queried by the gather process as soon as you switch on the monitoring feature. So without this function, you will regularly see some errors in your logs.

As we did with the the former function, we could also just pass this information to the original MDT web service and send the result back to the client. But as I found this feature pretty hard to use and configure with the default MDT implementation, let’s preserve this for future usage and just return a sample string for now, to prove that it’s working. For demonstration purposes I return a “HelloWorld” for a custom property called “MonitorResult

Looking at the log you can see, the gather process is now querying our custom Monitoring web service (which runs here on a different port than the MDT web service) and stores the result in the custom “MonitorResult” property.


Find the download with the compiled web service and the updated ZTIUtility.vbs file on CodePlex. The source files can also be found on CodePlex in the “Source Code” section. You might want to use a source control client like TortoiseSVN and point it to

In the next post, we will build upon what we have covered so far and move towards a more useful web service that stores and displays the information.

Das könnte Dich auch interessieren...

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.