Discovery auto populating assigned_to, breaking asset management processes.

smfoister
Giga Expert

Good morning,

 

OOTB Discovery runs and populates the assigned_to field on CI's. This is breaking out hardware asset management process and assigning assets to users erroneously if they sign into a shared machine, or a projection computer, kiosk, etc...

 

I'd like to have Discovery populate a custom field I have created on the CMDB called "u_last_logged_in"

I have found and customized the sensor that identifies computer information with no luck. I have also attempted to change the assigned_to field in the discovery pattern to use u_last_logged_in and I'm just getting a JS error. 

I'd like to hear from the community on how you would do this. I feel like there really should already be a last logged on field OOTB and you should have an option to populate this field, or assigned_to. I don't think assuming the recent user of a machine is the asset / CI owner is a very good practice.

1 ACCEPTED SOLUTION

Its running for both.. Ignore the var windowServer. lol

So doesn't look like anything changed here based on what I shared above. So if you want to map to a new field, need to update pattern with custom field and then updated the two lines below in the post script. 

 

 

Script you need to change the following:

var userName = windowsServer.assigned_to; <-- change "assigned_to" to whatever value you are using in the pattern. 

 

 windowsServer.assigned_to = userID; <-- change "assigned_to" to whatever filed you are using to match above. 

View solution in original post

8 REPLIES 8

Patrick DeCarl1
ServiceNow Employee
ServiceNow Employee

You using patterns or probe/Sensor? For windows. 

If pattern:

go to "pre post processing" look for "Windows OS - Pre Sensor", you can change line 44. However, you will own this code moving forward. 

If probe/Sensor:
go to "Windows - OS Information" sensor and change line 42, however, you will own this code moving forward. 

 

I'm using patterns, I've tried your suggestions and it doesn't work as intended. I've found the transform table in the Windows OS discovery pattern and changed assigned_to to my custom field. In debug mode it seems to work but it's not actually populating on the CI in the test environment. 

In debug mode it looks to be using domain\username as the value. So now my thought is that perhaps there is a component that strips the domain off of the username when populating assigned_to through discovery. If that's the case then I would need to update whatever that component may be to use my custom field.

Does that make sense?

What does your "pre post processing" look for "Windows OS - Pre Sensor" look like? Just changing it in the pattern doesn't do anything since its a reference field. 

This is the whole block:

 

Is it just me or does it only seem to be concerned with windows servers and not workstations?

/*
* 1. Pre sensor: You can change payload before it will be proccesed by Identification Engine.
* Use IEJsonUtility in order to add relevant information to the payload
* Input parameters in Pre sensor mode: payload, patternId
* 2. Post sensor: You can update/add missing info to the DB based on result (Json) from
* Identification Engine
* Output parameters in Post sensor mode: payload
*
*/

var rtrn = {};

//parsing the json string to a json object
var payloadObj = JSON.parse(payload);

//windows server data
var windowsServer = null;

var _isAssignedToFilled = function() {
var compGr = this.getCmdbRecord();
if (JSUtil.notNil(compGr.assigned_to + ''))
return true;

return false;
};

var setAssignedTo = function() {
var userName = windowsServer.assigned_to;

if (!gs.nil(userName)) {
var x = userName.indexOf("\\");

if (x > -1)
userName = userName.substring(x + 1);

var nameField = gs.getProperty('glide.discovery.assigned_user_match_field', "user_name");
var userID = GlideUser.getSysId(nameField, userName);

var atOverwrite = JSUtil.toBoolean(gs.getProperty('glide.wmi.assigned_to_always_overwrite', "true"));
if (!atOverwrite)
if (this._isAssignedToFilled())
return;
windowsServer.assigned_to = userID;
}
};

// };

var getMainCiFromPayload = function()
{
var itemsDiscovered = payloadObj.items;
var mainCi = null;

for(var index in itemsDiscovered){

if(Ci.extendsFromTable(itemsDiscovered[index].className,'cmdb_ci_computer')){
mainCi = itemsDiscovered[index];
break;
}
}

return mainCi;
};

var addLocationToHyperV = function()
{
var location = windowsServer.location;

if (JSUtil.notNil(location)) {
var itemsDiscovered = payloadObj.items;

for(var index in itemsDiscovered){

if(Ci.extendsFromTable(itemsDiscovered[index].className,'cmdb_ci_hyper_v_server')){
itemsDiscovered[index].values.location = location;
}
}
}
};
var mainCi = getMainCiFromPayload();

if(mainCi){
windowsServer = mainCi.values;
}


if(windowsServer){
setAssignedTo();
addLocationToHyperV();
}


//you can return a message and a status, on top of the input variables that you MUST return.
//returning the payload as a Json String is mandatory in case of a pre sensor script, and optional in case of post sensor script.
//if you want to terminate the payload processing due to your business logic - you can set isSucess to false.
rtrn = {'status':{
'message':'Windows Pre-Sensor script finished successfuly',
'isSuccess':true
},
'patternId':patternId,
'payload':JSON.stringify(payloadObj)
};