Microsoft Intune CMDB Integration

architecture scheduled to run once a day by default to get data from azure based microsoft intune, this integration consumes microsoft graph api to retrieve selected managed devices data, detected applications and the installation data of those detected applications on the managed devices the following are the cmdb data that will be populated from your microsoft intune by default intune endpoint intune resources servicely cmdb table description devicemanagement/manageddevices?$filter=devicetype eq 'desktop' or devicetype eq 'surfacehub' managed devices cmdbdesktop desktop cis devicemanagement/manageddevices?$filter=devicetype eq 'winembedded' or devicetype eq 'windowsrt' or devicetype eq 'windows10x' managed devices cmdblaptop laptop cis devicemanagement/detectedapps detected apps cmdbendusersoftware the applications/softwares registered on intune devicemanagement/manageddevices('${deviceid}')/detectedapps app installations cmdbinstalledsoftware the installation information of the registered applications/softwares on the registered desktops/laptops this is retrieved per managed devices by getting the applications installed on them reference to intune managed devices devicetype options https //learn microsoft com/en us/graph/api/resources/intune devices devicetype?view=graph rest beta reference to intune detected apps (software) discovered https //learn microsoft com/en us/mem/intune/apps/app discovered apps implementation steps the following outlines high level steps a typical implementation of this intune integration involves installing the “integration microsoft intune” application and performing an initial setup set up authentication from your servicely environment to your intune environment performing an initial one off pull from your intune to your servicely review the cis that the integration populates configure to address those review items by making the required tweaks as required activate the intune servicely job to have the integration running regularly on a pre defined but configurable, schedule application activation and performing initial setup install intune integration application navigate to application > application > applications and find the application named integration microsoft intune click on the “install application” button at the bottom of the form generate import tables there are four import table definitions as part of the microsoft intune integration the actual import tables will need to be generated prior to the first run of this integration to do that, please navigate to data import > import > import staging tables and find the following import table definitions intunecmdbdesktop intunecmdblaptop intunecmdbendusersoftware intunecmdbinstalledsoftware for each of the above import table definitions, view the record and click on the generate temporary table button example below set up authentication (azure and servicely) azure set up create and register a microsoft entra id (previously known as azure ad) app for more information please refer to azure configuration add the following microsoft graph permissions to the application note that each needs to be of type “application” with “admin consent” granted devicemanagementmanageddevices read all devicemanagementconfiguration read all offline access create a client secret for it and keep it for now as you need to enter it on servicely set up a redirect url for it as https //\<instance name> servicely ai/sso/oauth callback for example, if your instance name is acmecorp, the url should be https //acmecorp servicely ai/sso/oauth callback servicely set up (system oauth provider) the system oauth provider defines the information required to initiate the oauth2 authorization, token exchange, and token renewal you can find more information on the fields and requirements for the system oauth provider here managed oauth2 | oauth2 providers you can use one the supplied out of box templates, on the system oauth provider form, called “microsoft” to fill in the base information you will need to fill in the details for client id (get from “application id” of the microsoft entra id application you had set up earlier client secret tenant id (domain name you set up the microsoft entra id application in) to replace \[tenant id] part of both the authorization url and the token url grant type = client credentials initially the authorization urls populated by the microsoft template will look like the following replace the \[tennant id] part of the url with tenant id from previous step on azure setup then the overall system oauth provider will look like the following servicely set up (system api outbound token) the ‘ system api outbound token ’ record tracks the oauth authorization request this includes the user the request is to be issued as, along with the ‘scope’ of the privileges assigned to the user these tokens are tied to a system oauth provider ; however, you can have many tokens (each with different credentials and scopes) associated with each provider you can find more information on the fields and requirements for the system api outbound tokens here managed oauth2 | system api outbound tokens the only intune integration specific field you will need to configure is scopes (value as below) field value name microsoftintune scopes https //graph microsoft com/ default once the record is created, you can select the ‘ get authorization token’ button to begin the authorization process with azure you will be taken to the microsoft login page where you need to login as the user you want to use to access your intune data note that per microsoft article https //learn microsoft com/en us/intune/intune service/developer/intune graph apis microsoft intune , all intune’s api permission scopes currently require administrator access to authorize once you have authenticated, you will be asked to confirm the permissions being granted once the process is completed on microsoft end, you will then be taken back to servicely’s system api outbound token record you will notice that the state of the record will change from “new” to “ready” with the “expires” date and time auto populated note of the reference document from microsoft on consent consent experience for applications in https //learn microsoft com/en us/azure/active directory/develop/application consent experience servicely set up (set the token the integration to use) now that you have a system api outbound token set up, you will need to configure the intune integration property to make use of it go to the microsoft intune property page by navigating to microsoft intune > administration > properties find a property called “auth token” select the token you had set up previously click on save initial one off pull from intune into servicely navigate to microsoft intune > administration > job on the job record named “microsoft intune integration“, copy the “script” in there and execute it on the server script module please refer to server scripts documentation on how to execute/run one off server side scripts review the cis that the integration populates with relevant configuration management stakeholders check mapped fields are populated by the integration and if needed, review which intune attributes that are not yet mapped out of box check rough count of laptops/desktop/software cis vs what your intune has capture, review and prioritise the results from the review process configuration this section will make references to “intune integration properties” accessed by navigating to the microsoft intune property page by navigating to microsoft intune > administration > properties modify intune api queries used for managed devices this step may be required as part of initial configuration to ensure all devicetype possibilities are catered for and your servicely environment receiving all devices that are needed if you only need to pull one of the device types, for example, only laptop but not desktop, you should set the “desktop api endpoint” property to be blank on the intune integration properties, you may modify the following properties to add/remove graph api queries for the intune device types you would like synchronised over to servicely cmdb here are the properties property name default description desktop api endpoint $filter=devicetype eq 'desktop' or devicetype eq 'surfacehub'&$top=50 query to get cis to push to cmdbdesktop table note it is important that we retain the top http parameter to keep the number of devices returned by microsoft graph api per page, manageable and not throttled by the graph api laptop api endpoint $filter=devicetype eq 'winembedded' or devicetype eq 'windows10x' or devicetype eq 'windowsrt'&$top=50 query to get cis to push to cmdblaptop table note it is important that we retain the top http parameter to keep the number of devices returned by microsoft graph api per page, manageable and not throttled by the graph api modify/add intune attributes mapping to servicely here are the import staging table, transform map and cmdb tables mapping import staging table transform map cmdb table intunecmdbdesktop (intune) cmdb desktop api cmdbdesktop intunecmdblaptop (intune) cmdb laptop api cmdblaptop intunecmdbendusersoftware (intune) cmdb software api cmdbendusersoftware intunecmdbinstalledsoftware (intune) cmdb installed software api cmdbinstalledsoftware here are the out of box field mappings from intune to servicely desktop and laptop a field marked as the primary key in the mapping, is used by the integration to identify if a device in intune needs to update an existing ci in servicely, or create a new one if you need to check against the serial number instead of the intune device id, mark the serial number mapping to be the primary key instead if there is any mapping you do not need because you do not want servicely to bring in the particular information from intune, you can remove the field maping intune attributes servicely field names primary key id asset id yes devicename name model model lastsyncdatetime last discovered enrolleddatetime enrolment date osversion operating system version serialnumber serial number manufacturer vendor totalstoragespaceinbytes storage wifimacaddress mac address operatingsystem operating system physicalmemoryinbytes memory processorarchitecture processor userprincipalname end user lastloggedonuser last logged in user isencrypted encrypted software intune attributes servicely field names displayname name softwareversion software version to modify/add intune attributes to map to servicely identify the intune attributes you need servicely to process identify which cmdb tables and fields you want those intune fields to be mapped to add the intune fields you identified in step 1 into the relevant staging import tables there will be a “fields” field on the import table definition following is example for intunecmdblaptop with an initial set of intune attributes we had mapped as part of the out of box setup you will then need to regenerate the import table, by clicking on the "delete temporary table" button and then the "generate temporary table" button add the transform map for those new import fields for the respective staging import and cmdb tables import table automated cleanup it is important to have the import tables used by the integration, regularly cleaned up to avoid unnecessary growth in the database size for that, the integration comes with the following pre configured system table cleanup records they are deactivated by default, but you should review them, update the data retention configuration if required, and then activate name table to cleanup default data retention clean up intune laptop records imptmpintunecmdblaptop max 7 days since creation date/time clean up intune dekstop records imptmpintunecmdbdesktop max 7 days since creation date/time clean up intune software records imptmpintunecmdbendusersoftware max 7 days since creation date/time clean up intune installed software records imptmpintunecmdbinstalledsoftware max 7 days since creation date/time to update the data retention configuration, please refer to this documentation system table cleanup advanced while all of the intune integration’s properties, can be updated, in most cases only the following may require changes please contact servicely support if you have questions on any of them property name default value description graph api version to use beta graph api version used for the intune integration choices are either beta v1 0 max pages 100 maximum pages in graph api paginated responses that servicely will handle this may need to be increased depending on the amount of data on your intune interval between consecutive api calls 120 interval in seconds that can be used to space out graph api calls chained one after another like pagination, to prevent throttling ref doc on microsoft about their graph api throttling https //learn microsoft com/en us/graph/throttling limits, e g every 20 seconds there is a max 200 requests for intune one installed software api structure device microsoft graph api allows for two different ways to retrieve software installation information, i e either by getting software installation off software definitions or off managed devices at the present time, the default way we are using is to get software installation per managed device choices are either (with order of api executions) device → get detected applications (software), then get managed devices and then get the detected applications installed on the managed devices software → get managed devices, then get detected applications (software) and then get the managed devices the detected applications (software) are installed on integration’s schedule the microsoft intune integration’s job that comes with the application runs on a schedule to regularly pull from intune into servicely it is not active by default to give you a chance to do ad hoc runs and have the resulting data reviewed to update/enable the job, navigate to microsoft intune > administration > job to update frequency of the job, update the “cron expression” there, you can define frequencies such as running the integration once a day, twice a week, etc note that the default is that integration will run once a day at 1am local time please contact servicely support of any question to enable the job, set active to be “yes” and click save to disable, set active to be "no" and click save non production servicely environments you should also consider whether you want a clone target instance such as a non production environment to run intune integration at all or to run it at different times if so, please set up a system configuration script to do that, on your production environment accordingly