Response Configuration Parameters and Options

In this section you can upgrade Intelligence Server components and the projects for an Intelligence Server.

Defines whether to upgrade Intelligence Server components and projects, as determined by the following values:

1: Upgrade Intelligence Server components and projects.

0: Does not upgrade Intelligence Server components and projects.

Defines whether to upgrade the metadata, as determined by the following values:

1: Upgrades the metadata repository, which contains the definitions of your MicroStrategy applications and supporting objects. An upgrade of your metadata is required to provide support for all new and updated features in the most recent version of MicroStrategy.

0: Does not upgrade the metadata.

Defines whether to upgrade administrative privileges, as determined by the following values:

1: Upgrades the privileges used to define the features and capabilities available for each MicroStrategy user. This upgrade is required to reflect any changes in privileges for the most recent version of MicroStrategy. After the upgrade is finished, you can manually modify the privileges for your users and user groups to ensure that all users have access to the required MicroStrategy features. To ensure that the updated user privileges are in compliance with your license agreement, you can use License Manager to audit and view user product privileges.

0: Does not upgrade administrative privileges.

Defines whether to migrate History List from a flat file to a database, as determined by the following values:

1: Migrates your previous file-based History List repository to a database-based History List repository. In pre-9.0 versions of MicroStrategy, all History List files were stored using a file-based method. In addition to the file-based method, it is also possible to store the History List repository in the database. This allows administrators to centrally monitor all History List messages across the system.

0: Does not migrate History Lists to a database. Use this option if you did not previously use History List messages or you plan to continue to use a flat file to support and store History Lists.

Defines whether to upgrade projects, as determined by the following values:

1: Upgrades the projects defined in ProjectLogicalUpgrade.

0: Does not upgrade projects.

Provide the user name for the MicroStrategy user to connect to the Intelligence Server to upgrade.

Provide the password for the MicroStrategy user to connect to the Intelligence Server to upgrade.

Provide the password for the metadata to upgrade.

If you have previously upgraded the metadata but not upgraded the privileges, provide the version of the metadata that you most recently upgraded your privileges to, from the following list of options:

9.4

9.5

9.5.1

10

10.1

10.2

10.3

10.4

10.5

10.6

10.7

10.8

10.9

10.10

10.11

If performing a History List migration, the type of History List to migrate to:

File

Database

Hybrid

If performing a History List migration, defines the directory location of the History List flat file to migrate to a database.

If performing a History List migration to a hybrid History List, defines the directory location where the hybrid History List files are to be stored.

If performing a History List migration, defines the DSN of the database to migrate the History List tables to.

If performing a History List migration, defines the user name to connect to the database for the History List migration.

If performing a History List migration, defines the password to connect to the database for the History List migration.

If performing a History List migration, defines the table prefix for History List tables.

Defines whether to drop existing tables in the database used for the History List migration, as determined by the following values:

1: Deletes existing tables in the database before migrating the History List tables.

0: Appends the migrated History List tables to the database without deleting existing tables.

Defines whether to delete the file based History List after the migration is complete, as determined by the following values:

1: Deletes the file-based History List repository once the migration to a database-based History List repository is complete. This option should only be used if the file-based History List repository is no longer needed, and you can ensure the migration process can be completed successfully.

0: Does not delete the file-based History List repository once the migration to a database-based History List repository is complete.

Defines whether UTF-8 encoding should be used for the History List migration on Windows, as determined by the following values:

1: Uses UTF-8 encoding for Windows drivers. This option should be used if your database and History List messages use UTF-8 encoding, and the Intelligence Server is installed on Windows.

0: Does not use UTF-8 encoding.

Defines whether UTF-8 encoding should be used for the History List migration on UNIX/Linux, as determined by the following values:

1: Uses UTF-8 encoding for UNIX/Linux drivers. This option should be used if your database and History List messages use UTF-8 encoding, and the Intelligence Server is installed on UNIX or Linux.

0: Does not use UTF-8 encoding.

Defines the database name to create or migrate History Lists stored in DB2 z/OS. This option should be used if connecting to a DB2 z/OS database.

Defines the table name to be used in the database when creating or migrating the History List. This option should be used if connecting to a DB2 z/OS database.

If performing a History List repository upgrade to a hybrid History List, defines the number of database threads to use for the upgrade.

Defines the projects to update their schedules that send reports and documents to caches, History Lists, and MicroStrategy Mobile as subscriptions. These subscriptions are part of the integrated subscription and delivery features in Intelligence Server 9.0 and later versions. They provide the same ability to send reports and documents to caches, History Lists, and MicroStrategy Mobile as the schedules in MicroStrategy pre-9.0.

This option also upgrades the reports and Report Services documents in the projects, which improves performance, reduces storage space requirements, and ensures that graphs display correctly in MicroStrategy Web 10 and Developer 10.

To upgrade multiple projects, you must enclose the name of each project in curly braces {} and separate the names with a backslash \ . For example:

{Project1}\{Project2}\...\{ProjectN}

Defines the projects to upgrade their schedules to the most recent version of MicroStrategy.

To upgrade multiple projects' schedules, you must enclose the name of each project in curly braces { } and separate the names with a backslash \ . For example:

{Project1}\{Project2}\...\{ProjectN}

Defines the projects to update their MDX source objects (MDX cubes) that were created in earlier versions of MicroStrategy to take advantage of increased performance and other updates.

You can integrate MDX sources such as SAP BW, Microsoft Analysis Services, and Hyperion Essbase into your MicroStrategy environment. For information on integrating MDX sources into MicroStrategy, see the MDX Cube Reporting Guide.

To upgrade multiple projects' MDX source objects, you must enclose the name of each project in curly braces { } and separate the names with a backslash \ . For example:

{Project1}\{Project2}\...\{ProjectN}

Defines the projects for which to update system objects so that objects can be moved between unrelated projects using MicroStrategy Object Manager. This is required for projects from pre-9.0.1 versions of MicroStrategy.

To upgrade multiple projects' system objects, you must enclose the name of each project in curly braces { } and separate the names with a backslash \ . For example:

{Project1}\{Project2}\...\{ProjectN}

Defines whether to update the rest of the specified projects if one project update generates an error:

1: Continues the update process even if an error is found in one project.

0: Halts the update process for all projects if an error is found in one project.

Defines whether the password is encrypted in the response file, as determined by the following values:

1: Encrypts the password in the response file, which ensures that your password is secure. This is the default behavior.

0: The password is not encrypted in the response file, which enables you to modify the password in the response file later using a text editor. You can then distribute the response file to multiple users with various login and password credentials. However, be aware that this can compromise your database security if you do not remove the password from the response file before distributing it.

Defines the database name to update metadatas stored in DB2 z/OS. This option should be used if connecting to a DB2 z/OS database.

Defines the table name to be used in the database when upgrading the metadata. This option should be used if connecting to a DB2 z/OS database.

Defines whether to perform Lean Objects migration at the server level:

1: Perform Lean Objects migration.

0: Do not perform Lean Objects migration.

In this section you can upgrade statistics repositories to the most recent version of MicroStrategy. You can have more than one [UpgradeStats] section. Additional statistics upgrade sections can be included as [UpgradeStats1], [UpgradeStats2], and so on.

Defines whether to upgrade the statistics and Enterprise Manager repositories, as determined by the following values:

1: Upgrades the statistics repository

0: Does not upgrade the statistics repository

Defines whether the password is encrypted in the response file, as determined by the following values:

1: Encrypts the password in the response file, which ensures that your password is secure. This is the default behavior.

0: The password is not encrypted in the response file, which enables you to modify the password in the response file later using a text editor. You can then distribute the response file to multiple users with various login and password credentials. However, be aware that this can compromise your database security if you do not remove the password from the response file before distributing it.

If performing a statistics repository upgrade, defines the DSN of the database that stores the statistics repository.

If performing a statistics repository upgrade, defines the user name to connect to the database for the statistics repository.

If performing a statistics repository upgrade, defines the password to connect to the database for the statistics repository.

In this section you can upgrade an Enterprise Manager project to the most recent version of MicroStrategy. You can have more than one [EMProjectHeader] section. Additional Enterprise Manager project upgrade sections can be included as [EMProjectHeader1], [EMProjectHeader2], and so on.

Defines whether to upgrade the Enterprise Manager project, as determined by the following values:

1: Upgrades the Enterprise Manager project.

0: Does not upgrade the Enterprise Manager project.

Defines whether the password is encrypted in the response file, as determined by the following values:

1: Encrypts the password in the response file, which ensures that your password is secure. This is the default behavior.

0: The password is not encrypted in the response file, which enables you to modify the password in the response file later using a text editor. You can then distribute the response file to multiple users with various login and password credentials. However, be aware that this can compromise your database security if you do not remove the password from the response file before distributing it.

If performing an Enterprise Manager project upgrade, provides the MicroStrategy user name that can access and administer the Enterprise Manager project.

If performing an Enterprise Manager project upgrade, provides the password for the MicroStrategy user that can access and administer the Enterprise Manager

project.

If performing an Enterprise Manager project upgrade, defines the DSN of the database that stores the statistics tables and Enterprise Manager repository.

If performing an Enterprise Manager project upgrade, defines the user name to connect to the database for the statistics tables and Enterprise Manager repository.

If performing an Enterprise Manager project upgrade, defines the password to connect to the database for the statistics tables and Enterprise Manager repository.

In this section you can upgrade History List repositories to the most recent version of MicroStrategy. You can have more than one [UpgradeHistoryList] section. Additional History List upgrade sections can be included as [UpgradeHistoryList1], [UpgradeHistoryList2], and so on.

Defines whether to upgrade a History List repository, as determined by the following values:

1: Upgrades the History List repository.

0: Does not upgrade the History List repository.

Defines whether the password is encrypted in the response file, as determined by the following values:

1: Encrypts the password in the response file, which ensures that your password is secure. This is the default behavior.

0: The password is not encrypted in the response file, which enables you to modify the password in the response file later using a text editor. You can then distribute the response file to multiple users with various login and password credentials. However, be aware that this can compromise your database security if you do not remove the password from the response file before distributing it.

If performing a History List repository upgrade, defines the DSN of the database that stores the History List repository.

If performing a History List repository upgrade, defines the user name to connect to the database for the History List repository.

If performing a History List repository upgrade, defines the password to connect to the database for the History List repository.

If performing a History List repository upgrade, defines the database prefix for the History List repository.

If performing a History List repository upgrade, upgrades existing History List messages to the specified format, as determined by the following values:

1: Upgrades existing History List messages.

0: Does not upgrade existing History List messages.

Regardless of this setting, the new database tables required for the new History List format are created, and any new History List messages are created in the new format.

In this section you can migrate MicroStrategy Web delivery subscriptions from a Narrowcast Server environment to Distribution Services. You can have more than one [MigrateNCS] section. Additional MicroStrategy Web delivery subscription migration sections can be included as [MigrateNCS1], [MigrateNCS2], and so on.

Defines whether to migrate MicroStrategy Web delivery subscriptions from a Narrowcast Server environment to Distribution Services, as determined by the following values:

1: Migrates MicroStrategy Web delivery subscriptions from a Narrowcast Server environment to Distribution Services.

0: Does not migrate MicroStrategy Web delivery subscriptions from a Narrowcast Server environment to Distribution Services.

Defines the DSN of the database that stores the Narrowcast Subscription Book Repository.

Defines the user name to connect to the database for the Narrowcast Subscription Book Repository.

Defines the password to connect to the database for the Narrowcast Subscription Book Repository.

Defines the prefix used for the tables of the Narrowcast Subscription Book Repository.

Defines the DSN of the database that stores the Narrowcast Object Repository.

Defines the user name to connect to the database for the Narrowcast Object Repository.

Defines the password to connect to the database for the Narrowcast Object Repository.

Defines the prefix used for the tables of the Narrowcast Object Repository.

Defines the project source that the Web delivery subscriptions are migrated to.

Defines the user name to connect to the project source.

Defines the user password to connect to the project source.

Defines the projects, for a project source, to migrate Web subscriptions from Narrowcast Server to Distribution Services. You can select multiple projects, separating projects by the \ character. For example, TargetProjects=Project1\Project2.

Defines whether to migrate all users of Web deliveries to Distribution Services, as determined by the following values:

1: Migrates all users of Web deliveries to Distribution Services. Addresses of the MicroStrategy users who subscribed to Web deliveries are assigned to the corresponding MicroStrategy users. No new MicroStrategy users are created.

0: Does not migrate all users of Web deliveries to Distribution Services.

If you choose to migrate all users of Web deliveries to Distribution Services, this option defines whether to grant the Use Distribution Services privilege for all Web delivery users that are migrated to Distribution Services, as determined by the following values:

1: Grants the Use Distribution Services privilege for all Web delivery users that are migrated to Distribution Services. Ensure that granting these privileges is in compliance with your product license for Distribution Services.

0: Does not grant the Use Distribution Services privilege for all Web delivery users that are migrated to Distribution Services.

Defines whether to migrate Narrowcast Server users and their addresses as contacts in Distribution Services, as determined by the following values:

1: Migrates Narrowcast Server users and their addresses as contacts in Distribution Services. A contact is created for each Narrowcast Server user. The Narrowcast Server user's addresses are copied as addresses of the contact. A contact is a list of subscription recipient addresses. These recipients do not have the permissions to log in to MicroStrategy Web or Developer. Contacts enable these recipients to receive subscriptions.

0: Does not migrate Narrowcast Server users and their addresses as contacts in Distribution Services

These parameters specify the conflict resolution rules when migrating Narrowcast objects to Distribution Services. Conflicts occur when identical objects are present in both the Narrowcast Server system you are migrating from and the Intelligence Server metadata you are migrating to. Defining conflict resolution rules determines how these conflicts are resolved during the migration.

You can use the following parameters to define how to resolve any conflicts during the migration:

MigrateTransmittersAction for Transmitters

MigrateDevicesAction for Devices

MigrateSchedulesAction for Schedules

MigrateSubscriptionsAction for Subscriptions

MigrateUsersAction for Users

For each object type listed above, you can define conflict resolution rules based on matching IDs. For transmitters, devices, and schedules you can also define conflict resolution rules based on matching definitions. These options are described in the table below.

In the table below, "source" refers to your Narrowcast Server and "destination" refers to the new metadata tables.

Option Value

1

2

3

4