, security
of deployment archives , and references to third-party namespaces .When you deploy, you must consider how to handle security and whether to deploy the entire content store or to deploy selected packages, folders, and directory content. Other considerations relate to the database vendor, bursting reports and ownership of entries.
To avoid breaking references in the target environment, you must deploy all entries that refer to entries in another package or folder. Entries to consider include:
jobs, shortcuts, and report views
memberships and entry permissions
Before you deploy, you must consider access permissions , security
of deployment archives , and references to third-party namespaces .
The entries that you deploy may have security applied to them,
such as access permissions that specify which users and groups
can access them. If you deploy the entire content store ,
all access permissions are deployed. If you deploy selected packages,
public folders and directory content, you can choose whether to
deploy access permissions .
Consider the following:
Referenced users and groups
If you deploy access permissions to a target environment, the referenced users and groups must exist in the target environment.
Access permissions rules
For access permissions to work after entries are deployed, the source environment and the target environment must use the same authentication provider with the same configuration. Otherwise, the permissions may not work after deployment.
Use the Cognos namespace to ensure that the permissions from the source environment work in the target environment. For example, in the source environment, create Cognos groups with the group Everyone as a member, and then set access permissions for the groups. After deployment, in the target environment, map the Cognos groups to the appropriate users and groups from the authentication provider, and then remove Everyone from the groups membership.
For information about deploying Cognos groups and roles, see Including Cognos Groups and Roles.
A deployment archive can contain sensitive information, such as
signons and confidential account or credit card numbers in report
outputs. When you export, you can encrypt the deployment archive
by setting a password. Later, when you import, you must type the
encryption password. The password must contain eight or more characters.
You must encrypt the deployment archive when it contains data
source signons or when you deploy
the entire content store .
The encryption settings are configured in the configuration tool. For more information, see the Cognos 8 Installation and Configuration Guide.
Some entries, such as groups, roles, distribution lists, contacts, data source signons, and some report properties, such as email recipients and report contacts, can refer to entities in third-party namespaces. When you deploy public folders and directory content, you can deploy these entries with or without the third-party references.
Consider the following:
Included references
If you include the references to third-party namespaces, the system verifies that each of the referenced entities exists in the third-party namespaces. Therefore, you must ensure that you are logged on to each third-party namespace, and that you have the necessary permissions to access the required entities in the namespaces. If you cannot access the third-party namespaces, you will encounter errors during the deployment.
No included references
If you do not include the references to third-party namespaces, the referenced entities are removed from the membership list of groups, roles, distribution lists, and data source signons and other properties where they may exist.
When you deploy the entire content store ,
all references to third-party namespaces are included.
Deploying the entire content store ensures that all packages, folders, and directory content are copied to a new location. For example, if you are changing the computer where Cognos 8 is installed, you can move the entire content store from the old environment to the new environment and keep all the reports and other entries created by administrators and users.
Other reasons to deploy the entire content store include
moving a whole application into a new, empty environment, such as a new computer, from a development environment
refreshing a whole application into an existing environment, such as an existing computer, from a development environment
moving an application from an existing environment that uses a different underlying technology, such as a different database type for the content store, or a different operating system
upgrading the contents of the content store
When you move a content store from one environment to another, you must use the same namespaces for policies, users, roles, and groups to work correctly.
When you deploy the entire content store, if there are no conflicts, the contents of the target content store are removed and replaced by the contents of the source content store, except for configuration data. The imported entries keep the owners from the source content store. For information about conflict resolution, see Conflict Resolution Rules.
After the deployment is complete, some links for packages associated with reports may not work. You may need to relink packages to reports. For information about linking packages to reports, see the documentation for the studios.
Tip: Instead of deploying the entire content store, you
can deploy only specific public folders and directory content .
The content store includes all entries in the portal, such as:
public folders
packages
reports
data sources
distribution lists and contacts
printers
schedules
the Cognos namespace
deployment specifications
It does not include the deployment history . Configuration objects such
as dispatchers, are included in exports by default, but excluded
in imports.
If you want to deploy users’ personal folders and personal pages, you must choose to include the user account information when you export and import.
When you export an entire content store, the export and import deployment specifications that exist in the source content store are exported. Their deployment histories are not exported.
Later, when you import the entire content store, you also import the export and import deployment specifications. You do not see entries in the View the deployment history page for the imported specifications.
If any of the imported deployment specifications are used for an encrypted deployment archive, you can delete them. To import an entire content store the first time, you must create a new import deployment specification.
By default, the information saved in deployment records includes
the progress and summary reports only. If you want to include more
detailed information, change the recording level using the advanced
setting CM.DEPLOYMENTDETAILENTIRECONTENT. Use the steps in Set Advanced Content Manager Parameters.
More recording levels are available in partial deployment .
When you import an entire content store, configuration data is
included in the export, but excluded from the import by default.
We recommend that you do not change this setting. However, if you
must import configuration settings, you can change the default in
the Advanced Settings .
If you import the configuration data, especially in a distributed environment with multiple content managers, the current information about the content manager status may be overwritten by the imported data.
Tip: If you import the configuration, restart the service in the target environment to update status information properly.
For information about including configuration data in the import, see Include Configuration Objects in Import of Entire Content Store.
For information about how specific objects in the content store are imported, see Rules For Deploying the Entire Content Store.
You can choose to do a partial deployment, deploying
only selected public folders and directory content, rather than
the entire content store .
You can deploy any packages and folders in Public Folders. Browse the Public Folders hierarchy and select a package or folder. This will deploy its entire contents. You cannot select specific entries in the packages or folders. During export, the parent packages and folders are not exported and Content Manager does not create placeholder locations for them in the target environment. During both export and import, you can specify a new target location in the Content Manager hierarchy for each deployed package and folder.
The directory content that you can deploy includes the Cognos namespace, distribution lists and contacts, and data sources and their connections and signons.
For information about how specific objects in the content store are imported, see Deployment Rules When Importing.
After the deployment is complete, some links for packages associated with reports may not work, even if you included packages and their reports in the deployment. You may need to relink packages to reports. For information about linking packages to reports, see the documentation for the studios.
Tip: If you want to deploy specific entries, you can create a folder at the root level of Public Folders, copy the specific entries to that folder, and select this folder when you deploy.
A package is an entry that contains published reports and metadata. Packages are created in Framework Manager, the modeling tool, and then published to Cognos Connection. Packages are stored in the content store and appear as entries in Cognos Connection.
During a partial deployment , you can deploy one or more packages at a
time. A package can reference objects that are outside the package,
such as security objects, data sources, and distribution lists.
However, referenced objects are not deployed with the package.
While you are importing, you can deselect packages in the deployment archive that you do not want to import.
During a partial deployment , you can rename packages and folders so that
they have a new name in the target environment. This is useful if
you do not want to overwrite a package or folder that has the same
name in the target environment. The original package or folder remains intact,
and the deployed one is renamed.
You might also want to add multilingual names for packages and folders so that users can see names suitable for their locale. A locale specifies linguistic information and cultural conventions for character type, collation, format of date and time, currency unit, and messages.
Before you rename packages, you consider the information about renaming entries and what happens to associated references to other entries in Organizing Entries.
During a partial deployment , you can disable the packages and folders
in the target environment so that users cannot access them. Disabling
packages and folders is useful if you want to test them in the target
environment before you make them available to users.
You can disable packages and folders at the time of export or import.
When you disable a package or folder, the entries it contains are not accessible in the target environment after the import. Users cannot run, view, or edit entries. Only users who have write privileges to the disabled entries can access them. For more information, see Disable an Entry.
During a partial deployment , when you export and import, you can choose
the following options. If you do not select an option when you export,
it is not available during import.
You can choose to include the report output versions in your deployment.
If you select this option, you can choose what to do if there is
a conflict. You can replace the existing report output versions
in the target environment with those from the deployment archive
or keep target environment versions.
The run history of a report shows statistics about the status
and times when the report ran in your deployment. You can choose whether
to include the run history of reports.
If you select this option, you can choose what to do if there is a conflict. You can replace the existing report run histories in the target environment with those from the deployment archive or keep target environment histories.
You can choose whether to include schedules in your deployment.
If you do not deploy schedules, they are removed from the jobs and
reports in the target environment.
If you select this option, you can choose what to do if there is a conflict. You can replace the existing schedules in the target environment with those from the deployment archive or keep target environment schedules.
You can choose whether to include Cognos groups and roles in your deployment.
When you deploy the Cognos groups and roles, you must deploy them all. However, the following built-in groups are not deployed:
Anonymous
All Authenticated Users
Everyone
When you deploy groups, members of the System Administrators group are merged with the members of this group already in the target environment. This ensures that the target environment is accessible in case the deployed members are not valid. However, you may need to modify the membership list when the deployment is complete.
If you select this option, you can choose what to do if there is a conflict.You can replace groups and roles in the target environment with those from the deployment archive or to keep target environment groups and roles.
You can choose whether to include distribution lists and contacts in your deployment. If you choose to deploy distribution lists and contacts, you must deploy them all.
If you select this option, you can choose what to do if there is a conflict.You can specify whether to replace the distribution lists and contacts in the target environment with those from the deployment archive or to keep the target distribution lists and contacts.
You can choose to include data sources and their associated connections in your
deployment. If you choose to deploy data sources, you must deploy
them all.
You can deploy the data sources with or without their signons. If you do not deploy the signons, you must configure the data sources accordingly in the target environment. If you deploy the signons, you must encrypt the deployment archive.
If you select this option, you can choose what to do if there is a conflict.You can specify whether to replace the data sources in the target environment with those from the deployment archive or to keep the target environment data sources.
If you replace the target data sources, and the data source connections in the source and target environments do not match, you can lose database connections. In this case, you must manually reconnect to the data sources in the target environment after the import, using the third-party database client software.
You can choose to include access permissions in your deployment.
If you select this option, you can choose what to do if there is a conflict. You can specify whether to replace the access permissions in the target environment with those from the deployment archive or to keep the target environment access permissions.
You can specify what type of information is saved in the deployment records by setting the Recording Level for the deployment. The amount of information kept in the records has an impact on performance.
You can set the following recording levels:
Saves the deployment progress and summary information. This is the default option.
Saves only the deployment summary information. This option requires the least memory.
Saves all deployment details. This option requires the most memory.
For information about recording deployment details when an entire content store is deployed, see Deployment History.
You can change the ownership of imported entries to the user performing the import. You can select this option at the time of export or import. If you use the owners from the source, the owners are imported along with the entries. You can apply the ownership options to new entries or to new and existing entries.
