Jaa

Extra Monitor Type for TCP and HTTP(S) Synthetic Transactions

  • Artikkeli

NOTE: I authored this MP in the SCOM 2007 R2 Authoring Console. This MP should work in both SCOM 2007 and SCOM 2012. I have only tested it in SCOM 2012 R2, so if you are using it with a different version of SCOM you may want to verify that it properly works.

The SCOM Operations Console provides a way to author TCP and HTTP(S) synthetic transactions. But sometimes it is handy to be able to author these checks directly into a Management Pack.

Some common reasons to do this would be:

  1. You need all members of a class to run the transaction.
  2. Authoring Web Application and TCP Port monitors in the Operations Console requires that you explicitly pick agents and/or resource pools from which to run the test. This means you must manually keep up with configuration churn.
  3. You want to use object properties in the monitor configuration.
  4. You want to put these monitors into MP's that can be shared or distributed across SCOM deployments.

To meet this need I have created two, very simple monitor types.

Microsoft.Extra.Synthetic.Transactions.TCP.Port.MonitorType

This monitor uses the existing Microsoft.SystemCenter.SyntheticTransactions.TCPPortCheckProbe probe found in the Microsoft.SystemCenter.SyntheticTransactions.Library. You can read more about it on MSDN. https://msdn.microsoft.com/en-us/library/jj130214.aspx

I just used a Simple Scheduler and a couple of Expression Filters to turn it into a monitor type.

The monitor takes three configuration settings.

  1. Destination – the IP address or DNS name of the destination
  2. TCPPort – The TCP port you want to check
  3. IntervalSeconds – How frequently you want it to run

If you want to put its output into an Alert Description, you can do something like this:

  • Server or IP Address: $Data/Context/DataItem/ServerName$
  • TCP Port: $Data/Context/DataItem/Port$
  • Connection Time: $Data/Context/DataItem/ConnectionTime$
  • Status Code: $Data/Context/DataItem/StatusCode$

Microsoft.Extra.Synthetic.Transactions.Basic.URL.MonitorType

For this monitor type I did write a custom data source in PowerShell. I could have used VBScript, but that would have prevented me from allowing the option to make the call, automatically using the credentials of the Run As user account, without needing to pass the user name and password as parameters.

These are the monitor type's configuration settings:

  1. URL – The URL you want to test. HTTP and HTTPS are both fine.
  2. IntervalSeconds – How frequently you want it to run.
  3. UseDefaultCredentials – false will make an ANONYMOUS request. true will have it use the credentials of the SCOM Action Account.
  4. Proxy – Leave it blank to not use a proxy server. Otherwise fill it in. You can use IPAddress:PORT or Hostname:PORT
  5. CertThumbprint – Leave it blank to not use a client cert. Otherwise give it the thumbprint of a cert installed in the Local Computer’s Personal certificate store.

The PowerShell script itself is nothing fancy. I just create a [System.Net.HttpWebRequest] and then optionally set the UseDefaultCredentials, Proxy, and ClientCertificates properties if I need to. You can read more about this on MSDN here: https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest(v=vs.110).aspx

For your convenience I will place the PowerShell script in the ZIP file attached to this blog post so you can easily see it outside of the SCOM MP. If you want to use the script outside of SCOM you will need to update the QuitTheScript to output something besides a SCOM property bag.

I am also including a sealed and unsealed copy of the library and an example MP that uses the library. The example MP demonstrates some possible ways to use the monitor types and data that can be included in alert descriptions.

Extra.Synthetic.Transactions.zip

Comments

  • Anonymous
    May 18, 2016
    Hi Michael,Thanks for the sharing. I did an almost exactly same MP for TCP Port monitoring too. But recently I got a new request, the server name and port number are provided in a configuration file. Each monitored server might have different server name and port in the configuration file. So my first thought is to add one more script probe which read the configuration file, wrap server name and port number in a property bag and then pass it the TCPPortCheckupProbe.The property bag out put as followingHealthy. Deploy server configuration is loaded.10.240.0.748089You can see I have already convert "Port" to type 2 which is integer. However when I tried to pass the value to TCPPortCheckupProbe by configuring it as following $Data/Property[@Name='Server']$ $Data/Property[@Name='Port']$ I got error message mentioned $Data/Property[@Name='Port']$ is string type and not matching with required integer type. I guess SCOM might treat all $Data$ values as string by default regardless what the value data type is at the first place. So any suggestion to work it around?Thanks!