Discovery of Windows servers is not going beyond identification phase

Rakesh16i · ‎04-07-2016

Hi,

We have two MID servers, with same version and same reach-ability to the IP ranges with configured to use same credentials. However discovery of Windows servers is not successful with one MID server (getting completed with status "classified"), but when discovery happens thru other MID, it could able to successfully create the CI.

I can see the following error message

'MultiProbe script error for probe `Windows - Network`: ReferenceError: "related_data" is not defined.'

Please suggest what needs to be done to resolve this issue.

Regards,

Rakesh

natem · ‎06-22-2016

The error that I'm receiving is "Sensor error when processing Windows - Identity: MultiProbe script error for probe `Windows - Network`: ReferenceError: "related_data" is not defined."

We have started experiencing this issue after upgrading to Geneva. Many CIs that were previously created no longer classify. I've looked at the old Windows - Identity Probe/Sensor and the new one... and there are significant changes to the script. Seems to me to be associated with the script for the Windows-Network Probe that runs as a part of the Windows-Identity multiprobe.

Here is the script for the newly upgraded probe:

function(ciData, debug, sensor) {

var nics = new CIRelatedList('cmdb_ci_network_adapter', 'cmdb_ci');

ciData.addRelatedList(nics);

[perhaps this is the issue???]>>> var adapters = related_data.adapters;

if (JSUtil.notNil(related_data.ip_default_gateway))

ciData.data.default_gateway = related_data.ip_default_gateway;

for(var i = 0; i < adapters.length; i++) {

var adapter = adapters[i];

var mm = MakeAndModel.fromNames(adapter.manufacturer, null);

adapter.manufacturer = mm.getManufacturerSysID();

nics.addRec(adapter);

//set the default_gateway for the computer CI:

if(JSUtil.notNil(adapter.ip_default_gateway))

ciData.data.default_gateway = adapter.ip_default_gateway;

}

This is the script for the probe prior to upgrade:

function(result, ciData, debug, sensor) {

var vips = {};

var nics = new CIRelatedList('cmdb_ci_network_adapter', 'cmdb_ci');

ciData.addRelatedList(nics);

// get our adapters and configurations...

var network_confs = g_array_util.ensureArray(result.Win32_NetworkAdapterConfiguration);

var network_adapters = g_array_util.ensureArray(result.Win32_NetworkAdapter);

buildVIPHash(vips);

for(var i = 0; i < network_confs.length; i++) {

var nc = network_confs[i];

var na = network_adapters[i];

if (parseInt(nc.Index) != parseInt(na.Index)) //Just in case Index doesn't match...

na = findCorrectIndex(nc.Index, network_adapters);

if (gs.nil(nc.IPAddress) || !nc.IPEnabled)

continue;

var ipParsed = nc.IPAddress.split(",");

var subnetParsed = [];

if (!gs.nil(nc.IPSubnet))

subnetParsed = nc.IPSubnet.split(",");

var ips = [];

for(var j = 0; j < ipParsed.length; j++) {

// The ip shouldn't be a VIP...

if (vips[ipParsed[j]])

continue;

var ip_address = ipParsed[j];

var isIPv6 = (ip_address.indexOf(":") > -1)

if (isIPv6) {

ip_address = SncIPAddressV6.get(ip_address);

if (!ip_address)

continue;

} else {

if (!GlideIPAddressUtil.isValidNicIP(ip_address))

continue;

}

var ip = {};

ip.ip_address = ip_address;

ip.netmask = (j < subnetParsed.length) ? subnetParsed[j] : null;

ip.ip_version = isIPv6 ? '6' : '4';

ips.push(ip);

}

var adapter = {};

adapter.name = na.NetConnectionID;

adapter.short_description = nc.Caption;

adapter.ip_address = (ips.length > 0) ? ips[0].ip_address : null;

adapter.netmask = (ips.length > 0) ? ips[0].netmask : null;

adapter.ip_default_gateway = nc.DefaultIPGateway ? nc.DefaultIPGateway.toString() : null;

adapter.mac_address = nc.MACAddress ? nc.MACAddress.toString() : null;

adapter.dhcp_enabled = (nc.DHCPEnabled.toString() == 1) ? true : false;

adapter.ip_addresses = ips;

var mm = MakeAndModel.fromNames(na.Manufacturer, null);

adapter.manufacturer = mm.getManufacturerSysID();

nics.addRec(adapter);

//if this nic has a default gateway configured, set the default_gateway for the computer CI:

if(JSUtil.notNil(adapter.ip_default_gateway))

ciData.data.default_gateway = adapter.ip_default_gateway;

}

/*************************************************************

* Function definitions

*************************************************************/

function buildVIPHash(vips) {

// if we have a VIPs parameter, parse it and build a hashmap of them...

var vipsParam = g_probe.getParameter('vips');

if (vipsParam) {

var vipsParamParts = vipsParam.split(',');

for (var i = 0; i < vipsParamParts.length; i++)

vips[vipsParamParts[i]] = true;

}

/*

* Win32_NetworkAdapter and Win32_NetworkAdapterConfiguration seem to always have the same

* length of array data and the order matches. But just in case it doesn't, we need to

* manually match them up by index.

*/

function findCorrectIndex(index, network_adapters) {

for(var i=0; i<network_adapters.length; i++)

if (parseInt(network_adapters[i].Index) == parseInt(index))

return network_adapters[i];

}

doug.schulze

natem · ‎06-22-2016

Looks like related_data is defined on the probe's post processor script. I'm not sure of the sequencing of how the code runs... or if variables on the probe are available to the multi-sensor script. Anyone know?

glennpinto · ‎06-22-2016

There was a big change to the method of reconciliation in Geneva. If you upgraded,you are probably using the same Discovery identification scripts that were used in Fuji, however there is a Discovery property that can be turned on called:

CMDB Identifiers: If "yes", identification and reconciliation will be handled by the CMDB API instead of through the old Discovery implementation.

If turned on, Discovery will use the new Reconciliation engine.

You may want to try to check this box and run again to see if that solves the issue, otherwise you may also want to delete the CI if it already exists in the CMDB and rediscover it.

Here is a short explanation of the the reconciliation engine in Geneva if you like.

glennpinto · ‎06-23-2016

Some other thoughts from development.

"Seems like MID Server didn't upgrade successfully, has a corrupted cache or configured differently from the other MID (credentials?). The first two might be resolved with a simple restart. Anyway, those are theories and the two input payloads (successful vs not) would need to be compared to get a better idea of what is going on"

johnnyjava · ‎06-23-2016

This happened to us too - you can force a mid to re-download the upgrade if you massage the info in agent\package\meta\mid-core.meta.properties to look like it did prior to upgrade and then restart them.

Sometimes it's simpler to just download fresh mid software and replace the config.xml and conf\wrapper-override.conf files and then start it up.