Finding unique element types in XML with PowerShell

I recently needed to deal with a large (165MB) XML file, so the first question I had is: How many unique element types are actually in the file? I found a bunch of truly painful-sounding answers online, mainly involving the distinct-values() XPATH 2.0 function. If you've ever dealt with XPATH, you know that just setting up the toolchain environment to use it is pretty labor intensive. However, I then started looking for PowerShell cmdlets that work with XML and I found Select-Xml:

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/select-xml?view=powershell-7

It looks nice enough, but it turns out that it has a few features that are really nice. Specifically, once you read in an XML document, your variable will have a Node member, and that member contains one member for each type of element in your document! So it automatically shows you the list of distinct elements. You can then maneuver through the members to find the number of each type of element ($myvar.Node.myelementType.count) or to view one of the instances ($myvar.Node.myelementType[0]), etc.

In my case, I found that my 165MB file (produced by the ITNM DLA) only contained about 17 unique element types, and that there were only about 2500 network devices, which I could then easily loop through to get the information I needed. Chained with ConvertTo-Csv, I was able to massage the data exactly as needed.

The moral of the story is: PowerShell is amazing right out of the box. I didn't have to add any new packages or anything, and it gave me precisely what I needed.

JRExecAction() function behavior in Netcool Impact

Just a short post today to set the record straight on the use of the JRExecAction() function in Netcool Impact policies.

The product documentation states that the JRExecAction() function returns nothing, but sets the variables ExecError and ExecOutput corresponding to stderr and stdout from the script/command that you run. However, the function itself returns the data written to stdout in addition to setting ExecOutput and/or ExecError. So if you try the following, you'll see that the same output is logged twice:


results = JRExecAction("/bin/ls", "/", false, 1000);
log(0,"Frank results = " + results);
log(0,"ExecOutput results = " + ExecOutput); 


Incidentally, the first use above is really the more common use in practice. You will find very few implementations where the ExecOutput variable is referenced.

How to reconfigure your ServiceNow MID server when your developer instance changes URLs

If your developer ServiceNow instance is hibernated, it may be assigned a new URL. This will break your MID server(s).

To fix this:

cd /servicenow/<midservername>/agent

vi config.xml

search for the old URL

update it

if the password has changed, put the new password in the file unencrypted. On startup, it will get encoded and encrypted.

./stop.sh

./start.sh

Go to your instance to check the status of your MID servers.

Customizing the ServiceNow Netcool Connector

UPDATE 5/1/2020

You can update this script through the ServiceNow GUI. The navigator item to select is "Script Files" under "MID Server". And the name of the script is NetcoolConnector. Edit in the GUI and it gets updated on all of your MID servers.

Background

The ServiceNow Netcool Connector (introduced at some point before the New York release) allows you to pull events from a Netcool ObjectServer into ServiceNow. The connector is a process that runs on a MID Server. Within the ServiceNow interface, there are only a few configuration options (userid/password, JDBC URL, how often to run, etc.). However, there are no filters to configure. That's because the connector is a straightforward Groovy script that you can edit as needed on the MID Server.

Details

The Netcool Connector script is found on the MID Server in the file .../agent/scripts/Groovy/NetcoolConnector.groovy. Some of the interesting parts of the script are the actual query that's run:

query = "select top 3000 Identifier,Node,NodeAlias,AlertKey, Manager,Agent,AlertGroup,Severity,Type,Summary,Acknowledged,LastOccurrence,StateChange,SuppressEscl from alerts.status where StateChange > " + lastTimeSignature + " and Manager not like '^.*Watch\$' order by StateChange asc";

That is exactly the query that's run, and you can edit it to include custom fields, for example. To complete the customization, you also need to update the createEvent() function to actually include those custom fields in the event that's created in ServiceNow. In there you can also do any hard-coded transforms that are required or anything else.

Short script to generate continuous random events to Netcool OMNIbus

So you need to generate some events to OMNIbus? It's really easy with the nco_postmsg shell script that's installed on your ObjectServer host:

while (true); do nco_postmsg -user root -password n3tc00l "Identifier='my_identifier_${RANDOM}'" "Node='mynode${RANDOM}'" "Severity=5" "Manager='nco_postmsg'" "Summary='An event occurred again'" "ImpactFlag=1" "AlertGroup='FRANK_${RANDOM}'"; sleep 10; echo sending another event; done

Update the user and password parameters, and you can add any fields you need. It simply generates an event every 10 seconds.

Why you should use MXOSINCIDENT instead of OSLCINCIDENT for creating and querying ICD incidents

In re-reading the documentation and looking through the system, I finally recognized why the MXOSINCIDENT is a much better choice for integration than OSLCINCIDENT. The OSLCINCIDENT OSLC Resource only includes 11 attributes (fields) for an incident. Those are:

modifiedBy
modified
classStructureId
title
internalPrioirity
created
creator
priority
status
shortId
identifier


and that's it. So when you GET an incident via the OSLCINCIDENT URL (.../maximo/oslc/oslcincident/...), those are, essentially, all of the fields that you'll see for that incident. For example, here is the data I retrieved for incident number 1003 in my system:

dcterms:creator
rdf:resource "http://was.gulfsoft.rocks:80/maximo/oslc/os/sccdoslcperson/_TUFYQURNSU4-"
oslc:shortId "1003"
dcterms:title "First incident"
dcterms:created "2019-11-27T10:43:18-05:00"
dcterms:modified "2020-02-11T11:10:06-05:00"
sccd:statusdate "2019-11-27T10:43:18-05:00"
rdf:about "http://was.gulfsoft.rocks:80/maximo/oslc/os/oslcincident/_SU5DSURFTlQvMTAwMw--"
dcterms:identifier "9"
prefixes
sccd "http://jazz.net/ns/ism/helpdesk/sccd#"
rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
dcterms "http://purl.org/dc/terms/"
oslc "http://open-services.net/ns/core#"
_rowstamp "17235351"
oslc:modifiedBy
rdf:resource "http://was.gulfsoft.rocks:80/maximo/oslc/os/sccdoslcperson/_TUFYQURNSU4-"
sccd:status_description "New"
sccd:status
rdf:resource "http://was.gulfsoft.rocks:80/maximo/oslc/os/sccdoslcsyndomain/_SU5DSURFTlRTVEFUVVMvTkVXL35OVUxMfi9_TlVMTH4vfk5VTEx_L05FVw--"

However, here's the data retrieved for the SAME incident using the MXOSINCIDENT URL (.../maximo/oslc/os/mxosincident/...):

spi:ticketid "1003"
spi:status "NEW"
spi:pluspporeq false
spi:virtualenv false
spi:hasactivity false
spi:relatedtoglobal false
spi:changeby "MAXADMIN"
spi:accumulatedholdtime 0
spi:selfservsolaccess false
_rowstamp "17235351"
spi:class_description "Incident"
spi:inheritstatus false
relatedrecord_collectionref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/incidentrelrec"
multiassetlocci_collectionref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/incidentmultiassetloci"
spi:isknownerror false
spi:oncallautoassign false
spi:createdby "MAXADMIN"
spi:cinum "RBA_PAYROLL"
spi:statusdate "2019-11-27T10:43:18-05:00"
spi:affectedperson "MAXADMIN"
spi:class "INCIDENT"
spi:createwomulti "MULTI"
spi:description "First incident"
ticketspec_collectionref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/ticketspecclass"
spi:creationdate "2019-11-27T10:43:18-05:00"
spi:actlabhrs 0
spi:historyflag false
spi:sitevisit false
rdf:about "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--"
spi:createwomulti_description "Create Multi Records"
prefixes
rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
spi "http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"
oslc "http://open-services.net/ns/core#"
spi:outageduration 0
spi:isglobal false
spi:multiassetlocci
0
localref "http://was.gulfsoft.rocks:80/maximo/oslc/os/mxosincident/_SU5DSURFTlQvMTAwMw--/incidentmultiassetloci/0-5"
spi:recordclass "INCIDENT"
spi:progress false
rdf:about "http://childkey#SU5DSURFTlQvTVVMVElBU1NFVExPQ0NJLzU-"
spi:langcode "EN"
spi:multiid 5
spi:isprimary true
spi:performmoveto false
prefixes
rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
spi "http://jazz.net/ns/ism/asset/smarter_physical_infrastructure#"
oslc "http://open-services.net/ns/core#"
_rowstamp "17235352"
spi:hasld false
spi:pmchgassesment false
spi:recordkey "1003"
spi:cinum "RBA_PAYROLL"
spi:externalsystem_description "EVENT MANAGEMENT"
spi:pmscinvalid false
spi:reportdate "2019-11-27T10:43:18-05:00"
spi:hassolution false
spi:actlabcost 0
spi:changedate "2020-02-11T11:10:06-05:00"
spi:status_description "New"
spi:externalsystem "EVENTMANAGEMENT"
spi:affecteddate "2019-11-27T10:43:18-05:00"
spi:template false
spi:ticketuid 9
spi:reportedby "MAXADMIN"

To me, MXOSINCIDENT provides much better data.

When you Reset Windows, Microsoft saves a list of all of the applications removed

The Windows 1909 (November 2019) Windows 10 update didn't like one of my laptops at all. After trying multiple times to upgrade to it, I finally gave up and decided to take the route of choosing "Reset Windows" and keeping all of my data. That worked on the first try, so I was already happy about that. Then I noticed an HTML file on my desktop named "Removed Apps". I opened it, and much to my surprise, it listed ALL of the apps that were deleted by the reset. Happily, I still had all of them in my Downloads folder, so I can easily re-install them. This was a happy surprise, since I was certain that the reinstall part (and figuring out everything that needed to be installed) would be the worst part of the process.