Probe to Pattern Migration: Frequently Asked Question Table of Contents How to determine if a migration needs to be performed?How long will it take to complete the Probe to Pattern Migration?Why does probe to pattern migration creates relationships?Is the migration stuck?Can I run the migration in dev and just move the changes via an update set?Why would the migration of windows be faster than the migration of unix, or vice versa?Why are some patterns triggered by discovery if probe to pattern migration was not done?Why are some probes still active after migration completed?Does migration need to be performed on all instances?Are there logs for the migration?Why are one or more of the migration buttons grayed out?How should custom probes in the classifiers be handled?Why does the prerequisite check fail with "Multiple Pattern Probes found for Classifier"?What if we do not have some of the default relationship type records as mentioned from the Prerequisites list?What if we do not have specific classifier records or pattern records with the names as mentioned from the Prerequisites list?Are there any System Properties affected by this change?What should be done if there is an error that occurs during the migration process? What logs should be collected?Prerequisite check fails with error "Name mismatch. Current name is" How to determine if a migration needs to be performed? Navigate to "Discovery → Migrate Probes To Pattern"Click on "Run Prerequisite Check"The Prerequisite check will: Turn gray the buttons for migrations already performedKeep active buttons for migrations that need to be performed How long will it take to complete the Probe to Pattern Migration? As listed in the Probe to Pattern procedure KB (KB0694477), the migration does the following: Add the appropriate relationships needed for pattern Discovery to continue to identify the current CIs that are being discovered via probes.Update certain relationships that may have different relationship types or have different parent/child values.Update the appropriate Discovery Classification records (discovery_classy) to convert the Triggers probes records (discovery_classifier_probe) to use pattern-related probes The time taken for the first item above will depend on the size of the CMDB. Therefore, the larger the CMDB the longer it will take to complete the migration. Additionally, most instances will have their own customizations which can cause the migration to take longer. It is hard to predict how long it will take for the migration to complete. Testing should be done on a recent clone of production and with similar overall size of the CMDB for a good estimate. Why does probe to pattern migration create relationships? Probe discovery only used the identification and reconciliation engine (IRE) for the creation and update of independent CIs, dependent CIs were created mostly via the DiscoveryReconciler script include. Once an instance is migrated to pattern discovery it will also send the dependent CIs to the IRE. The IRE uses the cmdb_rel_ci table to find the existing dependent CIs. The IRE will not be able to find the dependent CIs without the creation of the necessary relationships, and therefore duplicate dependent CIs may be created. In summary, these relationships are necessary to avoid potential duplicate CIs once the migration is complete. Is the migration stuck? Each migration runs a specific script to create the necessary relationships and migrate the required classifiers. The migration may seem stuck when running on a large CMDB, however it is not. The larger the CMDB the longer it should take to complete the migration. It will take longer to complete migration in Prod if Prod is larger than Dev or QA. The progress of the migration can be reviewed by looking at the respective probe_to_pattern_log log and checking the last time it was updated. Active transactions can be seen under v_cluster_transaction_list.do with name ProbeToPatternMigration. Can I run the migration in dev and just move the changes via an update set? No. The migration creates relationships between the CIs. Therefore, the migration must also be performed in production. Why would the migration of windows be faster than the migration of unix, or vice versa? The time taken for the migration to complete will depend on the size of the tables being migrated. As such it is not expected that all migration should take the same amount of time. For some instances windows might complete faster, while for others unix migration may be faster. Why are some patterns triggered by discovery if probe to pattern migration was not done? Some newer classifiers, and newer process classifiers, have always used patterns. As such, these will use patterns even before the migration and migration is not necessary for those. A list of classifiers that are migrated can be found in the prerequisites section (item 5) of KB0694477. Why are some probes still active after migration completed? Not all classifiers will have a pattern. A list of classifiers that are migrated can be found in the prerequisites section (item 5) of KB0694477. Does migration need to be performed on all instances? The migration should be performed first in a non production instance. Once working as expected then it can be run in production. Once production is cloned over any instance there is no need to run the migration on an instance which production was cloned over. Are there logs for the migration? Yes. The migration logs can be found in table probe_to_pattern_log. Why are one or more of the migration buttons grayed out? The "Run Prerequisite Check" will only make available the migration of classifiers that have not been migrated yet. If the check finds that a classifier was already migrated it will gray out the migration button for that classifier. How should custom probes in the classifiers be handled? The migration process is intended to set up the instance to use patterns as if we are enabling Discovery for the first time. By default, any custom probes that may have been added to a classifier that we are migrating will be made active = false.This is to help prevent any potential issues that may arise with data being discovered by these custom probes interfering with new data being discovered by patterns. These custom probes can always be re-activated by navigating to the respective classifier and set the Triggers probe record back to active = true. Why does the prerequisite check fail with "Multiple Pattern Probes found for Classifier"? This error can happen when a classifier already has a pattern configured. To resolve this please review the classifier mentioned in the error and set the pattern to active = false, or remove the pattern from the triggers probe list (always test in non production first). What if we do not have some of the default relationship type records as mentioned from the Prerequisites list? In the Script Include FixPatternsModelBasic, this is where these relationships are defined as such. If any of these relationships are missing, we need to reinsert the default versions of these records.This can be done by seeing if the missing records are existing in the deleted records table (sys_audit_delete) and then restore the deleted records or if possible you may need to request Technical Support to import the missing records from an out-of-box instance. If any of these relationships are existing, but instead have a different sys_id value, the recommendation is to restore the default version of the relationship if possible and remove the custom version.This may also include having to update any existing relationship records (cmdb_rel_ci) that may be using this custom relationship type to instead use the default value. However, if this is not possible, then this FixPatternsModelBasic script will need to be manually updated to replace the default value with the custom value that is being used.For example, if you have a record for the relationship Runs on::Runs, but with a different sys_id (ex. 517ab95338a02000c18673032c71b904), then you will need to replace the appropriate variable value to reference this new sys_id value like below. this.RUNS_ON = "517ab95338a02000c18673032c71b904"; What if we do not have specific classifier records or pattern records with the names mentioned in the Prerequisites list? One example would be if instead of Windows 2008 Server, there is using a custom classifier called Windows 2008 Custom In the individual "Fix" Script Includes (ex. FixWindowsModelForPatterns, FixUnixFamilyModelForPatterns, etc.), the migration process converts the classifiers from probes to patterns using function calls like this below. migrate.enablePattern('windows', 'Windows 2008 Server', 'Windows OS - Servers'); This function call passes three parameters: The first parameter helps to identify which discovery_classy table we are targeting against (ex. discovery_classy_windows).The second parameter tells us which classifier record we are targeting against (ex. Windows 2008 Server).The third parameter tells us which pattern we should use if we need to create a new discovery_classifier_probe record to trigger the pattern (ex. Windows OS - Servers). If there is a different classifier record that needs to be updated or if the pattern has a different name, then this function call can be modified to pass in the appropriate values.For instance, if in this example mentioned above we need to use Windows 2008 Custom instead of Windows 2008 Server, you can make the following change: migrate.enablePattern('windows', 'Windows 2008 Custom', 'Windows OS - Servers'); Or, if the pattern that is being used is also different then you can change to something like this: migrate.enablePattern('windows', 'Windows 2008 Custom', 'Windows OS - Custom'); This should only be done if you are using customized classifiers or patterns and are not using, or no longer have the out-of-the-box classifiers or patterns. Are there any System Properties affected by this change? There is a System property named glide.discovery.ip_based.active that will get set to a value of false when these migration scripts are run.This property is mainly a reference that Discovery is now using patterns instead of probes. What should be done if there is an error that occurs during the migration process? What logs should be collected? When running the migration scripts, most of the details about what is happening during this process will get logged in the syslog table and will have a Source value of DiscoveryMigrateToPatterns.See example screenshot below. Starting in Orlando, there is also a new log table (probe_to_pattern_log) where this log information will be stored as well. Please refer to KB0781470 for more details. Investigating these log details, along with looking into other typical node logs, can be helpful to see when and where any issues may occur. If further assistance is needed, you can open a case with Technical Support to investigate accordingly. Prerequisite check fails with error "Name mismatch. Current name is" The script include AbstractDiscoveryMigrationHelper expects some values to be in English. Therefore, it is best to perform the migration with a user who has the default language set to English: Create a new user with the admin role and the language as English.Log in with that user to the instance and change the instance language setting to English.Rerun the pre-requisite check.