Preserved CMDB records missing after clone | How to check your CMDB sys_class_path matches on both Source and Target instanceSummarySometimes, we will have some Custom CMDB tables created on a sub-prod, then moved over to other instances for testing or even moved to Prod. If these tables weren't moved over properly, they could be created on the target instance with a different sys_class_path. This doesn't become a problem until you start trying to clone your Source instance to your Target instance WHILE trying to preserve the Target CMDB records, but they have different sys_class_paths for the tables. The issue mentioned here is, after cloning the Source instance over the Target instance while preserving those CMDB tables on the Target, the sys_db_object table will come along from the Source, which changes any table paths that may have existed on the Target instance prior to the clone. If the CMDB tables have a different sys_class_path on the Source instance, then the current Target CMDB records will have the wrong sys_class_path and will either: Not show up at all / Be missing.They show up, but under a different table that has the same sys_class_path. E.x Here is an example: Source: cmdb_ci_testing | sys_class_path = /!!/#,/$) Target: cmdb_ci_testing | sys_class_path = /!!/#,/!% The records on the target instance will be pointing to "/!!/#,/!%". When the clone occurs, the sys_db_object table is brought over from the Source instance and will change the sys_class_path for those tables. If the target instance records are pointing to "/!!/#,/!%" and the new sys_class_path in sys_db_object is "/!!/#,/$)", the records will not show up. If a different table like cmdb_ci_testing123 now uses that sys_class_path "/!!/#,/!%", those preserved CMDB records will now show under this table instead of cmdb_ci_testing.InstructionsIf the clone has already occurred, we can run a script on the Target instance to check and verify all of the bad sys_class_path records. The script will check the CMDB records and see if the sys_class_path matches on the [sys_db_object] table. This also means that if no records for a particular CMDB table exist, it won't get checked against the [sys_db_object] table. Though, the issue here is if you preserve the records and they have issues, so if a record doesn't already exist, it won't matter in this scenario. Plus, any new records created on these tables will have the right sys_class_path values. The script will be in the attachments for this article. Steps to check if this is the issue: Download the Script attachment on this KB Article.Open the script and copy it.Login to your Target instance.Use the Filter Navigator and type "Scripts - Background". Click the one under System Definition.Paste the script in the TextArea/Text Box and set the Scope to Global.Run the script. Note any output saying "Bad Path:", as this will tell you all the records that have the wrong sys_class_path. If any tables are returned with a bad path, please contact Now Support to assist in fixing the CMDB record to match the new sys_class_path values.