Use case 1: Insert CMDB Data Feed into ServiceNow
Pull Computer and Handheld CI data into ServiceNow CMDB and update it based on the serial number match. In addition to standard attributes this will demonstrate how additional attributes can be obtained through customization.
Implementation
- Install Service Graph Central app from the store a as guided setup for Service graph will be deprecated soon.
- Configure the connection by choosing the Intune connector playbook and provide the Client ID, Client secret and Token URL
- Change application global to Service Graph Connector for Microsoft Intune.
- Below Actions are available by default upon plugin activation.
5. Now for example if there is a requirement to bring in additional attributes such
as joinType, azureActiveDirectoryDeviceId, physicalMemoryInBytes,actionName then it should be added in the script parser under the computers action as per below. Add custom attributes by choosing the concerned Action that is available as default for Intune.
6. Similarly as an example if there is a need to get a new attribute (ethernet mac address) into ServiceNow
that is not stored in import sets then custom action must be created altogether.
7. Once action is created this can be called from the OOB Script include (IntuneIntegrationUtil)
// Custom code added to fetch ethernetMacAddress
getMacAddress: function(connection, deviceid) {
var inputs = {};
var macAddress = "";
inputs['connectionalias'] = connection;
inputs['deviceid'] = deviceid;
var response = this.executeRestAction('sn_intune_integrat.intune_device_ethernetmacaddress', inputs, 'ethernetMacAddress');
if (!gs.nil(response) && response.statuscode == 200) {
macAddress = response.responseobject;
} else {
gs.error("SG-Intune: IntuneIntegrationUtil.getMacAddress() returned no response for device id - " + macAddress);
}
return macAddress;
},
8. Mapping changes have to be done to the OOB Robust transform map to bring in the custom attributes in CMDB.
9. For example, to bring in RAM attributes from Intune and mapping it in CMDB following approach should be considered.
10. First, we must create Entity field records for the required custom attributes
11. Remember data that is coming from Intune will be stored in Import entity first so the field (u_physicalmemoryinbytes) in import set table will have RAM from Intune data stored.
12.As a next step create an Entity Operation to manipulate this data if required for example convert ram data into MegaBytes.as ram data which is being retrieved from Intune is in Bytes.
13.Then map ram entity field to computer table ram field.
14. Follow the similar steps for adding additional custom attributes.
Use case 2: - Wipe and Delete Operations in Intune
Intune Integration can be leveraged for maintaining the Cloud PC’s life cycle and perform Wipe and Delete Operations on PC’s during offboarding process automatically through graph API’s.
Consider asset user making status changes in the alm hardware table as per the below conditions that would then trigger either a wipe or delete of the CPC’s.
Wipe/Delete Operation
Wipe command should be issued at Intune side during following conditions which is triggered from the Flow. Below scenarios were considered as an example and for better understanding. Additional conditions should be included and not limit it to State values depending on the requirements.
- State changes from In use to In stock, Configuration is Computer and Action is Wipe (This can be set through UI Action based on user's confirmation).
- State changes from On order to In stock, Configuration is Computer and Action is Wipe (This can be set through UI Action based on user's confirmation).
- State changes from On order to In stock, Configuration is Computer and Action is Wipe (This can be set through UI Action based on user's confirmation).
- State changes to Missing and Action is Wipe, Configuration is Computer.
User returns the PC to the inventory and asset user changes the state to In Use/In Stock available which means it will be reused and allocated for another user hence Wipe gets triggered through Wipe button on the form and based on states respective actions (Wipe/Delete) can be triggered.
This will trigger the custom flow that calls the Graph API by providing the device id details and initiate wipe.
- Flow trigger happens through state changes in the alm hardware table.
- Get Device ID, Device Name, Serial Number, Stock room, Previous owner details of the asset to name the few.
- As an immediate step access has to be revoked through Intune Webhook API by sharing the Device name details.
- Delete owned by details by consuming Intune graph API by providing device id
- Keep a check on the user and user's group who has initiated wipe operation for auditing purposes.
- Remove the owned by details in the hardware table.
- Initiate Wipe command by consuming graph API and issuing wipe as per below resource path.
/v1.0/deviceManagement/managedDevices/action->Device ID/wipe
- Wait for a day and then check for the device status by using Get method
- If Wipe is successful then update the log and end it else assign it to the respective group to take care of this process manually.
- Repeat the above steps for Delete operation by performing Wipe operation first and then for Delete seek confirmation from the concerned fulfiller group.
Common challenges
Device ID is provided as a parameter to the API for both Wipe and Delete operations. Sometimes it would throw 504 error while consuming Intune Graph API for which you need to ensure required read permissions for the Service account created in Azure as part of Application registration and the same should be used for authorizing account to fetch and refresh tokens through Oauth mechanism.
API Permissions
DeviceManagementManagedDevices.ReadWrite.All, DeviceManagementManagedDevices.PrivilegedOperations.All
Also, Microsoft Intune package should be configured at Intune side as per the pre-requisites so consult Intune team for further troubleshooting.
Quality Testing
My recommendation is to do enough testing with Wipe and delete operations with test PC’s in lower instances to ensure foolproof solution and it doesn’t trigger wipe/delete operation for an incorrect user. Wipe and Delete operations are queued and managed through threads ensure it doesn't cause performance issues and incorrect deletion.
1 Comment
