|
| |
| Sun Java Communications Suite 5 Upgrade Guide | |
Chapter 1
Planning for UpgradesThis chapter provides information used for planning the upgrade from previous versions of Sun Java™ Communications Suite product components to Communications Suite 5 in the following sections:
Communications Suite 5 ComponentsAs an introduction to planning the upgrade of Communications Suite software, this section reviews the components included in this release of Communications Suite. Depending on your upgrade scenario, you might need to upgrade one or more of these components.
Communications Suite components interoperate with Java Enterprise System components. These component sets are grouped into different types. Accordingly, service components provide the main infrastructure services, while service quality components enhance those system services. These two types of components are together referred to here as product components. Each product component depends on one or more locally shared libraries known as shared components.
For instructions on upgrading Java Enterprise System components see the Java Enterprise System Upgrade Guide (http://docs.sun.com/doc/819-6553).
Product Components
Communications Suite product components are shown in the following table, listed alphabetically. For the service quality components among them, the table includes the type of service enhancement they provide.
Instructions for upgrading Connector for Microsoft Outlook are available in the Sun Java System Connector for Microsoft Outlook Installation Guide.
Communications Suite Shared Components
The Communications Suite shared components are listed in the following table.
About Communications Suite UpgradesThere is no single system utility that upgrades all Communications Suite components. Instead, the upgrade of Communications Suite product components is performed component-by-component, computer-by-computer, using component-specific upgrade procedures documented in this Upgrade Guide.
The upgrade of a component can range from a major upgrade, which might not be compatible with the previous version of the component, to a fully-compatible upgrade that simply provides bug fixes. Because of dependencies between Communications Suite components and between Communications Suite and Java Enterprise System components, the nature of the upgrade can impact whether you need to upgrade other components as well.
Product Component Upgrades
Communications Suite product component upgrades involve two basic operations that mirror the initial installation and configuration of Communications Suite product components:
- Installing upgraded software. The new software can enhance or fix existing software, or replace existing software. In general, the new software is achieved through the application of patches to existing software packages, the selective replacement of existing packages or the installation of new packages.
- Re-configuration. Re-configuration encompasses any change in configuration data, user data, or dynamic application data needed to support the upgraded software. A change in data can mean additional data, a change in data format (whether in property files or database schema), or a change in data location. Sometimes re-configuration requires that you perform an explicit procedure and sometimes it takes place automatically without your involvement. In some cases, re-configuration also requires re-deployment of component software to a web container.
Both of these aspects of component upgrade are described in this Upgrade Guide for each of the Communications Suite product components.
This book also covers other important aspects of product component upgrade, including:
Product Component Upgrade Approaches
The upgrade of each product component, as documented in this Upgrade Guide, involves one of the following upgrade approaches:
Each of these approaches is discussed briefly in the sections that follow.
Running a Component-specific Upgrade Script
A number of product components provide an upgrade script for automating the upgrade of the component to Communications Suite 5. The script generally performs both the upgrade of software packages and any re-configuration required as part of the upgrade. For those components deployed to a web container, the script generally re-deploys the upgraded component software to the web container.
Patching Existing Component Packages
For a number of product components, upgrade is performed by manually patching existing software packages. Solaris and Linux platforms employ similar technologies for managing installed software packages and tracking changes to those packages through a package registry.
- Solaris platform. Packages can be installed and removed through the Solaris pkgadd and pkgrm commands. Package contents, once installed, can be modified using patches that are applied or removed through the patchadd and patchrm commands. Patches to Solaris packages are distributed through the SunSolve website at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Solaris patches can patch one or more packages. The patchadd command saves a backup of the package being patched to facilitate the removal of the patch using the patchrm command. Patches are identified by a patch ID, which consists of a patch number followed by a revision number that is incremented as the patch is modified over time.
- Linux platform. RPM (Red Hat Package Manager) packages can be installed or updated through the rpm command. Package contents, once installed, however, cannot be modified using patches. Rather, RPM packages are updated using the rpm -U command option, which replaces the current package with a newer package.
As a convenience, many RPM package upgrades are distributed not only on the Communications Suite 5 distribution, but also through the SunSolve website at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
For distribution through SunSolve, RPM packages can be wrappered as patches and assigned a patch ID and revision number similar to Solaris patches. These Linux patches can include one or more RPM packages, each identified by a unique RPM name, RPM number, and a revision number that is incremented as the RPM package is modified over time.
Shared Component Upgrades
Communications Suite shared component upgrades are often a necessary part of upgrading the product components that depend on them.
The upgrading of shared components is typically more straightforward than the upgrading of product components: there is normally no reconfiguration required, no pre or post upgrade procedures to be performed, and no rollback supported.
Operating System Issues
A number of operating system issues impact the upgrading of Communications Suite software, as described below.
Required Operating System Updates
In some situations, successful upgrade of a Communications Suite product component can require you to first patch the operating system or apply specific fixes. Rather than applying the specific operating system patch required in each case, it is generally preferable to simply bring the operating system up to date before performing Communications Suite upgrades.
- Solaris platform patches are available through the SunSolve website as a patch cluster, a collection of operating system patches that can be collectively applied. The operating system patch clusters for Solaris 9 and 10 are available at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Linux platform update releases are available at: https://www.redhat.com/apps/download/
Operating System Upgrades
Upgrading an operating system can have an impact on installed Communications Suite components, both product components and shared components, often requiring that at least some components be restored or upgraded. Upgrading the operating system can affect Communications Suite components in the following two ways:
- Release-specific packages. A significant number of Communications Suite shared components have Solaris release-specific packages that do not function correctly on other Solaris platform releases. For example, packages that are released for the Solaris 9 operating system cannot always be expected to work on Solaris 10 operating system.
- Operating system-bundled shared components. In some cases the updated version of operating system includes versions of Communications Suite shared components earlier than those required by the installed Communications Suite software. In other words, upgrading the operating system overwrites the existing Communications Suite shared components with earlier versions. In that case the correct Communications Suite versions need to be restored.
Upgrading Non-Supported Systems
There are two situations by which an operating system and Communications Suite software could become misaligned:
For example, Java Enterprise System 2004Q2 is supported on Solaris 8 and 9 operating systems and on Red Hat Enterprise Linux (RHEL) 2.1. If you wish to upgrade your operating system platform to Solaris 10 or RHEL 3.0, which are not supported by Java Enterprise System 2004Q2, you will also need to upgrade your Java Enterprise System 2004Q2 to a Communications Suite release version that supports the upgraded platform, preferably to Communications Suite 5.
Because upgrade of some components requires that other Communications Suite components be running, you cannot, as a general rule, simply upgrade your operating system platform to Solaris 10 or RHEL 3.0 (which are not supported by Communiations Services 2004Q2) and then upgrade product components from 2004Q2.
For example, Java Enterprise System 2005Q1 and Java Enterprise System 2005Q4 are supported on Solaris 8 and RHEL 2.1. If you want to upgrade to Communications Suite 5, however, which is not supported on Solaris 8 or RHEL 2.1, you will also need to upgrade your operating system to versions supported by Communications Suite 5, preferably to Solaris 10 or RHEL 4.0.
In both these situations, you have to upgrade both Communications Suite software and operating system software.
In general, such dual upgrades require the following upgrade sequence:
- Back up all Communications Suite configuration files and customizations.
- Uninstall the currently-installed Communications Suite release version.
- Upgrade your operating system software.
- Perform a fresh install of Communications Suite 5. See the Communications Suite Installation Guide.
- Configure Communications Suite 5 using saved configuration data.
Upgrade PlanningThe approach you take to upgrading to Communications Suite 5 can depend on your upgrade objectives and priorities, as well as the scope and complexity of your deployment architecture.
For example, your Communications Suite deployment architecture might consist of a single Communications Suite component running on a single computer, and your upgrade objective is to fix some bug in the previous software release. On the other hand, your deployment architecture might consist of a number of interdependent Communications Suite components deployed across a number of different computers, and your upgrade objective is to achieve some new functionality by upgrading the minimum number of components required to achieve that end with minimal downtime.
These two examples represent upgrade scenarios of very different complexity, requiring substantially different upgrade plans. No one plan works for all deployed Communications Suite software systems.
In general, the greater the number of Communications Suite components and the greater the number of computers in your deployment architecture, the more complex will be your upgrade plan. This section discusses considerations that impact an upgrade plan.
What is an Upgrade Plan?
An upgrade plan specifies how to approach each stage of the upgrade process. This process involves, at a minimum, the phases shown in the following table.
The following sections provide information that can help in formulating an upgrade plan.
Upgrade Plan Considerations
Your upgrade plan will depend on a number of factors beyond the scope and complexity of your deployment architecture. These factors include the following considerations:
These factors are discussed in the following sections.
Upgrade Paths
While it is possible to upgrade all previous releases of Communications Suite software to Communications Suite 5, the only certified upgrades are from Java Enterprise System 2005Q4, Java Enterprise System 2005Q1, and Java Enterprise System 2004Q2. Upgrades from earlier releases are not documented in this Upgrade Guide.
The various upgrade paths involve different upgrade strategies, as described in Table 1-4.
Table 1-4 Upgrade Paths to Communications Suite 5
Product Number
Communications Suite Release
System Characteristics
Upgrade Strategies
2005Q4
Java Enterprise System 2005Q4
Communications Suite 5 supports a mixture of 2005Q4 and 5 components on a single computer. This includes both product components and shared components. Compatibilities between 2005Q4 and Communications Suite 5 components have been tested, and any known incompatibilities are noted in the Sun Java Communications Suite Release Notes.
The coexistence of 2005Q4 and Communications Suite 5 components provides for the possibility of selectively upgrading 2005Q4 components to Communications Suite 5 on a given computer, or within a deployment architecture consisting of multiple computers.
2005Q1
Java Enterprise System Release 3
Communications Suite 5 supports a mixture of 2005Q1 and Communications Suite 5 components on a single computer. This includes both product components and shared components. Compatibilities between 2005Q1 and 5 components have been tested, and any known incompatibilities are noted in the in the Sun Java Communications Suite Release Notes.
The coexistence of 2005Q1 and Communications Suite 5 components provides for the possibility of selectively upgrading 2005Q1 components to Communications Suite 5 on a given computer, or within a deployment architecture consisting of multiple computers.
2004Q2
Java Enterprise System Release 2
Communications Suite 5 does not support a mixture of 2004Q2 and Communications Suite 5 components on a single computer. This includes both product components and shared components. There are known incompatibilities between the release versions, and interoperability between 2004Q2 and Communications Suite 5 components is not certified.
When upgrading components from 2004Q2 to Communications Suite 5 on a given computer, all 2004Q2 components should be upgraded to Communications Suite 5. However, assuming compatibility of components, it is possible to mix 2004Q2 and Communications Suite 5 components residing on different computers within a deployment architecture consisting of multiple computers.
2003Q4
and priorJava Enterprise System Release 1
and priorCommunications Suite 5 does not support a mixture of Release 1 or prior releases and 5 components on a single computer. This includes both product components and shared components. There are known incompatibilities between the release versions, and interoperability between Release 1 or prior components and Communications Suite 5 components is not certified.
Communications Suite 5 does not certify the direct upgrade of Release 1 or prior releases to 2005Q4.
In some cases, however, It is possible to perform an upgrade from Release 1 by upgrading first to Java Enterprise System 2005Q1, as documented in the 2005Q1 Java Enterprise System Upgrade and Migration Guide (http://docs.sun.com/doc/819-0062).
In other cases the upgrade from Release 1 to 5 can be performed in the same way as the upgrade from 2004Q2 or 2005Q1 to 5, and in those cases, the upgrade roadmap for that component in this Upgrade Guide notes this possibility.
Upgrade Dependencies
One of the main issues in planning the upgrade of any given Communications Suite component is to understand that component’s dependencies on other Communications Suite components, and whether such other components also need to be upgraded to support the upgrade of the dependent component.
In this respect, there are two types of upgrade dependencies:
- Hard upgrade dependency. A hard upgrade dependency is when an upgraded version of a component requires an upgraded version of some component upon which it has a dependency. This requirement can be due to new functionality, new interfaces, or bug fixes needed by the dependent component. You cannot successfully upgrade and use the component without first upgrading the component upon which it depends.
- Soft upgrade dependency. A soft upgrade dependency is when an upgraded version of a component does not require an upgraded version of some component upon which it has a dependency. You can successfully upgrade and use the component without upgrading the component upon which it depends.
Upgrading a Communications Suite component requires you to upgrade all the components upon which it has hard upgrade dependencies, but allows you to not upgrade components upon which it has soft upgrade dependencies. (This general rule does not apply to upgrades from 2004Q2 to Communications Suite 5 on a single computer.)
This general rule does not necessarily apply, however, when multiple interdependent components are involved in an upgrade. In such cases, you have to upgrade a component if only one of several other Communications Suite components has a hard upgrade dependency on that particular component.
Selective Upgrade or Upgrade All
The difference between hard and soft upgrade dependencies allows for the possibility of selectively upgrading Communications Suite components within a deployed system. This possibility only applies to upgrading from 2005Q1 and 2005Q4 to Communications Suite 5 on a single computer (see upgrade path characteristics in Upgrade Paths). Selective upgrade from 2004Q2 to Communications Suite 5 on a single computer is not supported.
- Selective Upgrade. The selective upgrade approach starts with the Communications Suite component you wish to upgrade to Communications Suite 5. Determine the hard upgrade dependencies for that component, which includes dependencies on both product components and shared components. Those components also need to be upgraded. You repeat this process for each successive hard upgrade dependency until no further components need to be upgraded. This exercise specifies all Communications Suite components that need to be upgraded.
- Upgrade All. As an alternative, you can upgrade all deployed Communications Suite components to Communications Suite 5. The complexity of this approach also depends on your deployment architecture. In some cases, it simply is not feasible for business reasons to upgrade an entire system at one time.
The two approaches to performing upgrades are compared in the following table.
The choice between selective upgrade and upgrade all is not rigid. For example, you might choose to selectively upgrade the product components on a particular computer, but wish to upgrade all shared components needed to support the selected product components.
Multi-instance Upgrades
The sequence of upgrade procedures can depend on whether and how redundancy is being used in a deployment architecture. Multiple instances of a Communications Suite component can be used to achieve high availability, scalability, serviceability, or some combination of these service qualities. There are two technologies that make use of redundant components in Communications Suite deployment architectures: load balancing and high availability techniques (such as Sun Cluster and High Availability Session Store).
In most cases where redundancy is involved, it is desirable to perform upgrades without incurring downtime. These rolling upgrades attempt to successively upgrade redundant instances of a component without compromising the service that they provide.
In most cases, the redundant instances are deployed across multiple computers. From an upgrade planning perspective, this might imply isolating the upgrade of such replicated components from other component upgrades in order to achieve minimal downtime. In other words, you might perform all the pre-upgrade tasks for the component on each computer before performing a rolling upgrade of the replicated component.
Each replication technology has configuration or re-configuration procedures that might affect the overall sequence of Communications Suite component upgrades. For example, components that run in a Sun Cluster environment can require upgrading Sun Cluster before upgrading the components that are running in the Sun Cluster environment.
Communications Suite Component DependenciesAs mentioned in Upgrade Planning, an upgrade plan specifies the Communications Suite components you need to upgrade and the sequence by which you need to upgrade those components. One of the important considerations in an upgrade plan is the dependencies between the various Communications Suite components in your deployed system.
Whether you take a selective upgrade approach or you upgrade all components, the sequence by which you perform the component upgrades is affected by the nature of the dependencies between them.
This section provides information about Communications Suite component dependencies. The following dependency factors impact your upgrade plan:
Each of these factors is discussed briefly in the following sections.
Dependencies On Shared Components
When upgrading Communications Suite product components, you have to take into account dependencies these Communications Suite components have on Communications Suite shared components. When a product component has a hard upgrade dependency on a shared component, the shared component also must be upgraded.
Shared Component Dependency Matrix
Table 1-6 shows the dependencies of Communications Suite 5 product components on Communications Suite shared components. The abbreviations for product components that head the columns of Table 1-6 are taken from Table 1-1. The abbreviations for shared components are spelled out in Table 1-2.
Two product components are not included in Table 1-6: High Availability Session Store (HADB) and Directory Preparation Tool (DPT) have been omitted because they have no dependencies on shared components.
Within the matrix of Table 1-6 hard upgrade dependencies for 2005Q1 and 2005Q4 to Communications Suite 5 upgrades are marked “H,” while soft upgrade dependencies are marked “S.” For 2004Q2 to Communications Suite 5 upgrades, all shared component dependencies are, by definition, hard upgrade dependencies; all shared components must be upgraded from 2004Q2 to Communications Suite 5.
The dependencies shown in Table 1-6 for any product component represent both direct and indirect shared component dependencies. In other words, a product component might depend on a specific shared component that, in turn, depends on one or more other shared components. The shared component dependencies shown in Table 1-6 include all such indirect dependencies.
Shared Component Upgrade Guidelines
Table 1-6 lets you determine the shared components to upgrade when upgrading one or more product components on a given computer:
- 2004Q2 to Communications Suite 5 Upgrades. If you are performing an upgrade from 2004Q2 to Communications Suite 5, all the shared components marked as “S” or “H” in Table 1-6 for the respective product components must be upgraded.
- 2005Q1 and 2005Q4 to Communications Suite 5 Upgrades. If you are upgrading all product components from 2005Q1 or 2005Q4 to Communications Suite 5, all the shared components indicated in Table 1-6 for the respective product components should be upgraded.
Even if you are selectively upgrading product components, however, it is the recommended practice to upgrade the shared components needed by all product components on the computer; Communications Suite 5 shared components are certified to support 2005Q1 and 2005Q4 product components.
While selectively upgrading shared components might work in most cases (that is, upgrading only those shared components that support selectively upgraded product components, or upgrading only hard upgrade dependencies compared to soft upgrade dependencies), significantly more risk is involved in adopting this approach.
If no hard upgrade dependencies are involved, you might not upgrade shared components at all. However, as a general rule, it is a good practice to upgrade your underlying Communications Suite shared component base to the most current versions.
Note
The sequence of upgrading shared components can depend upon the shared component inter-dependencies shown in Table 1-1.
Also, if you plan to upgrade J2SE to J2SE 5.0, you should upgrade this shared component first. J2SE is the base component for some of the Communications Suite components.
For information on how to upgrade shared components, consult Chapter 2, "Upgrading Communications Suite Shared Components."
Dependencies On Product Components
Dependencies of one product component on another are an important determinant of the Communications Suite components you need to upgrade and the sequence by which you need to upgrade them. Dependencies on product components fall into two general categories: runtime dependencies and configuration dependencies.
- Runtime Dependencies. The functioning of a software system is based on the interactions between its deployed components. In upgrading any Communications Suite product component, you must take into account such dependencies. If an upgraded version of one component has a hard upgrade dependency on another component, that dependency implies that the dependent component should only be upgraded after the component upon which it depends is upgraded.
- Configuration Dependencies. In many cases, a Communications Suite component must be installed, configured, and running for another component to be configured. For example, a Directory server user/group directory must be running for you to configure Messaging Server components. Component upgrade procedures often involve re-configuration of upgraded components. In fact, some product components’ main function is to provide configuration and administrative support to other components. As a result,dependencies can have a strong impact on the sequence of upgrade procedures.
Table 1-7 shows the dependencies between the Communications Suite product components listed in Table 1-1. Using Table 1-7, you can diagram the chain of dependencies in your upgrade set. The left column lists each product component, the middle column shows its dependencies on other product components, the third characterizes each dependency, and the last column indicates whether or not the respective components must be local.
General Sequencing GuidelinesThe factors discussed in the previous sections can all impact which Communications Suite components you plan to upgrade as well as the order in which you upgrade them. These factors also influence your approach to upgrading Communications Suite components that are deployed across multiple computers. The specific impact of all these factors depends on your deployment architecture.
In general, a few sequencing guidelines apply, though not in every case. The following list provides the order in which Communications Suite and Java Enterprise System components can be successfully upgraded on a single computer or in a deployed system. When performing an upgrade, simply omit those components that are not part of your deployment architecture, or, if you are performing a selective upgrade, omit those components which are not part of your upgrade plan.
Note
The chapters in this Upgrade Guide are arranged according to the order you would normally upgrade Communications Suite components, as indicated by these sequencing guidelines. Instructions for upgrading Java Enterprise System components are documented in the Java Enterprise System Upgrade Guide (http://docs.sun.com/doc/819-6553).
- Shared Components (See Chapter 2, "Upgrading Communications Suite Shared Components")
Shared components should generally be upgraded before the components that depend on them.
- Sun Cluster software (See the Java Enterprise System Upgrade Guide)
If any components run in a Sun Cluster environment, and the Sun Cluster software needs to be upgraded, it should be upgraded before the components that use Sun Cluster services. Sun Cluster agents, if upgraded, should be upgraded as part of the Sun Cluster upgrade.
- Sun Cluster Geo software (See the Java Enterprise System Upgrade Guide)
Sun Cluster Geo should be upgraded after Sun Cluster software, upon which it depends. It should be upgraded before any components that use Sun Cluster services.
- Directory Server (See the Java Enterprise System Upgrade Guide)
Many components store user data in Directory Server, so upgrades to Directory Server should generally be performed before upgrading the components that have runtime or user lookup dependencies on Directory Server.
- Directory Proxy Server (See the Java Enterprise System Upgrade Guide)
Directory Proxy Server has a hard upgrade dependency on Directory Server and is therefore upgraded after Directory Server. Other components might access Directory Server through Directory Proxy Server.
- Web Server (See the Java Enterprise System Upgrade Guide)
A number of Communications Suite components require the support of a web container, which, if upgraded, should be upgraded before the components requiring web container services. Normally, web container services are provided by Web Server or Application Server, but if your architecture contains both, upgrade Web Server first.
- Message Queue (See the Java Enterprise System Upgrade Guide)
Message Queue, if upgraded, is best upgraded before Application Server, which requires Message Queue to be Java 2 Enterprise Edition (J2EE) compliant.
- High Availability Session Store (See the Java Enterprise System Upgrade Guide)
High Availability Session Store, if upgraded, is best upgraded before Application Server, which requires High Availability Session Store for high availability.
- Application Server (See the Java Enterprise System Upgrade Guide)
Application Server depends on Web Server for its load balancing plug in, so if you are using that capability, Application Server should be upgraded after Web Server.
- Service Registry (See the Java Enterprise System Upgrade Guide)
Service Registry can be upgraded anytime after Application Server is upgraded because it depends upon Application Server for runtime container services.
- Web Proxy Server (See the Java Enterprise System Upgrade Guide)
Web Proxy Server can be upgraded anytime, though generally it would be upgraded after the Web Server or Application Server component for which it provides a proxy service.
- Access Manager (See the Java Enterprise System Upgrade Guide)
Access Manager plays a central role in authentication and authorization, including single sign-on, and, if upgraded, should be upgraded before the components that depend on it for those services. In addition, Access Manager requires specific Directory Server schema (Schema 2), which affects how other components use Directory Server.
- Directory Preparation Tool (See Chapter 3, "Directory Preparation Tool")
Directory Preparation Tool depends on the Directory Server schema and should therefore be run against Directory Server after Access Manager is upgraded. (An exception to this guideline exists, see Chapter 3, "Directory Preparation Tool.") If upgrading Directory Preparation Tool, it should be upgraded before you upgrade the communications components that depend on Directory Preparation Tool to make changes in the directory: Messaging Server, Calendar Server, Communications Express, and Delegated Administrator.
- Messaging Server (See Chapter 4, "Upgrading Messaging Server")
Messaging Server, if upgraded, should be upgraded only after the preceding upgrades and should be upgraded before Communications Express, which has a dependency on Messaging Server components.
- Calendar Server (See Chapter 5, "Upgrading Calendar Server")
Calendar Server, if upgraded, should be upgraded after Messaging Server since some of its functions require Messaging Server support. Calendar Server should be upgraded before Communications Express, which has a dependency on Calendar Server.
- Communications Express (See Chapter 6, "Upgrading Communications Express")
Communications Express, if upgraded, depends on many of the preceding components (Calendar Server, Messaging Server, Directory Preparation Tool, Access Manager, Web Server, and Directory Server) and, if upgraded, should be upgraded after them.
- Instant Messaging (See Chapter 7, "Upgrading Instant Messaging")
Instant Messaging, if upgraded, can be upgraded at almost any point after Access Manager has been upgraded. Upgrading the Instant Messaging shared components will upgrade the server on that node: the server .jar is part of the shared components.
- Portal Server (See the Java Enterprise System Upgrade Guide)
Portal Server, like Communications Express, depends on many of the preceding components, but in particular, it depends on Communications Express to provide messaging and calendar channels, and, if upgraded, should therefore be upgraded after Communications Express.
- Portal Server Secure Remote Access (See the Java Enterprise System Upgrade Guide)
Portal Server Secure Remote Access, if upgraded, can be upgraded anytime after Portal Server has been upgraded.
- Delegated Administrator (See Chapter 8, "Upgrading Delegated Administrator")
Delegated Administrator, if upgraded, can be upgraded and used to provision users any time after Directory Preparation Tool has been upgraded and run against Directory Server. By convention, users are provisioned after other services have been upgraded and started, however, Delegated Administrator can be upgraded before upgrading the communications components that depend on Delegated Administrator for provisioning users.
Communications Suite and Solaris 10 ZonesIf you are upgrading Communications Suite in an environment using Solaris 10 zones, keep the following considerations in mind:
- (Issue Number: 6527792) If you are upgrading to Communications Suite 5 from Java Enterprise System 2005Q4, you must remove the SUNWldkx package in the global zone before upgrading shared components.
- If you want to upgrade all installed product components to Communications Suite 5, upgrade all Communications Suite shared components in the global zone, then perform the upgrade of the desired product components in the zones where they have been installed. (Communications Suite 5 shared components are backwardly compatible.)
- If you have product components installed in a non-zones environment, and you want to add non-global zones to the environment and install product components in the new non-global zones, be sure to do so in accordance with the recommended practices described in the Java Enterprise System Upgrade Guide. This might mean uninstalling components in the global zone and reinstalling them in non-global zones.
For detailed information about zones, when to use them, and instructions on upgrading a deployment that uses Java Enterprise System in addition to Communications Suite components and Solaris 10 zones see the Java Enterprise System Upgrade Guide.