Share via

Office Communications Server and WMI

  • Article

As many of you are likely aware, Office Communications Server (and previous versions) make use of WMI for storing various pieces of data.  You can find details of the WMI classes that currently ship with OCS 2007 here.  While this gives helpful information about what types of classes and properties are available, there are some fine points that I believe would be helpful to know.

First, our WMI provider is quite a bit more complicated than your traditional WMI provider.  In a simplistic view, it provides seemless access to data from three separate sources.

1) Active directory

2) WMI

3) SQL server

In theory, when you query these WMI classes you do not need to know from where the WMI provider is getting its data.  However, in reality this is not true.  In order to query a WMI class that uses active directory, the account you are running under must have permissions to AD.  If this is not the case, your query will fail.

In a somewhat finer point, say you wish to query MSFT_SIPRoutingTableData.  Say you know the MatchURI and wish to perform a query.  Your first inclination would be to probably create a query similar to the following.

SELECT * FROM MSFT_SIPRoutingTableData WHERE MatchURI='[match Uri]'

This may give you the results you want, but may also be extremely slow.  Why is this the case?  Say you have several pools in your forest, and they are spread over a wide geographic area.  For instance, one pool is located in Singapore.  When you perform this query, the WMI provider will retrieve the results from all pools.  This has two very bad consequences.

a) If the WMI provider must query SQL servers that are located very far away, this query will be very slow and may waste valuable network bandwidth.

b) This will return results from all pools.  Therefore, in some cases you may only expect a single result but will actually receive multiple results.

The solution is to only query the backend when performing a WMI query on a SQL backed class.  Therefore, instead of the above query you would do the following.

SELECT * FROM MSFT_SIPRoutingTableData WHERE Backend='[backend]'

If this is an SE pool, then you can use (local)\\\\rtc (extra slashes for WMI).  If this is Enterprise Edition, you may or may not know the backend.  In a later blog I will discuss you to retrieve this.

You will then need to iterate through the results and check the MatchURI property for the one you are looking for.  Admittedly, this is not an elegant solution but in most cases it will be the better performing one - unless you only have one pool in your enterprise.

You may wonder why you cannot simply create a query checking for both results.  Unfortunately our WMI provider does not support multiple query search terms and therefore this will not work.

So how can you tell where the WMI provider retrieves its data for each class?  For SQL server backed classes, this is easy.  If the class contains a backend property, then it is SQL backed.

Comments