We are currently working on a way to integrate Endpoint Manager with our CMDB. What we want to accomplish is to have data in a number of fields in the system for each computer object, that contains data that come from our CMDB.
We have added a number of global properties, such as “Region”, “Environment” and “Category”, they are the visible for every computer object, so far so good.
The plan is then to export data from our CMDB and to import the data into the respective property field in IEM. This was not as easy as we expected, the solution that we are currently working on uses the REST API and makes calls like this:
This would actually be a method that works, but there is an issue that we need to resolve. Every single call to the REST API that set / modify a property of a computer objects is logged as a “Single Action” in the system. The list of actions will be huge, and it does not make sense to log all these updates as separate actions.
Questions:
Is there a better way to import custom property data into IEM, than using the REST API?
- Otherwise, is it possible to disabled the action logging, perhaps for a specific account?
Overall what happens is that the values of the properties in the database come from the periodic report that each computer sends.
The post to the REST API is creating an action which sets the value of the setting on the computer. When the computer reports the value it will then be in the database.
So it’s not a direct update of the information in the database - rather an update of the data on the computer which is then reported into the database by the computer.
I’m not sure if that’s what you intended with your solution but that’s how properties and settings work.
Without an action you will not set the value of the setting on the computer so you won’t get a value coming into the database.
Unless you have different way to determine the value you want for the property, say by using existing attributes of the computers. You would then determine the value using relevance. Which might be a nice way to do things.
Thanks a lot for your quick reply. I understand how you mean, so perhaps using the REST API is not the best approach.
What I want to accomplish is to have custom fields for each computer object in the IEM database which contain information that comes from another system.
In our CMDB we have information such as servername, category, description, region, environment etc. We want this information to be available in IEM as well to be able to build smarter automatic groups. As I understand it, the only way to accomplish this is to create global properties.
I guess one thing to keep in mind is that with Endpoint Manager much of what’s determined is done by the agent running on the computer using data from the computer itself. It’s not done by a process running on the server using data in the database.
In the case for automatic computer groups - each computer’s agent determines its automatic group membership using data on the computer. It then reports its membership back to the databse. If you want to use your data for automatic computer groups it needs to be on the computers themselves, or readily accessible by them.
So a couple of things to consider:
Can you use existing data on the computers to determine the same values you are setting in the CMDB ? This has a couple of advantages:
you will always have the most current assessment because it’s being done using real time data on the computers.
you will not have to set the setting like you were doing above.
If you do have to set the property data to the computers you can create a fixlet or task that does this. Then using REST API you Take Action and target multiple computers. Using your example: create a task that sets the value of Category and takes the value as a parameter. To set all your web servers with the value “Web Server” you take action, send in “Web Server” as the parameter value and target all of the web servers. You will still be creating actions but there will a lot less of them.
Use REST API’s action resource to take the action.
I’m curious why you need to do this at all? What if you could look up all the info in IEM within your CMDB? would that be sufficient?
Also, the best way to go about this would be if the client machine could query the CMDB itself using something that is already in the CMDB like a serial number, IP address, MAC address, etc… then the client would take the info from the CMDB and save it to an XML file or something similar. Then you would create an analysis that would read back this info into properties and make it available within IEM.
This would mean you would create a single action targeted to all endpoints and the data from the CMDB would populate IEM automatically.
The reason that we want to import metadata for computers, is that we would like to create automatic groups for patch management, which are defined on such things as the region and physical location of the server, the applications hosted on it, the server SLA level etc.
This information is nothing that each computer itself can find out using relevance, so it makes sense to import this as metadata for each computer in IEM.
We have actually used the method described above, when the data is first imported it generated a lot of actions, since every single setting will be logged. But when the data is there, only the future updates are logged.
The option I was describing does not involve multiple actions, but a single action for all endpoints. The actionscript running on the endpoint itself would query the CMDB for info about itself and save that info to XML or the registry and not to a client setting. Once in XML or the registry, you can use relevance to query the XML or registry on the client and pull that into properties in an analysis and then use those properties/relevance to create automatic computer groups. This task would run periodically on the endpoints to update the XML/registry to reflect any updates to the CMDB, perhaps once a week.
I would not recommend the multiple actions to set multiple settings unless it is a very small number of settings.
How many endpoints do you have total? That also affects the recommendation.
At my installation we have a CMDB feed pushed to our BES Server 3 times a week with the fields we are interested in and use IIS to host an aspx page that we let the BES clients query and load into a file on the endpoint. We then have an analysis that has properties for the different fields in the BES client file.