The BigFix team is very pleased to announce the release of version 1.5 of BigFix ServiceNow Data Flows! This integration enables organizations to harness the wealth of near real-time endpoint data that BigFix makes available to automatically enrich ServiceNow® CMDB. Conversely, it also provides BigFix with access to endpoint metadata and business contexts defined in ServiceNow® CMDB.
This functionality enhances the discovery, tracking, and understanding of assets using BigFix endpoint data available in ServiceNow®.
Identify, prioritize, and remediate issues by utilizing the business context of your endpoints (such as Department, Location, and Environment) from ServiceNow® directly within BigFix. Additionally, deploy actions targeting these attributes.
The main features of this release are: Improvements:
Support for ServiceNow Xanadu Release.
Bug Fixes
Added more validation such as validating the property name before running the Dataflow.
Defect Article Resolution:
The following defects have been resolved in this version:
KB0115319: ServiceNow Integration failure because of missing module.-
KB0116089: Computers are missing in the analysis "ServiceNow Custom Properties“.
KB0118264: Correlations are not triggered correctly.
Version Information:
Published site version: 10
Useful links:
For more information, please see the documentation
I guess worth asking @MB43, to what use case you are after? While the usage of the above-mentioned tables is hardcoded, we technically only use cmdb_ci_servers which is nested under computers (purposely narrowing the scope of the machines) and yet pulling certain fields from other related tables, including custom fields, like using dot-walking - ex. asset.install_date, asset.retirement_date, manufacturer.name, support_group.name, ref_cmdb_ci_server.u_patch_time (extending the data scope for the machines already in scope).
I guess worth asking @MB43, to what use case you are after? While the usage of the above-mentioned tables is hardcoded, we technically only use cmdb_ci_servers which is nested under computers (purposely narrowing the scope of the machines) and yet pulling certain fields from other related tables, including custom fields, like using dot-walking - ex. asset.install_date, asset.retirement_date, manufacturer.name, support_group.name, ref_cmdb_ci_server.u_patch_time (extending the data scope for the machines already in scope).
That helps quite a bit.
I’m not all that familiar with the structure of SNOW tables (what’s nested under what, how they relate, etc.) or what’s custom in our environment and what’s default.
I have a PowerShell script that pulls data from SNOW tables, such as cmdb_ci_servers, cmdb_ci_win_server, cmdb_ci_esx_server, (etc.) and updates custom properties on BigFix computers. And other scripts that update those tables with data from BigFix (such as last patched date). If all of those tables are nested under CMDB_CI_COMPUTERS I guess we would be able to use this integration instead my custom scripts.
Yea, that’s why I asked because while tables are locked out/pre-built there is some room for customization to an extend in both directions. For narrowing the scope you can use filterquery object within the config to narrow the data - for example, I specifically used: <filterquery><![CDATA[sys_class_nameLIKEServer^sys_class_nameNOT LIKEESX^sys_class_nameNOT LIKENutanix^sys_class_nameNOT LIKEStorage^sys_class_nameNOT LIKEChassis]]></filterquery>
but you can certainly play with those filter direclty on ServiceNow CMDB side to see what data is left and mimic whatever filter you like in a similar manner within the Data Flow config’s ServiceNow Adapter’s filter parameter.