Groovy WMI documentation
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).
The_Other_Josh
Posted 6 years ago·Last reply 6 years ago
24 comments
The_Other_Josh
OP6 years agoI 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.
Michael Rodrigues
·6 years agoCollectorDB is an unpublished internal class/API. We are looking at building this functionality into a published API that you can use without fear.
mnagel
·6 years agoI 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....
Mike Moniz
·6 years agoheh, still looking for that key-value store huh? :)
LM User
·6 years ago"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:
mnagel
·6 years agoAre 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.
LM User
·6 years agoMost 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.
Mike Moniz
·6 years agoI keep forgetting that is even an option. Are there good use cases for setting instance level properties I should be aware of?
The_Other_Josh
OP6 years agoGood point, I do now recall frequently seeing hostProps. Setting it at the device level does result in a failure.
Mike Moniz
·6 years agoGood point, I can't confirm there was groovy datasources at the time. WinCPU switched to using groovy somewhat recently, likely after my tests.
LM User
·6 years agoInstance 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.
The_Other_Josh
OP6 years agoJust the instance - I wanted to isolate the test.
LM User
·6 years agoJust to clarify, you were setting it on the device, not the instances themselves, right?
The_Other_Josh
OP6 years agoI 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?
Mike Moniz
·6 years agoThat 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.
Mike Moniz
·6 years agoOh, 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)
The_Other_Josh
OP6 years agoTested by setting wmi.user to 'thiswillnotwork' and both PollNow and collections are still working.
Michael Rodrigues
·6 years agoIt will automatically pull in wmi.user/pass.
Here are some recent javadocs: https://www.logicmonitor.com/support-files/javadocs/28606/com/santaba/agent/groovyapi/win32/package-summary.html
Mike Moniz
·6 years agoMake sure you are providing the domain within the username if that applies, for example wmi-user = "Domain\Username".
mnagel
·6 years agoI 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
LM User
·6 years agoI 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().
The_Other_Josh
OP6 years agoI'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.
Mike Moniz
·6 years agoI 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.