You'd probably want to do this using the BLCLI/Jython. While it's possible using NSH as seen in this KB article: https://www.bladelogic.com/community/entry.jspa?categoryID=28&externalID=666
it would probably take a long time against a large # of servers. A Jython script would be much faster. To query data across 3000+ servers and set a property using NSH would take some time, and Jython would certainly be the solution to that.
There are several Jython samples in the KB that would be a good start:
What's the big picture for this? Why do you want to store it in a property ? Depending on what the end goal is, there might be other options.
We take all of the custom fields from the servers and upload them to a datamart for use with our CMDB system. We are looking for the most efficient way to gather up some of the items we track for this export. Currently we see some of our items already accounted for in the live view and it would seem easier to copy that info to our custom field than to go and query for the info for each server again. (Unless, that's what the live view is doing in which case, it would make sense to query for it using an NSH script.) I have done the shell script NSH method and also a vbscript, but they are time-consuming on 3000+ servers, as well as a bit processor intensive.
Thanks Greg, I'll read those and see if they help out.
I see that the script provided does what I was looking for, but seems like it may be a wash when it comes to being any faster. The only thing I may save by doing it this way is the time it would take to write the scripts for the various OSes that we'd need to account for. I would have thought querying a local database would be considerably faster than deploying and capturing the output of a script.
depending on what you are looking for, some of it is gathered live by the blquery command (part of nsh). alot of the information is also gathered by the os_config.nsh script - and ends up in xml files in /data/os_config.
you could write something to parse the xml files for the data you need (assuming it's all in there) - you could also write something to pull it out of the reports database directly - that might be the easiest - the reports db is fairly flat.. now the data won't be "live" - it would be as old as the last run of the reports population process, which is usually run daily.
I would like this too.
I'm trying to run a script against servers that have a specific service enabled on them. I can detect the service by looking in a config file on the server. So the ones that have the service now have a component showing that. But, I cant run a job against "components". Only Smart Groups. And Smart Groups are defined by the Server properties.
So I'm trying to figure a way to have a Discovery job, once it detects a specific condition on a server, somehow have a property on that server set. then any new servers it discovers will be set and put into the Smart Group and the job can be run against them.
Its kinda weird to have to take a component in BL, and to use it in a external script (BLCLI) to put it back in BL.
There's a couple ways you could do this:
1 - NSH Script that will perform the 'discovery' step of finding the config file or config entry, then some blcli in the same script that sets the property on the server. No components or discovery jobs.
2 - Use the existing components and discovery jobs, add an nsh script that uses the blcli to check if a component exists for a server, then sets the server property. run the discovery and nsh script job together inside a batch job.
How does BL do it for their default server properties?
If I install an agent, the OS is tagged as a property. There's no BLCLI scripting,etc to do. I'm surprised that this isnt a basic thing to do as thats mainly what BL is for is to discover and Id devices/servers then use that info to do things against the devices.
But since its not available, I'll have to find another way.
In option 1, the script will be deployed to a device and then ran. That same script will then have to connect back to the BL server to set the property thru BLCLI right?
In option 2, the BL server would launch a script on a device with client binaries to use the BLCLI connection?
It's built in - but it's not accessible...
in both cases the script will be running from NSH, so the blcli will be available. in #1 you'd do some nexecs or blqueries to get the info off the server (look at os_config.nsh)
in #2 it would run only against the appserver, from the appserver