Setting the attribute permissions is an optional step in the Class Manager user interface (UI) of BMC CMDB. If you do not set the permissions, the default permission groups are applied by BMC CMDB.

You cannot set attribute permission using regular or computed groups from the CMDB Portal because a validation in CMDB engine allows only dynamic groups or roles to be associated with attributes. You must use the CMDB Driver commands or CMDB APIs to set the attributes permissions for regular or computed groups.

However, you can use the following workaround to set the attribute permission to certain regular or computed groups:

Use the existing computed groups and extend them to cover the regular groups. .

For example, if you want users of Group A, which is a regular group to change the data of a specific attribute, then Group A can be added to the existing CMDB Data Change Group, which is a computed group by using the following qualifications in the AR Group form:  

"Administrator" OR "CMDB Console Admin Group" OR "Asset Admin" OR "Request Catalog Manager" OR "Business Analyst" OR “Group A”

This method will regularize the CMDB permissions structure without changing the out-of-the-box permission model.

For information about modifying attribute permissions by using the CMDB Class Manager, see Creating-or-modifying-classes-by-using-Class-Manager.

For information about creating groups, see Creating groups .

For more information about regular, computed, and dynamic groups, see AR System: Regular, computed, and dynamic groups.

The classes and attributes provided out of the box cover most business scenarios. The structure of these classes and attributes, with the relationships, is available as the common data model (CDM).

However, if the out-of-the-box classes do not cover the scenarios for your business, you can extend the data model. Extend the CDM by either creating your own classes or extending an existing class with additional attributes.

For information about modifying the common data model, see Modifying-the-data-model-by-using-Class-Manager.

The options available are Quick Search and Advanced Search. Quick Search is the basic search, which helps you search for CIs quickly, based on the parameters you specify. With Advanced Search, can use template queries or build your own custom query.

Yes, you can search for CIs that are Marked As Deleted, by performing the following steps:

1. On the Search Widget, select Quick Search.
2. Select the dataset and class.
3. In the Attribute field, select MarkAsDelete.
4. In the AttributeValue field, enter 1, to show all CIs that have the MarkAsDelete attribute set as True.

Yes, Wildcard % is supported in search.

To search for a parameter type the string. By default, the wildcard character % is appended automatically to the end of the search string, while is the search is being run. The search returns all values starting with the search string you entered. For example, if you enter the string as Comp, the search returns values like Computer, Comp12, ComputerSystem, and so on.

However, if you want to search for CIs containing a particular string, you can place % anywhere in the search string to use as a wildcard.  For example, %system returns results like ComputerSystem, Computer_System,  AdminSystem, and so on.

When a large number of CIs (example 50K) are added to the production dataset, it takes few minutes for the CI Updates page to reflect the changes. That is because at the backend while the CI information is getting updated, it takes time to update the CMDB Portal. Hence, sometimes even after adding CIs or updating CIs, you might see the added or edited number of CIs as zero on the page.

See, Viewing-updates-to-CIs.

This error is displayed if you click a CI's link to view its details, but the CI has already been deleted. However, you can still view the details of a deleted CI. An example of the Integrity page from which the link to the CI details can be accessed is shown in the following figure:

When large datasets are displayed on CMDB Explorer, the canvas may look cluttered with too many CIs. Use Group CIs, Filters, Remove CIs options to simplify the view. For more information to simplify the CMDB Explorer view, see Searching-and-viewing-CIs-and-relationships-in-CMDB-Explorer.

Perform the following steps to create a custom group.

1. Click Drag Mode to switch to Select Mode.
2. Hold your left mouse button on the canvas and draw your selection to include CIs that you want to group.
3. Click Group Selected CIs. The Custom group is created.
4. Click Drag Mode again.

However, there are restrictions for including a CI as part of a custom group, which are listed as follows:

a. You cannot add an already existing group of CIs to a custom group.
b. CIs that are children of another group cannot be added to a custom group.

Yes, use the following options to manage the CIs that are displayed in CMDB Explorer:

• Filters to include or exclude.
• Remove CIs.

In the CMDB Portal, filtering is simplified and you can achieve the same results by checking only those classes and relationships that you want to view on the Explorer canvas. The Filtering options are as shown in the following figure.

When you create a filter, you can also determine whether that filter can be used by others or only by you.

If Is Global is ON, the filter is saved as a shared filter and is available to everyone. If Is Global is OFF , the filter is saved as a Personal filter and it is available only to you.

You can also use the Remove CIs option to exclude specific CIs from the Explorer canvas.

For more information, see Searching-and-viewing-CIs-and-relationships-in-CMDB-Explorer.

Yes, right-click a CI and use the Collapse option to collapse the Parent or Children CIs. 

For more information, see Searching-and-viewing-CIs-and-relationships-in-CMDB-Explorer.

Reconciliation Engine is a component installed with the BMC CMDB. The main function of the Reconciliation Engine is the creation of a production dataset that contains accurate data from all available sources. Data in the production dataset is then used by consuming applications.

For more information, see the following resources:

Before you run a Reconciliation job, perform the following:

• Perform CDM metadata diagnostics - Run the CDMChecker utility to:
  • Detect invalid customization
  • Detect CDM corruption
    • For information about running this utility, see Troubleshooting-issues-when-using-the-CDMChecker-tool.
• Perform data diagnostics
  
  • Run the cmdbdiag utility to check if data conforms with the model defined in BMC CMDB and correct it. For information about using this utility, see Verifying-your-data-model.
• Perform Reconciliation Engine-specific data diagnostics
  
  • Run the Data Analyzer tool to check whether the data follows the RE-specific guidelines. BMC highly recommends you to run this tool before running any RE job. See Using-CMDB-Data-Analyzer-to-investigate-CMDB-data-issues.
• Perform manual checks for RE jobs
  
  • Make sure that all the classes and attributes used in standard or custom rules of all the RE jobs exist in your CDM data model. If a certain job is imported in your CDM, the job might fail.
  • Make sure that the data sets (source, target and precedence data set) referred in all the RE jobs also exist in the BMC_Dataset class.
• Check whether indexes are set
  
  • During upgrade, for optimal RE performance, ensure that the out-of-the-box indexes set up on BMC.CORE:BMC_BaseElement and BMC.Core:BMC_BaseRelationship forms.Discrepancies, if any, are logged in the Atrium Installer log file. The following image displays an example message:
    

Watch the video on Reconciliation Engine best practices:

https://youtu.be/8dykPDe2GDU

For more information about best practices for effective reconciliation process, see Reconciliation-best-practices.

Configure recommended settings

Ensure that the System-level settings and Job-level settings are configured as per the recommendations. See the following images for recommended settings:

System-level settings 

Job-level settings

For more information, see Reconciliation-Engine-configuration-settings.

You should consider changing the default configuration settings in the following scenarios:

• If you are dealing with large volume of data, increase the value of the Definition Check Interval field.
• If you need specific log details, ensure that you change the log level to Debug. (Change the default log value only when you need and reset it back to default log level when you are done). Additionally, set the Maximum Job Log File Size value to 50000 KB.
• If the RE Job is not responding for a long period, set Job Idle Time value to the desired time other than the default value (0).

Standard identification and precedence rules simplify the process of creating reconciliation jobs. Standard rules use defaults for Identify and Merge activities and automate the creation of reconciliation jobs.

The standard rules work with all classes in the Common Data Model (CDM) and BMC extensions. They identify each class using attributes that typically have unique values, and they merge based on precedence set for BMC datasets. Standard reconciliation jobs always use these standard rules, but you can also use standard rules when you create your own reconciliation job.

You must use standard rules:

• When configuration items are published into the CMDB or when the data is pulled from the CMDB.
• To uniquely identify attributes of the discovered configuration items.

A set of rules that are created as per your specific business requirements and are not part of the standard rules are termed as custom rules. You can use custom rules for CI classes.

The following is an example scenario in which you might want to create custom rules:

If you have extended the Common Data Model by adding a new attribute, which is specific to your requirement and which might not be populated by any discovery tool. You might want to define custom rules to identify your assets based on this attribute.

For more information about using custom rules, see Configuring-reconciliation-identification-rules.

Standard identification and precedence rules simplify the process of creating reconciliation jobs. A reconciliation job is provided with a standard rule sets of identification and precedence rules.

These standard rules work with all classes in the Common Data Model (CDM) and BMC extensions. They identify each class using attributes that typically have unique values, and they merge based on precedences set for BMC datasets. Standard reconciliation jobs always use these standard rules, but you can also use them when you create a custom reconciliation job.

For more information, see Standard reconciliation jobs.

Watch the following video:

For more information, see Creating-precedence-sets-and-associations-for-reconciliation-merge-activities .

• Do not set a Reconciliation Engine ID manually in any dataset.
• Do not manually delete data, which is marked as soft delete.
• Do not delete datasets manually. You must also need to clean up dataset references from Reconciliation Engine, Normalization Engine etc.

For most reconciliation activities, you can specify a qualification set for the purpose of restricting the instances that participate in an activity. Qualification sets, which are reusable between activities, are qualification rules that each select certain attribute values. Any instance that matches at least one qualification in a set can participate in an activity that specifies the qualification set.

For example, you might create a qualification set that selects instances that were discovered within the last 24 hours and have the domain "Frankfurt" if your company just opened a Frankfurt office and you are reconciling its discovered CIs for the first time.

• For more information, see Creating-qualification-rules-for-reconciliation-activities.
• For information about conventions to be used in qualification of Reconciliation Engine activity, see Qualification-conventions-for-reconciliation-activities.

The CMDB Data Analyzer is a collection of tools that enable you to perform data analysis and also identify  data inconsistencies  in any CMDB dataset.

For more information, see Using-CMDB-Data-Analyzer-to-investigate-CMDB-data-issues .

Normalization process helps maintain consistency and standardizes the CMDB data. Hence, as a best practice, we recommend that you must reconcile only those CIs that have been normalized or those that do not require normalization. To reconcile the appropriate CIs, enable the Process Normalized CIs Only option while creating a reconciliation job. For more information about normalization, see Managing-consistency-of-CMDB-data-by-using-normalization.

To reconcile manually created CIs, perform the following steps:

1. Create a custom job.
2. Define the job for the classes in which you populate the data.
3. Identify the CIs. 
   
   1. Ensure that you adhere to the identification rules for the discovered jobs so that your CI matches with the discovered CIs.
   2. Ensure that you populate at least those columns/attributes correctly that are defined in the identification rules (This helps in correct identification of the CI with the existing CI)
4. Set a lower precedence value for the manual dataset, but set a highest precedence to the manually edited columns/attributes of the dataset.

CIs are partially merged when the merge process fails due to data issues.

See the following flowchart that explains the checks to be performed if the CIs are partially merged:

 Run the CMDB Data Analyzer utility to find duplicate CIs. See Using-CMDB-Data-Analyzer-to-investigate-CMDB-data-issues.

Run Reconciliation Engine's (RE) Identification activity across multiple datasets. For example, open the BMC.CORE:BaseElement form and enter the RE ID value and search. If a CI having the same RE ID is found in multiple datasets, it means that the same CI exists in those datasets. 

Run the CMDB Data Analyzer utility to find orphan CIs. See Using-CMDB-Data-Analyzer-to-investigate-CMDB-data-issues.

The following table lists the common RE issues and provides access to relevant resources and workaround to these issues.

From BMC Helix CMDB version 21.02, migrate the reconciliation jobs by using the Reconciliation Job Export utility. For more information about the utility, see Exporting reconciliation job definitions.

The Reconciliation Engine process terminates because:

• The AR System server or database is busy and is unable to process the requests coming from RE.
• The AR System server is either not responding or not reachable.

In the above scenarios, RE awaits for a response from the AR System server and then terminates itself.

For more information, see the Knowledge Article number 000224175.

Perform the following:

• Check whether the job schedule is deleted or modified.
• Check if the job listed under Queued Jobs on the Manage Reconciliation page.
• Check whether the Application Pending form has an entry for that job.
  • If there is no entry for that job, enable the AR API, SQL and Filter logs.
  • If the entry exists, check the AR Dispatcher log.
• Check whether RE is registered with the AR Dispatcher.
• Check the number of entries in the Application Pending form.
  • If there are many entries in the form and if you do not need them, delete those entries from the form.
• Check whether the RE job entry is in the Queued state in the RE job run. If yes, delete the entry from the Queued state.
• If you are using RE in a server group environment, ensure that the Reconciliation-Engine-Suspended flag is set to False (F). Note: You cannot set this value manually.

Perform the following:

1. Enable server-side logs.

   1. Edit the log4j.properties file located in the <AR_Installation_Home>\midtier\WEB-INF\classes folder. Add the following lines:

      log4j.rootLogger=DEBUG, atrium   log4j.appender.atrium=org.apache.log4j.RollingFileAppender   log4j.appender.atrium.File=C:/Program Files/BMC Software/ARSystem/midtier/logs/atrium-ui.log   log4j.appender.atrium.MaxFileSize=25MB   log4j.appender.atrium.MaxBackupIndex=10   log4j.appender.atrium.layout=org.apache.log4j.PatternLayout   log4j.appender.atrium.layout.ConversionPattern==%d[%t] %-5p %C{1} - %m%n

      and

      log4j.logger.com.bmc.atrium=DEBUG   log4j.logger.com.bmc.bsm.atrium= DEBUG   log4j.logger.com.bmc.atrium.flex.ds= DEBUG

   2. Edit the <AR_HOME>\ARSystem\midtier\WEB-INF\AtriumWidget\flex\services-config.xml file.
      
      In the services-config.xml file, modify the logging level from Warn to Debug. 
      
      For example, change the following line:
      <target class="flex.messaging.log.ConsoleTarget" level="WARN">
      To
      <target class="flex.messaging.log.ConsoleTarget" level=“DEBUG">
2. Enable client-side logs.
   For information about enabling client-side logs, see Enabling-API-and-web-services-logs.

 See Knowledge Article number 000276842 .

Recent versions of modern browsers are starting to enforce more privacy-preserving defaults and are changing the way cross-site cookies are handled. 

Remedy Single Sign-On relies on cookies to enable your users to seamlessly access all integrated applications. As browsers implement changes to their default SameSite attributes, cross-site cookies will not be sent by default. As a result, your users will be prevented from accessing your applications.

To continue to use Remedy SSO with newer browser versions, you must do the following:

• Use the secure HTTPS protocol for all of your applications.
• Upgrade to Remedy SSO 20.02.
• Set the following configuration options in Remedy SSO:
  • Enable Secured Cookie
  • Use Cross Site Cookie

For instructions, see Configuring settings for Remedy SSO server.

Note: If you subscribe to Remedy SSO 20.08 and later releases (SaaS), no action is required. BMC will update your configuration.