Determining Your Upgrade Requirements

Before using Siebel Anywhere to upgrade existing software or distribute new software, you must gather detailed information about the software to be distributed and about the computers that will receive it. This task is a step in "Planning and Preparing to Use Siebel Anywhere".

Specifically, you must collect the following kinds of information, each of which is described in more detail in the following topics:

• What software must be replaced or added? See "Identifying Software to Be Replaced or Added".

• Is Siebel Anywhere a suitable method for upgrading or adding this software? See "Evaluating Siebel Anywhere as an Upgrade or Delivery Method".

• Which computers need the software? See "Identifying Computers and Users to Receive Upgrades".

• Which configurations can deliver the necessary components to the designated computers? See "Identifying Configurations to Deliver Upgrade Components".

• What files must each component's upgrade kit contain? See "Identifying Files to Include in Upgrade Kits".

• Will each upgrade kit be required or optional? See "Determining Whether an Upgrade Kit Is Required or Optional".

• What version settings must each component's upgrade kit have? See "Determining Version-Setting Values".

• What specific preliminary tasks must be performed for particular upgrade kit types? See "Other Preliminary Tasks for Upgrade Kits".

• Must multiple components be delivered in a prescribed sequence? See "Determining Required Upgrade Sequences".

• How will you test each upgrade kit before distributing it to end users? See "Planning Upgrade Test Details".

Identifying Software to Be Replaced or Added

Siebel Anywhere can upgrade or distribute many kinds of software. The nature of the software to be upgraded or distributed affects many parts of the process of using Siebel Anywhere:

• Upgrades of existing software. For upgrades of existing software, you must determine the version numbers used by Siebel Anywhere for previous versions of the software being upgraded. You must also decide whether to allow any of those previous versions to remain in use, or whether to require that they be upgraded.

• Distribution of new software. For distribution of new software, you might need to create one or more custom components. Depending on who will use the software, you might also need to create new configurations.

This topic is part of "Determining Your Upgrade Requirements".

For language-dependent components, planning the upgrade also includes identifying every end-user language used in your Siebel Business Applications implementation. For example, a CFG file associated with a specific language is a language-dependent component, such as Siebel Sales CFG__ENU for U.S. English, Siebel Sales CFG__DEU for German, or Siebel Sales CFG__JPN for Japanese. Make sure to use the correct end-user language pack (or upgrade component) for each language included in your Siebel Business Applications while creating upgrade kits. For more information regarding the use of different languages, see "Example of Global Deployment with Siebel Anywhere".

The number and type of upgrade kits required for your upgrade depend on your subscribers and the components to be upgraded. For example, you might be preparing to upgrade to a new version of your custom Siebel configuration, requiring the distribution of an updated Siebel runtime repository to every Mobile Web Client user. (Siebel runtime repository changes are not distributed by an upgrade kit to Developer Web Clients. Runtime repository changes are visible to Developer Web Clients, without distribution through an upgrade kit, because these clients connect directly to the Siebel database.)

Your custom configuration might also need to apply Siebel database schema changes to your Siebel databases and to the local databases of Mobile Web Clients. Creating a Siebel Database Schema upgrade kit applies the changes from the logical schema to the physical schema. (Siebel database schema changes are not distributed by an upgrade kit to Developer Web Clients. Schema changes are visible to Developer Web Clients, without distribution through an upgrade kit, because these clients connect directly to the Siebel database.)

You must create an upgrade kit for each component to be upgraded. In the preceding example, you would need to create one upgrade kit for the Siebel runtime repository updates and a second upgrade kit for the Siebel database schema extensions. Compile a list of the upgrade kits you will need.

Evaluating Siebel Anywhere as an Upgrade or Delivery Method

Observe the following guidelines:

• Use Siebel Anywhere only with software that is related to the use of Siebel Business Applications.

• Do not use Siebel Anywhere for major upgrades, such as upgrading a Siebel database schema from Siebel CRM 8.0 to Siebel Innovation Pack 2017 (Siebel CRM version 17.0), or for installing any prior release, such as Siebel CRM 8.1.1 or version 8.2.2.

  
  

  Note: It is not necessary to install a prior release such as Siebel CRM version 8.1.1 or version 8.2.2 before you install Siebel Innovation Pack 2017.

  
  

This topic is part of "Determining Your Upgrade Requirements".

Identifying Computers and Users to Receive Upgrades

To make sure that Siebel Anywhere delivers your upgrade kit to the appropriate computers and users, you must take the following steps:

• Determine whether any Siebel Servers need the upgrade. (The steps to follow for servers, and the expected behavior, might differ from the corresponding client steps and behavior.)

• Determine which clients need the upgrade. Some possibilities include:

  • All client users need the upgrade.

  • Client users who have a particular job function need the upgrade.

  • Clients users that have particular prior versions of the software need the upgrade.

This topic is part of "Determining Your Upgrade Requirements".

Identifying Configurations to Deliver Upgrade Components

A Siebel Anywhere configuration is a definition of the setup used by a particular set of Siebel Anywhere subscribers, such as Siebel Call Center clients or Siebel Sales clients. A configuration associates a particular set of Siebel Anywhere subscribers with the specific set of upgrade components that those subscribers must have managed and maintained. Each Siebel subscriber belongs to an individual Siebel Anywhere configuration that includes a specific set of components.

This topic is part of "Determining Your Upgrade Requirements".

As part of the process of planning your upgrade, you must make sure that your Siebel Business Applications implementation contains configurations that are related to the components you want to upgrade. You must also make sure that those configurations can be used to distribute the upgrade to the appropriate subscribers, whether those subscribers represent servers or clients.

The following procedures provide instructions for listing existing configurations and for inspecting the components and users to which these configurations are related. For more information about Siebel Anywhere configurations, see "Siebel Anywhere Terminology".

Displaying Siebel Anywhere Configurations and Their Components

The following procedure describes how to display the available Siebel Anywhere configurations and their related components.

To display available Siebel Anywhere configurations and their related components 

1. Navigate to the Administration - Siebel Anywhere screen, then the Upgrade Configurations view.

2. In the Upgrade Configurations list, select a configuration that you want to inspect, and then click the Upgrade Components view tab.

   The Upgrade Components list displays the components that are currently associated with the selected configuration. Table 3-1 describes some of the fields in this list.

Table 3-1 Selected Fields in the Upgrade Components List

Field Name	Comments
Name	The name of the component. Only single-byte, alphanumeric characters, blank space, underscore, and dash are allowed. Component names cannot include special characters like periods or characters such as slash, asterisk, pipe, question mark, colon, quotes, or angle brackets.
Min Version	The minimum version required for the component on the client system. If the client uses a version of the component that is less than the minimum, then the client must upgrade or the application runs in read-only mode. Every component receives automatic version checking.
Max Version	The maximum version allowed for the component on the client system. If clients use a version of the component that is between the minimum and maximum, then they can still use the application in read and write mode without installing an upgrade kit, even if the upgrade kit is otherwise required. Clients can access Siebel Business Applications if their local version is higher than the maximum version for the component. Every component receives automatic version checking.
Min Version Distributed	The version of the component that has been distributed for this configuration. This value is set automatically when upgrade kits for this component are distributed for this configuration.
Max Version Distributed	The version of the component that has been distributed for this configuration. This value is set automatically when upgrade kits for this component are distributed for this configuration.

The following procedure provides instructions for listing the subscribers who are dynamically assigned to a selected configuration. The procedure does not list subscribers who are assigned to a particular configuration by means of a CFG file setting.

Displaying Employees Associated with a Siebel Anywhere Configuration

The following procedure describes how to display the employee users who are associated with a Siebel Anywhere configuration.

To list employees who are dynamically associated with a configuration 

1. Navigate to the Administration - Siebel Anywhere screen, then Upgrade Configurations, then the Employees view.

2. In the Upgrade Configurations list, select the configuration for which you want to view the dynamically assigned employees.

   The Employees list displays the employees who are dynamically assigned to the selected configuration. Employees who are assigned to the configuration through their CFG file values are not listed.

If you find that existing configurations do not meet your current upgrade needs, then see "Modifying and Creating Siebel Anywhere Configurations" for information about how to modify existing configurations or create new configurations.

Identifying Files to Include in Upgrade Kits

Most Siebel Anywhere upgrade kits contain software files to be distributed to subscribers. (The exceptions are upgrade kits that contain only instructions to be executed. Such instructions are generated during the upgrade kit creation process, rather than being stored in file attachments.) As part of planning an upgrade kit, identify any files the upgrade kit will include and gather those files into a single directory.

Note: It is recommended that you gather files for only one upgrade kit at a time.

This topic is part of "Determining Your Upgrade Requirements".

Table 3-2 lists some files that are typically included in various upgrade kit types. For more information about the supported component types for upgrade kits, see Table 2-4.

Table 3-2 Typical Files Included in Upgrade Kits

Upgrade Kit Type	Files
Siebel Configuration File (Siebel CFG File component type)	One CFG file for each upgrade kit, such as siebel.cfg (for Siebel Sales), uagent.cfg (for Siebel Call Center), and so on.
Siebel Database Schema (Siebel Database Extension component type)	No files
Siebel Client Executables (Siebel Executables component type)	Files for a Siebel Innovation Pack release.
Siebel Client Executables__language-code (Siebel Executables component type)	Files for a Siebel Innovation Pack release that are specifically for a given language.
Siebel Quick Fix (Siebel Quick Fix component type)	Files for a Siebel Patchset release.
Siebel Client Customer Revisions (Customer Revision component type)	Batch files, Web image files, or other files.
Siebel Client Customer Revisions__language-code (Customer Revision component type)	Message template files.
Siebel Repository Export Import (Siebel Repository ExportImport component type)	An update of the Siebel runtime repository, in the form of a data file (DAT) that will be executed in the local database on the Siebel Mobile Web Client.

Determining Whether an Upgrade Kit Is Required or Optional

You can define an upgrade kit as either required or optional, as described in the discussion of upgrade kits in "Siebel Anywhere Terminology". However, it is recommended that you initially define every upgrade kit as optional. Your test client users can test an optional upgrade kit at their convenience, while keeping read and write access to the Siebel application in the meantime.

When you are satisfied that an optional upgrade kit functions appropriately for test client users, you can modify the upgrade kit to make it required, retest it as a required upgrade kit, and then distribute it to production users as a required upgrade kit. For more information about this process, see "Converting an Optional Upgrade Kit to a Required Upgrade Kit".

This topic is part of "Determining Your Upgrade Requirements".

Determining Version-Setting Values

The exact set of information needed for defining a Siebel Anywhere upgrade kit depends on the upgrade kit's component types. However, you must supply version information for all upgrade kits.

When determining who can, or who must, upgrade a particular component, Siebel Anywhere compares version information stored in the database with the versions of components actually installed on each subscriber's computer. The information in the database comes from the information you supply when you create upgrade kits.

This topic is part of "Determining Your Upgrade Requirements".

For each upgrade kit, you must supply values or approve the default values for the following version settings:

• New Version

• Minimum Old Version

• Maximum Old Version

For a general discussion of the significance of these version numbers, see "About Siebel Anywhere Version Settings". In general, the values you supply will be related to the version numbers already in use for the component being upgraded. Therefore, gathering version information about existing components is an important part of planning an upgrade.

Caution: Make certain that Minimum Old Version, Maximum Old Version, and New Version settings are correctly set before finishing your upgrade kit, using the default numbering system, if possible. Incorrectly specifying the version information can prevent subscribers from upgrading successfully.

Gathering Information About Existing Component Versions

The following procedure provides instructions for listing the components currently available in your Siebel Business Applications implementation, along with information about currently acceptable versions of those components and how those versions are checked.

When implementing upgrades, you must preserve the version numbers for every component. This precaution is important because Siebel Anywhere assigns increasing version numbers, but components that are included in upgrades might have default version numbers set to 0 (zero). If the version number of a new component is lower than the version number of the corresponding preupgrade component, then newly upgraded users might be prompted, incorrectly, to install the old component.

Never reset any Siebel Anywhere version numbers to zero; instead, increase the version numbers of the new components to match their preupgrade counterparts. The version number of your repository is displayed as User Version when you choose Help, then About Repository, in your Siebel application.

To display version information for existing components 

• Navigate to the Administration - Siebel Anywhere screen, then the Upgrade Component List view.

  The Upgrade Component List appears.

  
  

  Caution: Do not use the Upgrade Component List to modify information about an existing component. Modifying information in the list can prevent version checking from working properly. If you must modify version information for an existing component, then use the Upgrade Kit Wizard, as described in Chapter 4, "Defining Upgrade Kits." If you want to modify other component characteristics, then create a custom component with the characteristics that you need, as described in "Setting Up Custom Siebel Anywhere Upgrade Components".

  
  

Table 3-3 describes the information available in the Upgrade Component list.

Table 3-3 Fields in the Upgrade Component List

Field Name	Comments
Component Type	The type of component for upgrade kits; for example, Siebel Repository ExportImport or Third Party Software.
Locate Information	Information used by Siebel Anywhere when locating version information for the subscriber's currently installed component. For more information about how Siebel Anywhere uses this setting, see "About Monitoring and Verifying Siebel Anywhere Version Numbers".
Locate Method	The method used by Siebel Anywhere to locate version information for the subscriber's currently installed component. For more information about how Siebel Anywhere uses this setting, see "About Monitoring and Verifying Siebel Anywhere Version Numbers".
Max Version	The latest version of the component that is available for running the application in read and write mode.
Min Version	The earliest version of the component that is acceptable for running the application in read and write mode.
Name	The name that identifies the component for Siebel Anywhere.
Version Information	Information used by Siebel Anywhere when checking the version of the subscriber's currently installed component. For more information about how Siebel Anywhere uses this setting, see "About Monitoring and Verifying Siebel Anywhere Version Numbers".
Version Method	The method used by Siebel Anywhere to check the version for the subscriber's currently installed component. For more information about how Siebel Anywhere uses this setting, see "About Monitoring and Verifying Siebel Anywhere Version Numbers".

Planning Version Settings for a New Upgrade Kit

The information you gather about current version settings lets you plan version settings for your new upgrade kit.

Note: When you run the Upgrade Kit Wizard to define your new upgrade kit, you must supply values for the New Version, Minimum Old Version, and Maximum Old Version settings.

The following tables contain guidelines for determining the version values to use in a variety of situations.

• Table 3-4 provides guidelines for choosing your New Version value.

• Table 3-5 provides guidelines for choosing your Minimum Old Version and Maximum Old Version values.

You can use these tables as worksheets by printing them out and filling in the values that you will use when you define your upgrade kit for each component.

The New Version value specifies the version number that the component being upgraded will have after the upgrade kit is used. Look in the Situation column of Table 3-4 to find a description of your situation, and read the adjacent guidelines for setting the appropriate value.

Table 3-4 New Version Planning Worksheet for Upgrade Component

Version Setting	Situation	Value Guidelines	Your Value
New Version (Identifies the version number of the component in the upgrade kit)	New component	Set New Version to 1.	1
New Version (Identifies the version number of the component in the upgrade kit)	Upgrade to existing component	Set New Version to n plus 1, where n is the Siebel Anywhere version number of the latest version of the component previously installed within your Siebel Business Applications implementation. To display previously installed versions, see "Gathering Information About Existing Component Versions".	___
New Version (Identifies the version number of the component in the upgrade kit)	Upgrade to existing component after a major Siebel upgrade	Make sure that any components provided in the major upgrade have Siebel Anywhere version numbers equal to or greater than preupgrade components. You might need to stamp new numbers on the components to achieve this. For more information, see "Testing the Consistency of Upgrade Kit Components". When component version numbering is continuous for the upgrade, use the instructions for upgrading to an existing component, in the previous row of this table.	___
New Version (Identifies the version number of the component in the upgrade kit)	Replacing a defective upgrade kit that has been distributed and deactivated	Set New Version to the same value you assigned to the defective upgrade kit.	___

The Minimum Old Version and Maximum Old Version values specify the range of component versions that subscribers must have to download and install the upgrade kit. Look in the Situation column of Table 3-5 to find a description of your situation, and read the adjacent guidelines for setting the appropriate values.

Table 3-5 Minimum and Maximum Old Version Planning Worksheet for Upgrade Component

Version Setting	Situation	Value Guidelines	Your Value
Minimum Old Version (Determines who can use the upgrade kit)	No component versions are prerequisites for subscribers using upgrade kit or all needed prerequisites are included in this upgrade kit.	Leave blank.	NULL
Minimum Old Version (Determines who can use the upgrade kit)	Subscribers are upgrading a history-independent component, such as executable, or Siebel database schema.	This setting is automatically set to NULL. It cannot be changed.	NULL
Minimum Old Version (Determines who can use the upgrade kit)	Subscribers are upgrading a CFG file.	It is recommended that you leave this setting blank.	___
Minimum Old Version (Determines who can use the upgrade kit)	Subscribers are upgrading a customer revision component.	It is recommended that you accept the default value for this setting and the setting for Maximum Old Version, to make sure that your users download and install every upgrade kit of this type, without skipping any of them.	___
Minimum Old Version (Determines who can use the upgrade kit)	Subscribers are required to have a prior version of the component.	Set to the earliest component version that can download and install the new upgrade kit.	___
Minimum Old Version (Determines who can use the upgrade kit)	You are replacing a defective upgrade kit that has been distributed and deactivated.	Set Minimum Old Version to the same value as you used in the defective upgrade kit.	___
Maximum Old Version (Determines who can use the upgrade kit)	No component versions are prerequisites for subscribers using upgrade kit or all needed prerequisites are included in this upgrade kit.	Leave blank.	NULL
Maximum Old Version (Determines who can use the upgrade kit)	Subscribers are upgrading a history-independent component, such as executable, or Siebel database schema.	This setting is automatically set to NULL. It cannot be changed.	NULL
Maximum Old Version (Determines who can use the upgrade kit)	Subscribers are upgrading a CFG file.	It is recommended that you leave this setting blank.	___
Maximum Old Version (Determines who can use the upgrade kit)	Subscribers are upgrading a customer revision component.	It is recommended that you accept the default value for this setting and the setting for Minimum Old Version, to make sure that your users download and install every upgrade kit of this type, without skipping any of them.	___
Maximum Old Version (Determines who can use the upgrade kit)	Subscribers are required to have a prior version of component.	Set to the latest component version that can download and install the new upgrade kit. This value is always less than the value of New Version.	___
Maximum Old Version (Determines who can use the upgrade kit)	You are replacing a defective upgrade kit that has been distributed and deactivated.	Set Maximum Old Version to the same value as you used in the defective upgrade kit.	___

Other Preliminary Tasks for Upgrade Kits

This topic describes additional preliminary tasks to perform for upgrade kits, based on their specific component types.

This topic is part of "Determining Your Upgrade Requirements".

Preliminary Tasks for Siebel Database Schema Upgrade Kits

Perform the following tasks before creating a Siebel Database Schema upgrade kit:

• Make sure that the changes to your Siebel database schema can be distributed by this type of upgrade kit.

• Make sure that the ODBC data source correctly points to the server database that has the modified database definition.

• Use SQL queries on your server database to obtain values for the following parameters, as they apply to your database platform:

  • 16K Table Space

  • 32K Table Space

  • Table Group File

• If you are operating in an IBM DB2 environment, then drop all customized views and triggers before you run the Upgrade Kit Wizard to define a Siebel Database Schema upgrade kit. Otherwise, the attempt to create the upgrade kit will fail.

For more information about the overall process of deploying a Siebel Database Schema upgrade kit, see "Process of Updating the Siebel Database Schema".

Preliminary Tasks for Siebel Repository Export Import Upgrade Kits

Perform the following tasks before creating a Siebel Repository Export Import upgrade kit:

• Using the Siebel Migration application, complete a full runtime repository migration operation.

• Set up the Siebel Mobile Web Client.

• Create a new workspace, make the repository changes, and deliver the updates.

• Using the Siebel Migration application, complete an incremental runtime repository migration operation.

• Make sure that the repository changes are available in the runtime environment to which clients are pointing.

• Make sure that the ODBC data source correctly points to the server database that has the modified database definition.

• If you are running the dataexp.exe directly in the developer environment instead of using the Siebel Migration application, then make sure the workspace is in a check-pointed state.

For more information about planning for a database migration using Siebel Application Interface, preparing data for a migration using Siebel Application Interface, and migrating database data from a source environment to a target environment using Siebel Application Interface, see Siebel Database Upgrade Guide.

Preliminary Tasks for Third Party Software Upgrade Kits

Perform the following tasks before creating a Third Party Software upgrade kit:

• Locate or prepare the executable file or script that will be executed on the subscriber's computer when the upgrade kit is installed. Make a note of any input parameters required by the executable file or script for the third-party software.

• Place the executable file in a network location that is accessible to the Siebel Server where the Upgrade Kit Builder is enabled.

• Make a note of the UNC path to the network location where you placed the executable file.

• Determine the location where the third-party software will be installed on the subscriber's computer.

Preliminary Tasks for Siebel Client Customer Revisions Upgrade Kits

Perform the following tasks before creating a Siebel Client Customer Revisions upgrade kit:

• Locate or prepare the executable file or script that will be executed on the subscriber's computer when the upgrade kit is installed. Make a note of any input parameters required by the executable file or script.

• Locate any other files to be included in the upgrade kit, and make a note of the locations where they will be installed on the subscriber's computer.

Determining Required Upgrade Sequences

Sometimes you might need to use more than one upgrade kit to complete an upgrade.

This topic is part of "Determining Your Upgrade Requirements".

For example, you might want to deliver a Siebel Innovation Pack release, using a Siebel Client Executables upgrade kit, and then deliver an updated configuration file, using another upgrade kit (such as Siebel Sales CFG__ENU) that is dependent on the prior installation of the Siebel Client Executables upgrade kit.

In cases involving multiple upgrade kits, the upgrade kits might need to be installed in a specific sequence. It is possible to automate this process by making one upgrade kit dependent on the prior installation of another upgrade kit. You can specify this dependency before activating the second upgrade kit in the sequence. For more information about how to do this, see "Controlling the Order of Upgrade Kit Installation".

Note: If you plan to specify a required upgrade sequence, then do not use the Upgrade Kit Wizard to activate the upgrade kits involved.

Planning Upgrade Test Details

It is important to plan your upgrade kit testing ahead of time, to make sure that you create any needed infrastructure elements and choose appropriate settings when you create the upgrade kit.

This topic is part of "Determining Your Upgrade Requirements".

The following general recommendations are useful for most test plans:

• Create all upgrade kits as optional upgrade kits. This facilitates testing by letting users request an upgrade at their convenience. (A required upgrade kit might or might not prompt users to upgrade when they start the application, depending on the version requirements and the test client version.) After you have verified that an optional upgrade kit installs correctly, you can change it to be required, if you want, and retest its installation using another test client.

• Distribute a new upgrade kit to a test configuration (such as the Siebel Test Client configuration) before distributing it to production configurations. If necessary, create such a test configuration ahead of time. Make sure that it has the appropriate test employee logins assigned to it, either by means of configuration files or dynamic assignments.

• Test each upgrade kit with both Mobile Web Clients and Developer Web Clients, as applicable.