1 of 1 people found this helpful
it's not just the right way to go, it's the only way.
However, custom rules are the last step of normalization and not everything is possible there.
I would start here NE:ProductNameAlias, is the first step of a normalization process. With a % in the aliasName, it becomes a like search.
AttributeName = ModelName
AliasName = Oracle Linux 5.10
ActualName = Linux Oracle Enterprise Server 5.10
Please note that "model" is normalized here. If you really want to change the name, this step is wrong. I only use "name" very rarely to merge CIs.
Thanks for the reply Stefan -
I need to change the 'name' on the OperatingSystem class, specifically to merge CIs.
We have multiple data sources:
All feeding CMDB via Recon engine. The problem I'm having is that each of those discovery tools calls "Windows Server 2003" something different. Even though the ComputerSystem CIs get reconciled properly (for the most part)... the OperatingSystem CIs are not being reconciled... which means that each ComputerSystem has 2-3 operatingsystem relationships, the same OS , just named a little bit different. Since "Windows Server 2003" != "Microsoft Windows Server 2003" != "Win Srv 2003"
So the goal here is to normalize the OperatingSystem class "Name" fields , so Reconciliation identifies and merges properly and each computersystem has 1 operatingsystem relationship.
Red Hat Enterprise Linux 5.8 comes from ADDM
Linux Red Hat Enterprise Server 5.8 comes from DDMI
1 of 1 people found this helpful
you don't need the name to identify an OS and merge it cleanly.
Normally there is exactly one OS per computer system, it is a weak relationship (meaning that it is not identified without the parent). Therefore, you only need to adapt your identification rules and reference the classid.
Thanks for the tips ... what version of Remedy is that screenshot from? I can't seem to find a similar looking "New/Edit Identification Ruleset" on 8.1.02.
Closest thing I can find that I have is through the Standard Rules Editor -> Identification Rules
Currently I am using 9.1.03, but I am sure that I have already configured it in 8.1.02 this way. Unfortunately I don't have a 8.1.02 system anymore.
I only use the standard rules as an idea, they rarely match our data. Too often tokenid or name is used, there are often better field data.
- tokenid is useless for operating systems
- serial number together with name in your case also
To be sure, create another entry Prio 3, with' ClassId' = $ClassId$
If it works for you, you can delete Prio 1 and 2.
Thanks for the help so far, I appreciate it !
To me that still doesn't seem like it would totally solve my problems. I think it solves 1 big problem I'm having (ComputerSystems having multiple OperatingSystems).
But I think i would still have another 'problem'...
Red Hat Enterprise Linux 5.8 comes from BMC ADDM
Linux Red Hat Enterprise Server 5.8 comes from HP DDMI
If I got it down to where each ComputerSystem only had 1 OperatingSystem ... with my example ... the OperatingSystem Name seems like it change back and forth depending on which recon job ran last.
ServerABC would constantly change from
Name = Red Hat Enterprise Linux 5.8
Name = Linux Red Hat Enterprise Server 5.8
I still would need a way to 'normalize' the different operatingsystem names to get some consistency in reporting right ?
And also -
Since I'm already in the debacle of computersystems having multiple operatingsystems ... I'm thinking of ways I need to clean up.
This sound about right?
step 1) Identify all BMC_CORE_BMC_OperatingSystems in BMC.ASSET... purge them all
Step 2) Identify all BMC_CORE_BMC_BaseRelationships in BMC.ASSET where the relationship name = SYSTEMOS .. purge them all (Assuming these relationships don't get set to MarkAsDeleted during Step 1)
step 3) Set recon IDs to 0 to all BMC_OperatingSystems in ALL datasets (except BMC.ASSET)
step 4) Set recon ID's to 0 to all BMC_CORE_BMC_BASERELATIONSHIPS (where name = SYSTEMOS) in ALL datasets (except BMC.ASSET)
For reports I wouldn't use the field "name", but there are normalized fields like "category","type","item","model","versionnumber" and "marketversion". Structured information are much more suitable for reports.
Your merge activity uses a "Merge Precedence Set", where you can set the value of the information for you on dataset and field level. The field information with the highest value wins, so that the information does not change constantly.
second part - data correction.
IMHO you are almost right. I would proceed as follows
- set all BMC_OperatingSystems to markasdeleted (MAD) = yes in BMC.ASSET and purge BMC.ASSET. This automatically includes your step 2.
- Set reconid of BMC_OperatingSystems and the corresponding relationships to 0 in all source datasets except one.
- Merge this dataset first to BMC. ASSET
Important if you identify each source data set individually against your BMC.ASSET.
- Identify and merge the remaining source datasets one by one and check the result in BMC.ASSET
Unfortunately my Category / Type / Item is just as messy as the "Name", and even worse (lots of nulls).
Normalization seems to be the only way I need to do this -- but perhaps instead of creating Normalization on the "Name" .. I just need to create Normalization on the "Model" , based on a Name qualification ?
Oje, now it could get really complicated.
The normalization of CIs is always done via the fields "model", "manufacturer", "version" or if you like "marketversion" against your product catalog. Have you taken care of the product catalogue in advance? Which and how many entries do you see there for the class' BMC_OperatingSystem'? Did you allow your source datasets to create products in the catalogue?
However, if you see more than one entry for your OS example, you have a bigger task. I assume so, because at BMC_Operatingsystems I have never seen category, type, items (cti) with NULL values. At least not from the sources ADDM and SCCM.
I would now consider the following:
1. check your product catalog for Red Hat OS.
2. check your source data sets to see if they are allowed to create entries in the catalog
3. check your source data sets to see if they are filled with model, manufacturer and version.
4. check your normalization setting for your source datasets ("name only" or "name and cti")
5. if "name only", check your source data sets contents for category, type item. Have all the same content across all source datasets?
If 4 = "name only" and 5 = no I recommend you to rework your catalog, then change to "name and cti" and normalize again. The difference is that your cti will be copied from the product catalog to every CI. After that you will definitely have no more NULL values and a clean basis for your reports.
At this point I just need to stop the bleeding... and I know it can get super complicated ... which is why I was just suggesting initially how to create a normalization rule for the Name
I know it's not ideal, but in theory it should work.
I will address the other product catalog issues / etc later... but right now I'm just looking for a quick-fix.
It seems like Normalizing the "name" of the OperatingSystem will satisfy my immediate needs, right?
Taking Windows Server 2003 as an example... and ignore the fact that this isn't the most efficient way to do this ... Wouldn't this work?