Import considerations

When importing a configuration package, take note of a number of considerations and guidelines.

Back up your target Tivoli Netcool/OMNIbus installation before importing a configuration package.

Note: When nco_confpack attempts to import a configuration object, it checks whether the object already exists in the target ObjectServer. If the object already exists, nco_confpack modifies the target object to bring it in line with the object being imported. If the object does not exist in the target ObjectServer, nco_confpack creates it there. nco_confpack does not remove any object that already exists in the target ObjectServer.

This behaviour makes nco_confpack unsuitable for replicating or cloning entire ObjectServers. It is intended only for exporting and importing partial configuration data between ObjectServers. Use nco_osreport to replicate or clone entire ObjectServers.

The following considerations and guidelines apply to imports:
  • When using stdin to import the configuration package, you must use the -nowarn subcommand. This is because nco_confpack cannot read the configuration package and prompt the user at the same time.
  • When importing user, group, and role information, nco_confpack attempts to use the user, group, or role ID from the source ObjectServer. If an ID is already in use on the target ObjectServer, the next available ID is used. ObjectServer IDs do not have to match operating system user IDs.
  • If you attempt to import a user that belongs to a group that does not exist in the configuration package or on the target system, an error occurs and the user is not imported.
  • If you import a user that already exists on the target ObjectServer, but in a different group, that user will belong to both groups and will assume the permissions that are assigned to the group with the highest permission level. To ensure that the user has the correct permissions, you might need to delete the user from one of the groups.
  • You become the owner of any object that you import into an ObjectServer. The ownership of the object in the source ObjectServer is not imported into the target ObjectServer.
  • Permissions that are associated with an ObjectServer object are implicitly imported with the object; for example, the ability for a user to run SQL commands.
  • You cannot import a class from the source ObjectServer if the target ObjectServer contains a class that is defined with the same ID, but a different name.
  • You cannot import a user-defined signal if a signal with the same name, but different parameters, exists in the target ObjectServer.
  • If you import a trigger that references an object, make sure that the object either exists on the target system or is included in the configuration package. If you do not, an error occurs during the import process.
  • When importing menus and menu items, the following rules are applied:
    • Menus in the import package that do not exist in the target ObjectServer are created in the target ObjectServer. All the menu items in the package are added in the same order in which they appear in the package (which is the order that they appeared in on the source ObjectServer).
    • Menus in the import package that already exist in the target ObjectServer are merged to the target menu. Menu items in the package that do not exist in the target ObjectServer are added to the end of the target menu, in the same order in which they appear in the package. Menu items in the package that already exist in the target ObjectServer remain in the same order in the target menu, but their definitions are updated to match the package contents.
  • The configuration package stores text strings in Unicode. Therefore, if the target ObjectServer is using a different character encoding from the source ObjectServer, text will be converted from the source encoding to the target encoding. In this case, you must check the imported configuration because characters that cannot be represented in the target encoding are replaced by question mark characters (?).