Administer > Content utilities > Importing deleted content

Importing deleted content

If you have specified that content be marked as deleted during an export, running the
--delete option on import will delete those marked items from the destination mesh.

In some cases, however, if the content marked for deletion in the destination mesh is being used by parts of the SA model, DET will take a ‘no harm’ approach by renaming the content item instead of deleting it. Or, if you used the -del option during export but did not use the -del option during import, then any content items marked for deletion in the export will not be deleted in the destination mesh — they will instead be renamed.

When a content item is renamed in the destination mesh, the following naming convention is used for the renamed item:

<item_name>-cbtDeleted<12345>

For example, if Application Configuration “foo" is renamed during one DET run, it would be renamed to “foo-cbtDeleted134234".

Condition for content items to be deleted upon import with the -del option describes all conditions that must be met for a content item to be deleted on an import, and those cases in which the content item will be renamed. If the conditions for allowing delete are not met, then the item will be renamed according to the renaming convention.

For some content items, there are no restrictions and they will always be marked as deleted when the delete option is used for both import and export. For other content items, deletion will never be allowed.

Renamed objects that cannot be found

When a content item is renamed for any reason (no -del or “do no harm’"), it may become un-findable by DET on subsequent imports. This reason for this is that the name by which the item is located in the destination mesh has been changed due to the rename.

For example, if Application Configuration “foo" is renamed during one DET run to “foo-cbtDeleted134234", on subsequent runs the DET will attempt and fail to find an Application Configuration named “foo". This will prevent the DET from re-renaming or deleting the Application Configuration.

Types of objects with dependencies that can become unfindable after they get renamed include Application, Application Configuration, Application Configuration file, Compliance Selection Criteria, Custom Extension, Distributed Script, OS, Patch Policy, Server (Device) Group, Service Level, Template.

Condition for content items to be deleted upon import with the -del option

Object type

Conditions allowing delete

Application Configuration
  • In use by zero servers or device Groups.
  • In use by zero software policies.

Application Configuration File

In use by zero application configurations.

Compliance Selection Criteria

Always allow delete.

Custom Extension

Never allow delete; always rename.

Custom Field Schema

Always allow delete.

Customer
  • Zero application, service level, and template nodes.
  • Zero non-deactivated devices.
  • Zero packages (including those with status DELETED).
  • Zero IP range groups.
  • Zero folders.
A Customer cannot be deleted if it has any packages still in SA, including those with the status DELETED. When an object has a DELETED status, it means that either a) the package is still needed for remediation operations on at least one server, or b) the Satellite Software Repository Cache has not yet flushed the package. If this is the case, then the Customer marked for deletion will not be deleted, but renamed.

Deployment Stage Value

Zero devices using this value.

Folder

Zero contained packages, software policies, and sub-folders.

OS
  • Zero attached devices.
  • Zero child nodes.
  • Zero templates or device Groups include this node.

Package

Is a deletable unit type (see below)

  • Zero Solaris patch clusters or MRLs use this package.
  • Zero software policies use this package.
  • If a ZIP package, it has zero child relocatable Zip.
  • Zero OS definitions or application nodes use this package.
  • Zero software policies use this package.

If a patch:

  • Zero devices attached to the patch node.
  • Zero templates or device Groups include the patch node.
  • Zero patch policies or patch exceptions include the patch node.

If an LPP, HPUX depot, or Solaris package:

  • Zero sub-packages in use by software policies.
  • Zero OS definitions or application nodes use any sub-package.
  • For any sub-package that is a patch:
    • Zero devices attached to the patch node.
    • Zero templates or device Groups include the patch node.
    • Zero patch policies or patch exceptions include the patch node.

Deletable package unit types* (see list following this table)

Patch Policy
  • Zero attached devices.
  • Zero attached device groups.

Server (Device) Group
  • Zero attached devices.
  • Zero child nodes.
  • Not used by access control.
  • Zero dynamically bound jobs.

Server Use Value

Zero devices using this value.

Service Level
  • Zero attached devices.
  • Zero child nodes.
  • Zero templates or device Groups include this node.

Template

Zero child nodes.

User Group

Always allow delete.

* Detectable package unit types:

  • HOTFIX
  • HPUX_DEPOT
  • LPP
  • MRL
  • MSI
  • PROV_INSTALL_HOOKS
  • RPM
  • SERVICE_PACK
  • SOL_PATCH
  • SOL_PATCH_CLUSTER
  • SOL_PKG
  • SP_RESPONSE_FILE
  • UNKNOWN
  • UPDATE_ROLLUP
  • WINDOWS_UTILITY
  • ZIP

Send Help Center feedback