Overview of the Domain Upgrade Process

BEA provides a tool called Domain Upgrade Wizard to help you upgrade WebLogic domains.

You can use the Domain Upgrade Wizard to upgrade domains that are created in the following product releases:

Product	Upgrade from Release/s	Upgrade to Release/s
WebLogic Server	6.1, 7.0, 8.1, or 9.x	10.0
WebLogic Workshop	8.1 SP4 or higher, or 9.x	10.2
WebLogic Integration	8.1 SP4 or higher, or 9.x	10.2
WebLogic Portal	8.1 SP4 or higher, or 9.x	10.2
WebLogic Platform	8.1 or 9.x	10.2

This section provides an overview of the tasks that the Domain Upgrade Wizard performs when you use it to upgrade a WebLogic Platform domain.

The original domain directory is backed up (if you opt for it).

The wizard backs up the domain directory only; it does not preserve file permissions. BEA recommends that you back up the domain, any external applications, and application database resources. For more information, see Step 3: Back Up the Application Environment in Roadmap for Upgrading Your Application Environment.

Note:

The backup files created by the wizard might contain confidential information. So ensure that they are protected.

Scripts, such as the startup and shutdown scripts, are re-created. Any original scripts are renamed as orig-scriptname.bak, where orig-scriptname represents the name and extension of the original script.

Note: The wizard does not copy any customizations in the original startup scripts to the new scripts. For example, if you specified a nondefault value for the JAVA_OPTIONS environment variable in the original script, the specified value is not preserved in the new script.

The original domain is restructured: a new directory structure is created and the domain components are moved to new locations.

Note:

This step is performed only when upgrading from a pre-9.x domain.

During the restructuring, if a required directory already exists, that directory, and the files and subdirectories in it are retained.

Existing server log files are copied to the servers/server_name/logs/pre-10.0-logs directory in the domain, where server_name specifies the name of the server.

For information about the domain directory structure, see WebLogic Domain Directory Structure Enhancements.

The persisted configuration information stored in the configuration file (config.xml) is upgraded to the config directory.

Note:

This step is performed only when upgrading from a pre-9.x domain.

If the wizard encounters duplicate resources while upgrading the configuration file (config.xml), a message is logged in the progress window. In this case, the last resource definition encountered is used during the conversion.

Persisted data – such as JMS file stores, JMS JDBC stores, and transaction stores – is upgraded.

Note:

If JMS JDBC stores are used in the domain, you must first configure the environment, as described in Step 6: Set Up the Environment in Roadmap for Upgrading Your Application Environment.

After the JMS JDBC stores are upgraded, the original JMS JDBC stores are not deleted. You must consider this while planning for capacity. You can delete the original JMS JDBC store tables after the upgrade process. The original JMS JDBC store tables are named PrefixNameJMSSTORE and PrefixNameJMSSTATE, where PrefixName is the value of the Prefix Name attribute for the JMS JDBC store.

If you do not want to upgrade persisted JMS messages, you can delete the JMS file store or JMS JDBC store tables before running the upgrade. When you do so, only JMS messages are lost; the configuration is not changed. For information about managing JDBC store tables, see Managing JDBC Store Tables.

The wizard does not upgrade a JMS JDBC or file store if it detects that an upgrade has already been performed. To perform multiple upgrades of a domain in which the same persistent stores are used (for example, in a test scenario), you must revert the data in the JMS store each time you repeat the upgrade process, as follows:

For a JMS JDBC store, the upgrade process creates a new table named PrefixNameWLSTORE, where PrefixName is the value of the Prefix Name attribute for the JMS JDBC store. Before repeating the upgrade process on a domain that uses the JMS JDBC store, remember to drop this table.
To repeat the upgrade process, ensure that you first restore the backed up version of the JMS file store.

Resources are added to support advanced web services, including the WseeFileStore file store, the WseeJmsServer JMS server, and its associated JMS module.

Note:

This step is performed only when upgrading from a pre-9.x domain.

Beehive shared library modules are added to support Workshop applications.

Note:

This step is performed only when upgrading from a pre-9.x domain.

The JWSQueueTransport EJB, if it is present in the domain, is removed.
The following tasks are performed if any data source is configured to use PointBase (v5 or lower):

The database is automatically loaded in embedded mode and upgraded to PointBase v5.1.
The pointbase.ini file is updated to set database.home, documentation.home and pbembedded.lic for PointBase v5.1.
The database files are renamed from workshop to weblogic_eval and the associated data source JDBC driver URLs accordingly fixed.
The PointBase-related environment settings are carried over to the upgraded domain scripts, setDomainEnv.cmd and setDomainEnv.sh.

If the domain contains WLI resources, see the Upgrading Your WebLogic Integration Domain section in the WLI Upgrade Guide.
If the domain contains WLP resources, the wizard performs the following additional tasks:

Adds shared library modules to support personalization (P13n) applications.
Adds shared library modules to support WebLogic Platform applications.
Updates and adds JMS and JDBC resources to support WebLogic Platform applications.
Removes user-defined applications that have been deployed to the domain.

Note:

This step is performed only when upgrading from a 8.1x domain. For 9.2 and 10.0 domains, application deployments are retained.

Updates WebLogic personalization (P13n) JDBC data sources and connection pools.
Configures SSPI providers required by WebLogic Portal; also adds WebLogic SAML providers, Identity Asserter, and Credential Mapper to the security realm to enable the WSRP 9.x features.
Adds the SQLAuthenticator security provider to the domain.

Note: The portaladmin and weblogic users are added to the SQLAuthenticator security provider. You can remove these users from the DefaultAuthenticator security provider after the domain is upgraded.

If the RDBMSAuthenticator security provider is used, users and groups are copied from the RDBMSAuthenticator provider to the SQLAuthenticator provider.

Note:

You can remove the RDBMSAuthenticator, including its data and tables, after the domain is upgraded.

The domain database schema objects are optionally upgraded.
The configuration is saved.

Note:

When upgrading remote managed servers, the wizard does not persist the configuration information.

Issues that require further consideration are reported.

Important Notes About the Domain Upgrade Process

You must upgrade the domains on every machine in the application environment. For information about preparing domain directories on remote managed servers, see Step 5: Prepare the Remote Managed Server Domain Directories in Roadmap for Upgrading Your Application Environment.
As of WebLogic Server 9.0, the .wlnotdelete directory is no longer used in the WebLogic Server environment.
During the upgrade process, file permissions are not preserved. You must verify and reset all nondefault file permissions.
On a UNIX system, ownership and permissions for any new files created during the upgrade process are assigned to the user performing the upgrade. For example, if the upgrade is performed by root, then root is assigned ownership of any new files. As a result, any user who subsequently wants to update these files in the domain must have root privileges. So, if required, modify the permissions on files created during the upgrade process.
After upgrading, the server might prompt you for the user name and password while booting. This is because the weblogic.management.username and weblogic.management.password arguments, which were used in earlier scripts have been dropped.
When you upgrade a domain on a remote managed server, a message similar to the following might be displayed to indicate that the referenced application path does not reside in the system:

<Aug 1, 2005 6:42:06 PM EDT> <INFO> <Upgrade> <BEA-800000> <An invalid path, 'C:\bea\wlserver_10.0\user_projects\mydomain\medrecEar.ear', was specified for application, 'medrecEar'.>

Ignore this message.

The Domain Upgrade Wizard does not upgrade applications. For information about upgrading WLI, WLP, and Workshop applications, see the WLI Upgrade Guide, the WLP Upgrade Guide, and the Workshop Upgrade Guide, respectively.

It is not necessary to upgrade WLS applications. In most cases, they will continue to run in the upgraded WLS 10.0 application environment. For information about changes that affect WLS applications in your environment, see WebLogic Server 10.0 Compatibility with Previous Releases.

Domain Upgrade Guide

Overview of the Domain Upgrade Process

Important Notes About the Domain Upgrade Process