We all may be familiar with the process of transferring from patterns to probes that I outline here.

This process executes scripts that will build appropriate relationships that the full Identification and Reconciliation Engine (IRE) expects so not to create duplicate records. This is because in the old world of probes and sensors we would really only coalesce on the primary class (compute, network gear, etc) record and look at references for the supporting CI's that base class record contained.

In the world of patterns that was changed to now have the requirement to actually identify many supporting components through their own identifiers that the probes and sensors didn't require previously. If we look at the current hardware identifier in London we can actually discern between the two worlds. Identifier Entries and Related Entries.

If we focus on Identifier Entries tab you can consider this what the Probes and sensors would use to identify the base class device. Related entries were/are not used for probes and sensors So anything extended from Hardware would use these Identifier Entry rules to match on say, the compute records name only, and do its magic that Tom and Aleck always meant for us. Was a good day, we could rely on just the hardware rule, modify it for everything 'south' of hardware or even create a custom rule for a class that had special handling requirements as we did in the "horse-drawn discovery" days. All was good.

Moving to patterns

Well now came along our Patterns and their special requirements to need their own identification rules. Items such as identifying items in the Serial Number table (cmdb_serial_number) or the Switch Forwarding Table (discovery_switch_fwd_table) for network gear. This is required when building References or relationships in patterns among other things such as hosting and containment rules. We'll leave the latter out of the conversation for they really only come into play when you're creating brand new classes so we will focus on things we mess with 99.100% of the time, OOB classes. But it is important to remember the entire payload goes through the IRE, a process that promotes the accuracy and integrity of the CMDB.

We can see an example pattern step where these rules would be looked for in the Windows OS server pattern. If you look real close you will see on the form, the blank space on the right (in white font) it says this step needs an identifier rule (kidding, its not there and why I write)

So Imagine this scenario.

You have been doing discovery for the past 8 years and you are ready to switch over to patterns knowing that's the direction ServiceNow is going in its development. You have contacted support, they have run the appropriate scripts, disabled your probes in the classifiers and enabled the OOB patterns to do the good work from here on out.

NOTE: Probes and Sensors aren't going anywhere completely, it's just that all future development is focused on patterns. As of current builds, you will still need your Active Connections and Installed software probe enabled. The patterns do not collect this information, so keep them enabled.

But what you didn't think of was that you had maybe modified your OOB hardware identifier or had created an identifier for a child class from hardware. Maybe you didn't want to use the serial number table to be evaluated in the BASE CLASS identification, so you removed it or disabled it. Well when that windows server pattern runs you are going to get an error in the pattern log that reads

"Relation and/or reference table cmdb_serial_number is not a known CI Type. Check the discovery logs for more details".

This should be your first clue that there is something amiss and where we start talking about the Related Entries tab of our identifier.

These items do NOT measure the Base Class identification, they are there to support the pattern requirements in building the references and relationships and their identification requirements.

So you might be thinking, hey Doug, that's a great screenshot but our scenario we're talking about the serial number table not being needed in our Windows Server (class) identification I don't see anything about serial number table in that list.....

Well, reader, that is an astute observation. That is because that serial number table identifier is OOB over on the Identifier Entries tab. Here's where the plot twists. Patterns will use the Identifier Entries tab for the base class device identification. THEN use the Related Entries tab in combination with the Identifier Entries when looking for reference/relation identification rules.

So in our scenario when you see an error like that (or more appropriately, take the good admin steps beforehand) all you have to do is move that serial number table rule over to the Related Entries tab (if you do not want it used in your base class identification) and Voila!.

But what about custom identifiers I created? You may ask. Well as you go through the process of the transition just remember to be sure to add the entries you see in the OOB hardware Related Entries tab to your custom identifier. KEEP your primary class rule (Identifier Entries) intact, but add these others to the Related Entries.

Now as we all have some level of common sense, we know if you have a custom identifier for say your Windows Servers, Switch forwarding rules aren't going to come into play and aren't going to be needed.. But the rule of Doug says to keep things consistent. One constant is, of course, our Serial Number table example.

Hope this helps de-mystify one aspect of the IRE.