• 0
The Other Josh

Groovy WMI documentation

Question

Is there any documentation for the Groovy WMI implementation (com.santaba.agent.groovyapi.win32.WMI and com.santaba.agent.groovyapi.win32.WMISession)?  I wasn't able to find anything in a short search.

In particular, none of the examples that I found in LM check for WMI credential properties (wmi.user and wmi.pass).

Share this post


Link to post
Share on other sites

24 answers to this question

Recommended Posts

  • 0

I suspect that the WMISession class automatically uses the wmi.* properties when it exists. I suggest you reach out to your rep or talk with support.

Share this post


Link to post
Share on other sites
  • 0

I'm pretty sure that it doesn't do anything automatically with the properties.  The issue we are working on is related to access rights on the service account vs the WMI account, which is why I wanted to do some testing while specifying different accounts.  The WinCPU datasource is not working (it doesn't reference the properties) but other WMI data collection is fine.

I am working with support but was checking here in parallel in case someone had the information readily available.

Share this post


Link to post
Share on other sites
  • 0

I found our internal documentation and still couldn't find anything about how to pass credentials or an example passing credentials.  In fact, it looks like that class was specifically built to "inherit a devices authentication, etc.". Since each collection task defined on a collector has the details of all properties on a device when the task is created, it's quite possible that it does use wmi.user/wmi.pass at runtime, even if you haven't pulled them into the groovy script via hostProps.get().

I've put in the request to have this documentation published in the support docs, but I don't think it will help. In the same request, i've asked that they detail whether or not wmi.user/wmi.pass can be passed in as explicit parameters to WMI.open(), WMI.queryFirst(), and WMI.queryAll(). 

Share this post


Link to post
Share on other sites
  • 0

I found only one instance of WMI.open() in the datasource set we have loaded -- in Citrix_XenApp_UserExperience:

def session = WMI.open(hostname);
def active_apps = session.queryAll(namespace, "SELECT * from Citrix_Euem_ClientStartup", 15);

The implication is it would have to handle wmi.user/wmi.pass behind the scenes.  All other references are for WMI.queryAll and WMI.queryFirst with the same implication.  If none of the modules properly handle those properties, then there are a lot of broken modules:

[mnagel@colby datasources]$ egrep -l 'WMI\.(query|open)' *
Citrix_XenApp_UserExperience
LogicMonitor_Collector_TotalCPUMemory
Microsoft_Exchange_ActiveDirectoryDomainControllers_2016+
Microsoft_Exchange_EdgeTransportDatabaseInstances_2016+
Microsoft_Exchange_EdgeTransportDatabases_2016+
Microsoft_Exchange_MailboxDatabaseInstances_2016+
Microsoft_Exchange_MailboxDatabases_2016+
Microsoft_Exchange_MailboxOverview_2016+
Microsoft_Exchange_Replication_2016+
Microsoft_Exchange_TransportQueueOverview_2016+
Microsoft_Exchange_UnifiedMessaging_2016+
Microsoft_LyncMediationServer_Stats
Microsoft_LyncServer_AccessEdgeServerStats
Microsoft_LyncServer_Authentication
Microsoft_LyncServer_BackupCentralManagementModule
Microsoft_LyncServer_ClusterManager
Microsoft_LyncServer_ConferencingAttendant
Microsoft_LyncServer_Datastores
Microsoft_LyncServer_EmergencyCallRouting
Microsoft_LyncServer_InstantMessaging
Microsoft_LyncServer_MCU
Microsoft_LyncServer_Messages
Microsoft_LyncServer_Networking
Microsoft_LyncServer_Protocol
Microsoft_LyncServer_Routing
Microsoft_LyncServer_RoutingApps
Microsoft_LyncServer_StorageService
Microsoft_LyncServer_WebServices
Microsoft_LyncServer_XMPPProxy
WinCPU
Win_WMI_Access_Denied_ErrorCodes
Win_WMI_UACTroubleshooter

Share this post


Link to post
Share on other sites
  • 0

Make sure you are providing the domain within the username if that applies, for example wmi-user = "Domain\Username".

 

Share this post


Link to post
Share on other sites
  • 0

Oh, I'm bookmarking that link! It looks like there is an option for open(Host,user,pass), although I wouldn't suggest doing that though since that breaks convention.

https://www.logicmonitor.com/support-files/javadocs/28606/com/santaba/agent/groovyapi/win32/WMI.html#open(java.lang.String,java.lang.String,java.lang.String)

  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
15 minutes ago, The Other Josh said:

Tested by setting wmi.user to 'thiswillnotwork' and both PollNow and collections are still working.

 

That is interesting because I tested something like that previously (I wanted to see what Windows SNMP can provide without WMI) but I had added the device to a group that had bad wmi properties pre-setup so it never had wmi working. Perhaps it's cached good creds? Can you try restarting the collector?

Also you are setting the cred properties on the device you want to use the creds on? Not the collector device itself.

Edited by Mike Moniz

Share this post


Link to post
Share on other sites
  • 0
3 minutes ago, Mike Moniz said:

 

That is interesting because I tested something like that previously (I wanted to see what Windows SNMP can provide without WMI) but I had added the device to a group that had bad wmi properties pre-setup so it never had wmi working. Perhaps it's cached good creds? Can you try restarting the collector?

Also you are setting the cred properties on the device you want to use the creds on? Not the collector device itself.

I was setting the creds on the instance that I was testing.  Are you sure that the datasources you were testing were using the groovy API?  I'll test caching later; right now still focused on the actual problem (this is just a side effect :).  

 

11 minutes ago, Mike Moniz said:

Oh, I'm bookmarking that link! It looks like there is an option for open(Host,user,pass), although I wouldn't suggest doing that though since that breaks convention.

https://www.logicmonitor.com/support-files/javadocs/28606/com/santaba/agent/groovyapi/win32/WMI.html#open(java.lang.String,java.lang.String,java.lang.String)

 

Yeah that link is handy.  What is the convention that it breaks (I was looking at some other session options that might let you set authentication parameters) - assuming that you are checking for and only using it if wmi creds exist?

Share this post


Link to post
Share on other sites
  • 0
7 minutes ago, The Other Josh said:

I was setting the creds on the instance that I was testing.

Just to clarify, you were setting it on the device, not the instances themselves, right?

Share this post


Link to post
Share on other sites
  • 0
Just now, Stuart Weenig said:

Just to clarify, you were setting it on the device, not the instances themselves, right?

 

Just the instance - I wanted to isolate the test.

Share this post


Link to post
Share on other sites
  • 0

Instance level properties are a different animal than device properties and unless you tried out the method that @Mike Moniz found in the documentation, i doubt the built in methods pull from instance level properties.

Share this post


Link to post
Share on other sites
  • 0
6 minutes ago, The Other Josh said:

I was setting the creds on the instance that I was testing.  Are you sure that the datasources you were testing were using the groovy API?  I'll test caching later; right now still focused on the actual problem (this is just a side effect :).  

Yeah that link is handy.  What is the convention that it breaks (I was looking at some other session options that might let you set authentication parameters) - assuming that you are checking for and only using it if wmi creds exist?

 

Good point, I can't confirm there was groovy datasources at the time. WinCPU switched to using groovy somewhat recently, likely after my tests.

 

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Stuart Weenig said:

Instance level properties are a different animal than device and unless you tried out the method that @Mike Moniz found in the documentation, i doubt the built in methods pull from instance level properties.

Good point, I do now recall frequently seeing hostProps.  Setting it at the device level does result in a failure.

Share this post


Link to post
Share on other sites
  • 0
23 minutes ago, Stuart Weenig said:

Instance level properties are a different animal than device properties...

 

I keep forgetting that is even an option. Are there good use cases for setting instance level properties I should be aware of?

Share this post


Link to post
Share on other sites
  • 0
1 minute ago, Mike Moniz said:

good use cases for setting instance level properties

Most common is for automatic instance level grouping. Instance level properties (aka ILPs) can only be used in Script, not batchscript DSs.  In certain cases, ILPs could be used to direct the logic of a script based ds, either passing creds, or other meta data.

Share this post


Link to post
Share on other sites
  • 0

Are you sure about the batchscript limitation? Because the new SNMP_Network_Interfaces DS supports subrate ifSpeed designation as ILPs and is batchscript (we know this because it blew out several collectors due to default batchscript thread counts).  I have not looked at the guts yet, so perhaps I am off track there.

Share this post


Link to post
Share on other sites
  • 0

"instanceProps.get()" only works on script because in batch mode, which instance's props would be fetched.

 

That DS "cheats" a little to get the instance props by using this function to grab the props:

/*******************************************************************************
 * © 2007-2020 - LogicMonitor, Inc. All rights reserved.
 ******************************************************************************/

/**
 * Capture instance props for the interface.
 * @param hostName
 * @param dsName
 * @return instanceProps
 */
static def getInstanceProps(hostName, dsName) {
    def instanceProps = [:]
    CollectorDb.getInstance().hostEntries.each { device ->
        if (device.getHostName() == hostName) {
            device.getDataSourceInstances().each { instance ->
                if (instance.getName().startsWith(dsName + "-")) {
                    def props = [:]
                    instance.properties.each { k, v ->
                        props[k] = v
                    }

                    instanceProps[instance.wildValue] = props
                }
            }
        }
    }
    return instanceProps
}

 

Share this post


Link to post
Share on other sites
  • 0

So you know what I am going to ask next, right?  What is CollectorDb and where is that documented?  Feels a bit unfair to us poor mortal developers :).

Share this post


Link to post
Share on other sites
  • 0
3 minutes ago, mnagel said:

So you know what I am going to ask next, right?  What is CollectorDb and where is that documented?  Feels a bit unfair to us poor mortal developers :).

heh, still looking for that key-value store huh? :)

Share this post


Link to post
Share on other sites
  • 0
Just now, Mike Moniz said:

heh, still looking for that key-value store huh? :)

I was not actually thinking that, but sure, I really would like one!  Seems like a way to possibly do some of the cross-device correlation I have been wishing I could do.  Just would not dream of touching without docs....

Share this post


Link to post
Share on other sites
  • 0

CollectorDB is an unpublished internal class/API. We are looking at building this functionality into a published API that you can use without fear.

Share this post


Link to post
Share on other sites
  • 0
On 7/1/2020 at 2:59 PM, mnagel said:

Are you sure about the batchscript limitation? Because the new SNMP_Network_Interfaces DS supports subrate ifSpeed designation as ILPs and is batchscript (we know this because it blew out several collectors due to default batchscript thread counts).  I have not looked at the guts yet, so perhaps I am off track there.

 

I had some feedback about that one too.  Doubling your interface count should have a bit more visibility.  I was also pretty unhappy that the patch notes described it as "an identical replacement"; I like the direction but it's definitely still a WIP.

The new collector sizes (XL and XXL) don't have any changes to the default batchscript threads.  I opened a ticket on that and made some adjustments to the threadcount and didn't see any problem with other performance metrics.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.