@Cameron13 I like your reply!
@Smily Kasukurth
While the other replies are answering technically, they are not really covering the process of figuring out what should be Principal.
The CI classes tagged as Principal Classes should be highlighted in your configuration management plan as 'managed' classes. In a CMDB where automated discovery is active, you will always have a lot of classes that provide some useful information, but are not critical. Other classes will be essential to your CMDB such as Servers, Network Gear, Databases etc (as examples). What makes any of these classes essential to your CMDB are the use cases that you are trying to support. If you want to support ITSM (Change, Incident, Problem), then what typoes of CI's do you need to include. If you want to use the CMDB to support Vulnerabuility Response, what CI classes are you scanning for vulnerabilities? Think about the other use cases, and compile a list of classes (and critical attributes) that you need to have to support them. These will be your "managed" or "principal" classes.
Once you identify those managed classes, the next step is to ensure that your data governance is applied to data in those classes. You will want to make sure that the data is validated, audited, cleaned-up etc. The more mature your process gets, the more classes you can successfully manage. Don't try to do too much too soon though.
Once you are confident that the data in those managed classes is accurate, then it makes a great candidate for a Principal class, users trying to add a CI to an incident will have a high success rate in trying to find what they are looking for. CI matching for Vulnerability Repsonse or CI binding in Event Management will all work great.
So, Principal classe filter is really useful, but managing the lifecycle of the data in those classes is the critical part. You don't have to have all of the process behind it, but it will give you much better outcomes
Regards,
David
