One of the cool new features of System Center Operations Manager 2007 R2 is the possibility to check and update Management Packs from the catalog on the Internet directly from the Operators Console:
Even if the backend for this feature is not yet documented, I was extremely curious to see how this had actually been implemented. Especially since it took a while to have this feature available for OpsMgr, I had the suspicion that it could not be as simple as one downloadable XML file, like the old MOM2005’s MPNotifier had been using in the past.
Therefore I observed the console’s traffic through the lens of my proxy, and got my answer:
So that was it: a .Net Web Service.
I tried to ask the web service itself for discovery information, but failed:
Since there is no WSDL available, but I badly wanted to interact with it, I had to figure out: what kind of requests would be allowed to it, how should they be written, what methods could they call and what parameters should I pass in the call. In order to get started on this, I thought I could just observe its network traffic. And so I did… I fired up Network Monitor and captured the traffic:
Microsoft Network Monitor is beautiful and useful for this kind of stuff, as it lets you easily identify which application a given stream of traffic belongs to, just like in the picture above. After I had isolated just the traffic from the Operations Console, I then saved those captures packets in CAP format and opened it again in Wireshark for a different kind of analysis – “Follow TCP Stream”:
This showed me the reassembled conversation, and what kind of request was actually done to the Web Service. That was the information I needed.
Ready to rock at this point, I came up with this Powershell script (to be run in OpsMgr Command Shell) that will:
1) connect to the web service and retrieve the complete MP list for R2 (this part is also useful on its own, as it shows how to interact with a SOAP web service in Powershell, invoking a method of the web service by issuing a specially crafted POST request. To give due credit, for this part I first looked at this PERL code, which I then adapted and ported to Powershell);
2) loop through the results of the “Get-ManagementPack” opsmgr cmdlet and compare each MP found in the Management Group with those pulled from the catalog;
3) display a table of all imported MPs with both the version imported in your Management Group AND the version available on the catalog:
Remember that this is just SAMPLE code, it is not meant to be used in production environment and it is worth mentioning again that OpsMgr2007 R2 this is BETA software at the time of writing, therefore this functionality (and its implementation) might change at any time, and the script will break. Also, at present, the MP Catalog web service still returns slightly older MP versions and it is not yet kept in sync and updated with MP Releases, but it will be ready and with complete/updated content by the time R2 gets released.
Disclaimer
The information in this weblog is provided “AS IS” with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. All code samples are provided “AS IS” without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
THIS WORK IS NOT ENDORSED AND NOT EVEN CHECKED, AUTHORIZED, SCRUTINIZED NOR APPROVED BY MY EMPLOYER, AND IT ONLY REPRESENT SOMETHING WHICH I’VE DONE IN MY FREE TIME. NO GUARANTEE WHATSOEVER IS GIVEN ON THIS. THE AUTHOR SHALL NOT BE MADE RESPONSIBLE FOR ANY DAMAGE YOU MIGHT INCUR WHEN USING THIS INFORMATION. The solution presented here IS NOT SUPPORTED by Microsoft.
Thanks, works great.
Since the company I work at uses a proxy server I had to add the following:
$proxy = New-Object System.Net.WebProxy(“http://YOUR_PROXY_SERVER:80”)
$proxy.UseDefaultCredentials = $true
$req.proxy = $proxy
Yes, I intentionally left the proxy code out, as well as any decent error handling, to be honest: this is meant to be an EXAMPLE, so I wanted to leave IN the code just the mininum important instructions to get it working…
Also, currently I have not found a way in R2 beta to tell the GUI it is supposed to use a proxy… and that’s a bit more difficult to add, but in a script, anyway, it is very easy to change just adding the few lines you mentioned.
…in general I hate when people don’t include that possibility: http://www.muscetta.com/2007/08/13/why-do-developers-tend-to-forget-about-people-behind-proxy-servers/ :-))
Hi we also run Proxy servers for all our servers I am not familiar with powershell scripting and Richard K has posted the code kindly but where does the code need to be inserted and also wll this script work with Scom 2007 R2 Eval ?
Also where is the best place to post questions on Scom 2007 R2 ? So far I am unable to get the DFS Windows 2003 Pack working on our servers.
Thanks for your help in advance.
Jamie, for questions there used to be NNTP newsgroups, now replaced by the new web forums. Read more at Kevin’s blog http://blogs.technet.com/kevinholman/archive/2009/05/22/new-web-based-forums-for-opsmgr-no-more-nntp-newsgroups.aspx
As for the script, it still seems to be working, but in the future it might work or not work, as the webservice has not really been documented or released for anyone other than the console to use… so it might change. In fact, the Product Group has been asked (not just by me – http://blogs.technet.com/stefan_stranger/archive/2009/05/15/when-will-there-be-wsdl-for-the-mp-catalog-webservice.aspx) if they will provide more specification about the webservice… but I have not had a reply yet. Therefore, I think that means “no”…
Also, if you look at the GUI in R2 when checking for MPs from the internet, it will show you a certificate, and the whole conversation is now happening over HTTPS rather than HTTP. It still seems to work the way it worked, other than on teh more secure protocol…. but if the web service changes, it will be more difficult to reverse engineer, but it will provide transport security so that you know you really are downloading MPs from Microsoft.com, not from somewhere else through a man-in-the-middle attack.
Finally, adding the three lines by RichardK to handle the proxy is really simple – it should go after line 30.
But I would suggest you skip this and just use the console… this was meant as an experiment, not for production use.
…wow…this is hard core…and awesome. Thanks for sharing!
Yes it it pretty hardcore – I basically reverse engineered the communication to be able to interact with a webservice that is, in fact, only intended to be used in conjunction with the GUI.
But there was really no other way…
Great!!!! I was thinking about doing the same thing, and you did all already. This is awesome!
Your reverse engineering is too good. Thanks for the informative post. I should check how many of my management packs are lagging updates.