| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) E12495-01 |
|
 Previous |
 Next |
This chapter provides an overview of upgrade methods, tasks, and the planning that you must perform before you upgrade. Oracle provides two upgrade methodologies so that you can choose the one that best suits your needs. Unless explicitly stated, information applies equally to both methods. This chapter includes the following topics:
About Upgrading, Upgrade Methodologies, and Upgrade Packages
Planning Considerations for System Downtime During In-Place Upgrades
Planning Considerations for Extranet and Intranet Deployments
|
Note: This book primarily uses new product and component names. For example, Oracle Access Manager was formerly known as Oblix NetPoint or Oracle COREid. For details, see "What's New in Oracle Access Manager?". |
The latest release provides significant enhancements and regulatory compliance over previous releases. For example, each major release provides new features and additional platform support, and can include changes to the schema, data, parameter, or message files.
The term upgrade refers to the process of installing the latest major product release over an earlier product release (whether the earlier release has been patched or not).
Your existing data and configurations are made available to the new release. For example, suppose you have installed Oracle Access Manager 6.1.1 and added new object classes and panels; assigned or delegated administrative rights to key people; created workflows; protected resources with a policy domain; configured authentication schemes and authorization rules; customized the way the product looks or operates; and modified message files. After upgrading to 10.1.4, you do not need to replicate all the work you had completed on the earlier release. However, certain items must be handled manually. For more information about automated processes and manual tasks, see Chapter 3.
Starting with Oracle Access Manager 10g (10.1.4.2.0), Oracle provides two upgrade methodologies so that you can choose the one that best suits your needs. The method that you choose will determine the packages that you need::
The in-place upgrade method requires release 10g (10.1.4.0.1) component installers to upgrade existing components where they currently reside. You must upgrade each earlier component instance in your deployment. Separate platform-specific packages are provided for each component. The same 10g (10.1.4.0.1) package can be used to install or upgrade using the in-place method. For example:
|
Note: You cannot use 10g (10.1.4.3) packages for upgrading. |
The chapters in Part I of this book provide general information that you need to be aware of before you start any upgrade. Specific tasks that you need to perform for a in-place upgrade are described in Part II and Part III of this book.
Unless explicitly stated, information applies equally regardless of the upgrade method that you choose. For example:
Part IV explains how to upgrade your customizations, which is a manual task.
Part V explains how to validate the upgraded environment to ensure that everything is working properly.
Part VII provides a number of appendixes where you will find information that falls outside the scope of the main topics.
After this upgrade, Oracle recommends that you apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) and then Release 10.1.4 Patch Set 2 (10.1.4.3.0). For more information, see "Obtaining Packages for Upgrades".
The zero downtime upgrade method (also known as an out-of-place upgrade), is described in Part VI of this book. This method requires that you obtain the MigrateOAM script that is available with Oracle Access Manager 10g (10.1.4.2.0).
|
Note: The 10g (10.1.4.2.0) patch set provides tools for the zero downtime method. However, patch set packages cannot be used to install new components nor to upgrade components using the in-place upgrade method.After upgrading to 10g (10.1.4.2.0), you can apply the 10g (10.1.4.3) patch set. You cannot use 10g (10.1.4.3) packages to upgrade. |
The chapters in Part I of this book provide general information that you need to be aware of before you start any upgrade. Unless explicitly stated, information applies equally regardless of the upgrade method that you choose. As you perform the zero downtime upgrade, you will be directed to discussions outside of Part VI that apply to both methods. For example:
Part IV explains how to upgrade earlier customizations, which is a manual task.
Part V explains how to validate the upgraded environment to ensure that everything is working properly.
Part VII provides a number of appendixes where you will find information that falls outside the scope of the main topics, including troubleshooting tips.
After this upgrade, Oracle recommends that you apply the 10g (10.1.4.3) patch. For more information, see "Obtaining Packages for Upgrades".
The base release for 10g (10.1.4.3) is 10g (10.1.4.2.0). Oracle Access Manager 10g (10.1.4.3) installers cannot be used to upgrade an earlier Oracle Access Manager release.
To upgrade earlier Oracle Access Manager instances (6.x or 7.x) to 10.1.4, you must use either:
In-Place Method: Use 10g (10.1.4.0.1) installers available on OTN to perform an in-place component upgrade:.
After upgrading components in place, you can apply the 10g (10.1.4.2.0) patch and then apply the 10g (10.1.4.3) patch.
or
Zero Downtime Method: Use 10g (10.1.4.2.0) packages available on My Oracle Support (formerly MetaLink) to obtain the tools you need to perform a zero downtime upgrade.
After a zero downtime upgrade, you can apply the 10g (10.1.4.3) patch.
For more information, see "Obtaining Packages for Upgrades".
This book covers upgrades for Oracle Access Manager components only. For details about upgrading Oracle Application Server components, see Oracle Application Server Upgrade and Compatibility Guide.
Oracle Access Manager deployments fall into two categories: Identity System only or joint deployments of both the Identity and Access Systems. The upgrade tasks that must be performed, and the sequence in which you perform these tasks, depend upon the type of deployment you have. The topics in this section apply whether you choose to perform a in-place upgrade or you decide to use the zero downtime upgrade method. For more information about deployment types and upgrading, see:
Figure 1-1 illustrates a very simple Identity System-only deployment. Identified in the figure are the types of information that are upgraded for each Identity System component. As you can see, the Identity System schema and data are also upgraded.
Figure 1-1 Identity System Deployment Overview
The Oracle Access Manager schema and Identity System data reside in the directory server. Identity System schema and data upgrades are performed only once and require write access to information in the directory server.
Identity System Schema and Data Upgrades
Identity System schema and data upgrades include updating the following information types to meet requirements of the latest release:
Component information resides in the installation directory of the specific Oracle Access Manager component. The type of information that is upgraded depends on the component type: Oracle Access Manager Server or Oracle Access Manager Web component.
Identity Server Component Upgrades
Depending on the upgrade method that you use, each Identity Server component upgrade brings the following information up to release 10g (10.1.4.0.1) (in-place method) or 10g (10.1.4.2.0) (zero downtime method):
Program and library files, including message and parameter catalogs, are replaced with the latest versions.
Configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest Identity Server release.
Identity System Web Component Upgrades
WebPass is the Identity System Web component. Depending on the upgrade method that you use, each WebPass component upgrade brings the following information up to release 10g (10.1.4.0.1) (in-place method) or 10g (10.1.4.2.0) (zero downtime method):
Program and library files, including message and parameter catalogs, are replaced with the latest versions.
WebPass configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest WebPass release.
Configuration files and filters for the Web server hosting the WebPass plug-in are updated to accommodate requirements for the latest WebPass release.
Figure 1-2 illustrates the sequence of upgrade tasks that you must perform when you have an Identity System-only deployment and you are using the in-place upgrade method.
Figure 1-2 Identity System Only In-Place Upgrade Tasks and Sequence
An introduction to each task is described in "About the Execution Stage for In-Place Upgrades". For information about the zero downtime upgrade method and tasks, see Part VI.
Figure 1-3 illustrates a very simple joint deployment of both the Identity System and Access System. Identified in the figure are the types of information that are upgraded for each component. As you can see, both the Identity System and Access System schema and data are also upgraded. The same types of information are upgraded whether you use the in-place upgrade method or the zero downtime upgrade method.
Figure 1-3 Joint Identity and Access System Deployment Overview
The Oracle Access Manager schema and Identity and Access System data reside in the directory server. Schema and data upgrades include the information that is described next and require write access to information in the directory server.
Identity System Schema and Data Upgrades
Even in a joint Identity and Access System deployment, Identity System schema and data upgrades include updating the following information types to meet the requirements of the latest release:
Oracle Access Manager schema
Oracle Access Manager configuration data
Oracle Access Manager user and group data and run-time information
Oracle Access Manager workflow data
Access System Schema and Data Upgrades
Access System schema and data upgrades include updating the following information types to meet requirements of the latest release:
Additional schema updates are not typically required for the Access System unless you have directory instances configured for use by only the Access System
Component information resides in the installation directory of the specific Oracle Access Manager component. The type of information that is upgraded depends on the component type: Oracle Access Manager Server or Oracle Access Manager Web component. For example:
Identity Server and Access Server Upgrades
Depending on the upgrade method you choose, each Identity Server and Access Server component upgrade brings the following information up to release 10g (10.1.4.0.1) (in-place method) or 10g (10.1.4.2.0) (zero downtime method):
Program and library files, including message and parameter catalogs, are replaced with the latest versions.
Configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest Identity Server release.
Policy Manager, WebPass, and WebGate Upgrades
Depending on the upgrade method you choose, each Oracle Access Manager Web component upgrade (Policy Manager, WebPass, and WebGate) brings the following information up to release 10g (10.1.4.0.1) (in-place method) or 10g (10.1.4.2.0) (zero downtime method):
Program and library files, including message and parameter catalogs, are replaced with the latest versions.
Configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest WebPass release.
Configuration files and filters for the Web server hosting the Web component plug-in are updated to accommodate requirements for the latest release.
A WebPass must also be installed with each Policy Manager on the same Web server instance, at the same directory level.
Figure 1-4 illustrates the sequence of upgrade tasks that you must perform when you have a joint Identity and Access System deployment and you are using the in-place upgrade method.
Figure 1-4 In-Place Upgrade Tasks in Joint Identity and Access System Deployments
For more information, see "In-Place Upgrade Task Overview". The tasks that must be performed and their sequence will be different when you use the zero downtime upgrade method.
This discussion provides a high-level introduction to the sequence of tasks that you must perform when you use the in-place upgrade method. This is only a starting point in your planning.
You perform the entire in-place upgrade task in sequential order for the deployment approach adopted in your organization: Identity System only or Joint Identity and Access System deployment. Figure 1-5 provides a high-level view of the upgrade tasks that must be performed, and the order in which these tasks must be performed. Additional information is provided in "About the Execution Stage for In-Place Upgrades".
Figure 1-5 High-Level In-Place Upgrade Task Overview
Before you start any in-place upgrade activities, it is important to read through this entire chapter. For downtime assessment planning for in-place upgrades, see "Planning Considerations for System Downtime During In-Place Upgrades".
Whether you perform a in-place upgrade or you use the zero downtime upgrade method, you need to collect and record specific details about your existing deployment. For more information and specific details about planning, see "In-Place Upgrade Planning and Deliverables". Summary pages are provided to help you gather details about your existing deployment. For more information, see Appendix F.
This stage is illustrated in Figure 1-5 and outlined next. The sequence of tasks that you must complete is critical to your success. Summaries that can help you track the progress of upgrade tasks in your environment are provided in Appendix F.
|
Note: Task overviews like the one here outline the tasks that you must perform and provide a pointer to the discussion that provides the information you need to perform the task. For zero downtime tasks, see "Zero Downtime Upgrade Tasks and Sequencing". |
Task overview: Performing an upgrade using the in-place method includes
Planning: Develop a planning document that defines a detailed approach for each of your installed environments is described in:.
In-Place Upgrade Planning and Deliverables outline details you need to record for all earlier installed Identity and Access System components, directory servers, Web servers, and applications
In-place Schema and Data Upgrade Planning introduces considerations and sequences for schema and data upgrades
Customization Upgrade Planning discusses considerations and sequences to upgrade earlier customizations
Planning Considerations for System Downtime During In-Place Upgrades introduces strategies to minimize system downtime during the entire upgrade procedure
Planning Considerations for Extranet and Intranet Deployments are described
Upgrade Paths outlines starting releases and strategies for each one
Upgrading the Schema and Data: Prepare for and upgrade the earlier Oracle Access Manager schema and data as described in the following topics:
Preparing Remaining Components: After the in-place schema and data upgrade, you must prepare other components for the upgrade as described in Chapter 8.
Upgrading Identity System Components: Perform in-place Identity System component upgrades as described in Chapter 9 and outlined in the following list:
Upgrading Remaining Identity Servers In Place, one by one, as described
|
Note: When you have auditing and access reporting configured for a database in the earlier environment, immediately following each Identity Server upgrade you must import earlier Identity Server auditing data to a new database instance, as discussed in "Upgrading Auditing and Access Reporting for the Identity System". |
Upgrading Remaining WebPass Instances In Place, one by one,
Upgrading Access System Components: Perform the in-place Access System component upgrade as described in Chapter 10 and outlined in the following list:
Creating a Temporary Directory Profile For Access System Upgrades must be performed after upgrading the Access System schema and data and before upgrading any other Access System components as described
Upgrading Remaining Policy Managers In Place, one by one, as described
Upgrading Access Servers In Place
|
Note: When you have auditing and access reporting configured for a database in the earlier environment, immediately following each Identity Server upgrade you must import earlier Identity Server auditing data to a new database instance, as discussed in "Upgrading Auditing and Reporting for the Access Server". |
Upgraded Access Servers are automatically backward compatible with earlier WebGates. For more information, see Chapter 4.
Upgrading WebGates In Place can be staggered and performed gradually over time, as discussed in.
Upgrading Third-Party Integration Connectors: Upgrade any Oracle Access Manager connectors for third-party integration components and for the J2EE Application Server (if any are being used) as described.
Upgrading Independently Installed Software Developer Kits: Perform this upgrade to ensure the older APIs are upgraded (and ensure that any plug-ins developed using those APIs are compatible and working properly in the upgraded environment) as described.
Upgrading Customizations: This task can be started well in advance of other tasks and performed in a separate environment to reduce the amount of system downtime as described in:
Validating the Upgrade: After all other work is completed, you can verify system operation as described in Chapter 14, "Validating the Entire System Upgrade".
Oracle strongly recommends that before starting any in-place upgrade task, you and your team become familiar with all topics suggested in Figure 1-6, and the overview that follows the figure. While many of the planning deliverables are the same whether you perform an in-place upgrade or a zero downtime upgrade, if you are using the zero downtime upgrade method look for details in "Developing a Plan for a Zero Downtime Upgrade".
Figure 1-6 In-Place Upgrade Planning Overview
Task overview: Planning for an in-place upgrade
Review the following information in this chapter to get a high-level overview of the upgrade task, considerations, planning deliverables, deployment scenarios, and starting points. For more information, see:
Review Chapter 2 to gain a deeper understanding of the upgrade concepts and the methods and strategies you will use, and to learn about any applications and components that have been deprecated (no longer officially supported).
Review Chapter 3 to learn about the sequence of events that occur during the program-driven component upgrade, as well as what is preserved and what requires manual handling by you.
Investigate the functional differences between earlier releases and Oracle Access Manager 10g (10.1.4.0.1) in the centralized summary provided in Chapter 4, "System Behavior and Backward Compatibility".
|
Note: During component upgrades, backward compatibility with earlier plug-ins and WebGates is automatically enabled. However, the system might behave differently than in earlier releases. |
As you begin to plan for the upgrade in your environment, be sure to take the following considerations in to account:
Deployment Scenarios: The upgrade task should be performed in a sequential order in relation to the deployment approach adopted in your organization: Identity System only versus Joint Identity and Access System; intranet versus extranet; number and type of installed environments.
For example, if your earlier Identity System-only release is an intranet-only deployment with three different LDAP environments (one for Development, another for Test/Demonstration, and one Production deployment), the upgrade process should be performed and fine tuned in the smaller environments before ultimately being performed in your production environment. For more information about intranet or extranet deployments, see "Planning Considerations for Extranet and Intranet Deployments".
Stability: Each environment that you upgrade should currently be running a stable and appropriately installed release. In other words earlier Oracle Access Manager configurations in each existing environment must be confirmed to be stable and complete before you start upgrading.
A good approach to validate that the existing environment is stable is to develop a deterministic test script and run it both before and after the upgrade. For example, the script could exercise a full end-to-end transaction by requesting a single page that requires authentication and authorization and a workflow request (all triggered by a single page request).
Administrative Access: Schema upgrade operations (as well as other upgrade operations) require administrative access with write permissions to the directory server and Oracle Access Manager files.
Schema and Data Upgrades: Preparing an earlier master Identity System (formerly known as the COREid System) and Policy Manager (formerly known as the Access Manager component) is a critical first step to performing a schema and data upgrade. For more information, see "In-place Schema and Data Upgrade Planning".
Customization Upgrades: This is primarily a manual process. Oracle recommends that you complete any testing and alterations in a development environment before redeploying these in a shared or production environment. For more information, see "Customization Upgrade Planning".
The schema and data upgrade must be performed by someone with administrator privileges that include write access to the directory and files. The sequence of tasks you must perform to upgrade your earlier Oracle Access Manager schema and data to 10g (10.1.4.0.1) depend on the type of deployment you have (Identity System only or both the Identity and Access Systems).
The methodology for upgrading the schema and data is new and designed to help you ensure that the schema and data are properly upgraded before you start upgrading other components. This will differ slightly, depending upon your original installation.
Identity System Only: When you have only the Identity System deployed (with one or more Identity Servers and WebPass instances), you perform the schema and data upgrade, then complete other upgrade tasks as indicated in the next overview.
Task overview: Upgrading the schema and data in place with only an Identity System installed
Prepare and backup directory instances and data for the Identity System as described in Chapter 5.
Add an earlier instance of the following components to create a master environment for the schema and data upgrade:
One earlier Identity Server instance (formerly known as the NetPoint or COREid Server) as a secondary server for your original master read/write directory server instances. The directory server administrator will use this instance as the Master Identity Server when upgrading the schema and data.
One earlier WebPass to communicate with the master Identity Server you added
For more information, see "Adding An Earlier Identity System to Use as a Master for the In-place Method".
Upgrade the added master Identity System components and accept the automatic schema and data upgrade in the sequence in the following list:
Upgrade the master Identity Server, schema, and data (then upload directory index files).
Upgrade the master WebPass (there is no schema nor data upgrade here).
Validate the Identity System schema and data upgrade.
For more information about the in-place schema and data upgrade, see Chapter 6.
Prepare, then upgrade (and verify) remaining Identity System components, then integration components, then independently installed SDKs, and redeploy upgraded Identity System customizations in the sequence shown in Figure 1-5, "High-Level In-Place Upgrade Task Overview".
Joint Identity and Access System: When your installation includes both the Identity and Access Systems, the overall process is a bit different as outlined in the next overview. In both cases, the directory server administrator will use the master environment that is added before upgrading the Identity and Access System schema and data. However, the sequence differs after that.
Task overview: Upgrading the Identity and Access System schema and data in-place
Prepare for the in-place schema and data upgrade, and backup directory instances and data for both the Identity and Access System as described in Chapter 5.
Add an earlier instance of the following components:
One earlier Identity Server instance (formerly known as the NetPoint or COREid Server) as a secondary server for your original master read/write directory server instances.
One earlier WebPass to communicate with the master Identity Server you added
For more information, see "Adding An Earlier Identity System to Use as a Master for the In-place Method".
One earlier Policy Manager instance (formerly known as the Access Manager component) as a secondary server for your original master read/write directory server instances. For more information, see "Adding an Earlier Access Manager to Use as a Master for the In-Place Method".
Upgrade Identity Schema and Data: Upgrade the added master components and accept the automatic schema and data upgrade in the sequence in the following list:
Upgrade the master Identity Server, schema, and data (then upload directory index files).
Upgrade the master WebPass (there is no schema nor data upgrade here).
Validate the Identity System schema and data upgrade.
For more information about ugrading the Identity schema and data in place, see Chapter 6.
Upgrade Access System Schema and Data: Upgrade the added master component and accept the automatic Access System schema and data upgrade in the following sequence:
Upgrade the master Policy Manager, Access System schema and policy data, then upload directory index files.
Validate the Access System schema and data upgrade.
For more information about upgrading the Access System schema and data in place, see Chapter 7.
Access System: Create a temporary directory profile to provide write access to policy data by the Access Server for later WebGate upgrades, as described in "Creating a Temporary Directory Profile For Access System Upgrades".
Prepare, then upgrade (and verify) remaining Identity components, then Access System components, then integration components, then independently installed SDKs, and redeploy Identity System customizations then Access System customizations, as shown in Figure 1-5, "High-Level In-Place Upgrade Task Overview".
Customized configurations built around your earlier Oracle Access Manager installation must be manually tested for compatibility and upgraded for 10g (10.1.4.0.1). These include front-end customizations created using IdentityXML, PresentationXML, and the Access Manager API (formerly known as the Access Server API or simply as the Access API). Also included are back-end customizations created with the Identity Event API, Authentication API, Authorization API (including AccessGates and plug-ins).
Testing and upgrading earlier customizations is primarily a manual process that can take some development time. It is important to plan ahead to ensure that your customizations can be redeployed into a shared environment quickly (for example, for QA, Integration, or Production).
Recommendation: Upgrading customizations and plug-ins
Start well in advance of other upgrades and review customization considerations in "Planning Considerations for System Downtime During In-Place Upgrades".
Develop deterministic test scripts to run both before and after the upgrade to exercise a full end-to-end transaction.
For example, the script could request a single page that requires authentication and authorization and a workflow request (all triggered by a single page request). Test scripts that verify the behavior of your earlier customizations help you ensure that these work as expected and produce the same result, both before and after the upgrade. Your test scripts will depend on the specific customization being exercised.
Compile and test the code, and the instructions you developed to explain how to configure the customization in a given environment.
In your existing environment, test the earlier customization (styles, AccessGates, or plug-ins for example) to ensure it is working as expected.
Install 10g (10.1.4.0.1) in a small development environment (ideally a sandbox-type setting) where the dependency on the overall Oracle Access Manager deployment is minimal. For details, see the Oracle Access Manager Installation Guide.
In the 10g (10.1.4.0.1) sandbox, test the earlier customization and perform any manual steps needed to upgrade the customization to operate with 10g (10.1.4.0.1) functionality.
Upgrade Oracle Access Manager in the test or development environment, as described in "In-Place Upgrade Task Overview".
When the test or development environment upgrade is successful, you can redeploy the compiled binaries and custom components, then upgrade your production environment.
For information about specific customizations, see:
Planning deliverables include preparing a document where you define and record a detailed plan that identifies how the upgrade tasks will be performed within each environment. You can reduce the amount of system downtime by fine tuning the plan and tasks to meet the specific needs of each environment and to take into account the number of servers, downtime windows, and the like.
In addition, Oracle recommends that you prepare a detailed inventory of all earlier components and customizations. The details that you need to record for each component and the environment are described next. Planning summary pages provided in Appendix F.
Task overview: Developing your planning deliverables
Create a Planning Document: Define and record a detailed plan identifying how the upgrade process will be performed for each environment. For more information, see also:
Take Inventory of the Earlier Deployment: If you have not already recorded the exact details of the earlier environment, be sure to include details for Identity and Access components, directory servers, Web servers, and applications as indicated in Table 1-1. Planning summary pages provided in Appendix F.
Table 1-1 Inventory of Earlier Deployment Details
| Detail Types | Description |
|---|---|
|
Transport security mode; Simple, Cert, or Open Root CA details if certificate mode is used Any host definition type entries relevant to NetPoint (for example, /etc/host) |
|
|
Identity Server Inventory |
Workflows, search bases and ACLs Object definition details for all objects managed through NetPoint, if possible Auditing configuration details Password policy configuration |
|
Access Server Inventory |
Policy domains, authentication schemes, resource definitions, host identifiers Auditing configuration Directory profile information |
|
Application Tier details that will be impacted during the upgrade |
Any WebGate protected integration that uses Cookies or header variables (the impact on these should be minimal) Any custom AccessGate integration created using the API, which can have a more noticeable impact. Applications exposing Oracle Access Manager Identity Portal Inserts (such as portals). Look carefully at these to ensure that "service temporary unavailable" pages can be displayed during the upgrade process when access to workflows is unavailable. Applications relying on IdentityXML are significantly impacted because the IdentityXML service might be unavailable altogether (it could be complicated to separate read-only calls from write calls and might be best to disable the entire application during the upgrade process.) |
|
Administration and Presentation tier details for each WebGate, WebPass, and Web server |
Web server type, version, operating system, WebPass or WebGate identifier and exact patch version of the binary (for example, 6.1.1.19 or 7.0.4.2) Exact Oracle Access Manager patch version (for example, 6.1.1.19 or 7.0.4.2) WebPass or WebGate installation directory Connection information between the component and corresponding Oracle Access Manager Server, including primary or secondary status and number of connections |
|
Details for each and every AccessGate, WebGate, Policy Manager, application server integration Note: Policy Manager was formerly known as the Access Manager component |
HTTP Cookie domain, preferred host name, cache timeout and size, failover threshold Inventory any IdentityXML client that has been custom developed Inventory any virtual IP and DNS aliases used to reference the WebPass or Web server farm protected with WebGate, such that it would be feasible to alter their definition in cases where staged upgrade of the Web server components (WebPass and WebGate be planned/required) |
|
Oracle Access Manager Server Tier (for each Identity and Access Server |
Exact patch level (6.1.1.19 or 7.0.4.2, for example) Installation directory for the Identity or Access Server Installation directory for the associated WebPass or WebGate TCP port number for the service for example, port 6021) Host name (DNS) and Identity (formerly COREid) Server identifier For the Access Server note the status of the Access Management flag (on or off) Inventory any customizations performed Identify any Identity Event plug-ins For the Access Server, note any customized authentication or authorization plug-ins Record any file-based changes such as changes in globalparams.xml or .lst files Record any PresentationXML and XSL stylesheet customizations Are the Identity Server (and Access Server) configured to audit to files or a database For UNIX systems, record the user name and group membership for the Identity Server (formerly known as the COREid Server) |
|
Directory Server Tier |
Exact directory server version and patch level for example, Sun ONE v5.2 SP2) Directory server DNS name and Port Transport security mode: LDAP, LDAPS, ADSI Binding credentials used by Oracle Access Manager DIT and schema objects used in Oracle Access Manager Master/replica configuration details For more information, see "In-place Schema and Data Upgrade Planning" |
|
Customization Assessment and Planning |
Ensure that any custom developed plug-ins, Access Manager API clients, IdentityXML clients, PresentationXML customizations, Portal Inserts, and customized styles are compatible with Oracle Access Manager 10g (10.1.4.0.1). This is primarily a manual process. For more information, see: |
During an upgrade in any environment, system downtime is inevitable. Oracle recommends that you pay special attention to planning and coordinating with any external party that might be directly or indirectly impacted during the upgrade.
Most Oracle Access Manager deployments provide a mission-critical element of the enterprise infrastructure by supporting applications. For example, suppose Oracle Access Manager is protecting access to an employee portal, and providing a registration service for new users. During the upgrade, new users might not be able to register. Moreover, there could be a window of time during which access to the portal and any of the protected applications is not available. This can present significant impact to end users.
This discussion provides information to help you determine the amount of downtime required for the upgrade process and manual upgrade tasks in your environment. There will be some disruption to the services provided by Oracle Access Manager during some portion of the process. However, you can take steps to minimize the overall amount of service downtime. For example, if Oracle Access Manager is deployed in three environments: Development, Test/Demonstration, and Production, then upgrade tasks should be first tried in Development and fine tuned before ultimately being performed in production.
Recommendation: Upgrading each deployment in your environment
Perform the entire upgrade task, illustrated next, in your Development environment.
When your Development environment is successfully upgraded and confirmed to be running properly, perform the entire upgrade task again in your Test/Demonstration environment.
When your Test/Demonstration environment upgrade is successfully completed and running properly, you perform the entire upgrade task in your Production environment.
This approach helps you gauge the time it takes to perform the upgrade in your environment and ensure that all customizations and plug-ins are working properly before you start upgrading in a production environment. This also helps ensure that your production environment upgrade will go smoothly and quickly with fewer service interruptions.
The emphasis is on reducing the impact on availability of Oracle Access Manager (formerly Oblix NetPoint or Oracle COREid) service during the upgrade. One goal of this approach is to identify tactics that can help reduce overall upgrade time and minimize service impact. As you perform upgrade tasks within each environment, you can develop strategies and optimizations that significantly streamline the overall task.
Oracle recommends careful planning to minimize the operational impact of upgrading your earlier environment. Oracle cannot guarantee that a service outage is not required to complete the upgrade.
When planning the upgrade for each environment, it is important to take into account the criticality and number of applications that depend on Oracle Access Manager. This can increase with each environment. Pay special attention to coordinating the change process that the upgrade represents to the environment as a whole. It is important to work with the application owners to ensure that end user impact is properly managed. Standard procedures such as a change control process, scheduled maintenance windows, off hours operation windows, and others should be considered when planning the Oracle Access Manager upgrade.
When assessing the impact of the Oracle Access Manager upgrade, take inventory and categorize the various applications that depend on Oracle Access Manager. This can include applications protected by the Access System, or applications that leverage the Identity System for identity administration functions, as well as the impact on the underlying directory environments. Directory environments are particularly important because the upgrade process requires a directory schema update. In many environments, upgrading the directory schema is a highly privileged operation handled by a directory administration group.
As you take inventory and categorize the various applications, be sure to estimate potential outage windows for each application. This will help set and manage end-user expectations. The estimated duration of outage windows will vary depending on the type of application (whether it is Access System or Identity System dependent) and the estimated duration of the upgrade tasks. For the production environment, estimates can be extrapolated from the experience gained when performing upgrade tasks and fine tuning in your Development and Testing/Demonstration environments.
For more information, see:
The upgrade process will require some downtime of enterprise applications that rely on Oracle Access Manager for identity administration, authentication, and authorization. There are a few upgrade tasks that can occur without impacting these applications. Table 1-2 outlines lists the upgrade tasks, their downtime impact, and planning considerations to minimize downtime where applicable.
Table 1-2 Minimizing Downtime
| Upgrade Task | Downtime Impact | Steps to Reduce Downtime |
|---|---|---|
|
Upgrade Planning |
None |
N/A. Review the planning chapters, prepare a compendium of documentation as you take inventory of your environment. To reduce the probability of human errors, use the tracking summaries to track progress as you complete upgrade tasks. For more information about planning and tracking summaries, see Appendix F. |
|
Preparing for Schema and Data upgrades |
None |
N/A |
|
Upgrading the Schema and Data |
All Oracle Access Manager servers are down and all consumers of Oracle Access Manager are impacted. |
Make backups and be prepared with recovery procedures in case of problems. Validate the process in stage environment before trying in production. |
|
Upgrading Oracle Access Manager components |
All Oracle Access Manager servers are down and all consumers of Oracle Access Manager are impacted. |
Make backups and be prepared with recovery procedures in case of problems. Validate the process in stage environment before trying in production.Validate the upgrade in a staging environment before upgrading in production. |
|
Upgrading Third-Party Integration Connectors |
Only those third-party environments in which the deployment has chosen to upgrade the connectors. |
Validate the upgrade in a staging environment before upgrading in production. Consider that Oracle Access Manager is backward compatible with earlier environments, as described in Chapter 4, which can be exploited to minimize downtime. |
|
Upgrading Independently Installed SDKs |
Only those environments where an independently installed SDK must be upgraded are impacted. |
Validate the upgrade in a staging environment before upgrading in production. Consider that Oracle Access Manager is backward compatible with earlier environments, as described in Chapter 4, which can be exploited to minimize downtime. |
|
Upgrading Customizations |
Deployment services that rely on Identity or Access System customizations are impacted. |
Apply customizations in a staging environment first, to resolve issues. Then apply them in a production environment. |
|
Validating the Upgrade |
None |
N/A |
Perhaps the greatest amount of time spent in upgrading occurs during the planning process, which occurs offline. Careful planning can help reduce the overall amount of downtime needed to upgrade each environment in your enterprise.
The second greatest amount of time spent in the upgrade task occurs when preparing for the schema and data upgrade.
Less time will be spent actually upgrading components. Depending on your deployment and the amount of customization, some time must be allotted for any manual tasks needed to ensure that your earlier customizations are compatible with 10g (10.1.4.0.1) and are successfully redeployed. However, customizations can be handled outside the shared environment and have minimal impact on system downtime.
The following considerations are provided to help you understand the overall upgrade impact and downtime in your environment. Additional information is provided in "Downtime Assessment Example for In-Place Upgrades".
Planning and taking inventory of your existing environment, as discussed in this chapter and other chapters in Part I, is a zero downtime activity. Careful planning can actually help reduce the amount of system downtime during actual upgrade tasks.
Schema and data upgrades (introduced in "In-place Schema and Data Upgrade Planning" and described in Part II) will take the greatest amount of time, and includes:
Preparing your LDAP directory instances and data
Making backup copies of all data, installation directories, and Windows registry entries that include Oracle Access Manager information before the upgrade
Preparing a master system to use during the actual schema upgrade
Performing the actual schema upgrade
Performing the actual data upgrade, which depends upon the number of workflows and workflow steps and the number of access policies, domains, and protected resources
Verifying that the schema and data upgrade was successful
Preparing and upgrading all other Oracle Access Manager components, and Web server configuration upgrades, as described in Part III, for the most part does not require system downtime.
Manually processing customized stylesheets, plug-ins, forms-based authentication, audit to database implementations, and the like, as described in Part IV, can be performed outside the shared environment (which greatly reduces the amount of system downtime required)
Verifying that the upgrade was a success, as discussed in Part V does not result in system downtime.
The following estimates are provided to give you an idea of the amount of time it takes to upgrade an earlier deployment that includes approximately 100 workflows, 500 policy domains, 2500 access policies, and 1700 protected resources.
Identity System Downtime Assessment
Planning and Taking Inventory (of the currently installed environment): Zero downtime. This task is performed outside the environment, before the upgrade. For more information, see "Planning Deliverables".
Preparing for the Schema and Data Upgrade: ~1 hour and includes:
Developing Strategies for Upgrading in a Replicated Environment
Configuring the Challenge/Response Phrase at the Object Class Level
Configuring Unique Namespaces for Directory Connection Information
Preparing Your Directory Instances for the Schema and Data Upgrade
Adding An Earlier Identity System to Use as a Master for the In-place Method
Directory Server Backups: ~15 to 30 minutes For more information, see "Backup and Recovery Strategies".
File system Backups: ~15 minutes. For more information, see "Backup and Recovery Strategies".
Schema Upgrade: ~20 minutes
Data Upgrade: ~1.5 hours
Identity System Component Upgrades: ~5 minutes for each component (Identity Server and WebPass) instance, which includes parameter/message upgrades and Web server configuration upgrades.
Identity System Customization Upgrades (Zero Downtime): The following manual tasks can be performed ahead of the production environment upgrade and outside the shared environment. As a result, there is no system downtime for these activities:
Install and set up a fresh 10g (10.1.4.0.1) Identity System to use when testing and upgrading customizations, as described in the Oracle Access Manager Installation Guide.
Auditing and Access Reporting: Create a new database instance for use with 10g (10.1.4.0.1), as described in "Upgrading Auditing and Access Reporting for the Identity System".
Portal Inserts: "Ensuring Compatibility with Earlier Portal Inserts".
Custom Identity Event Plug-ins: Redesign and recompile custom plug-ins as described in "Migrating Custom Identity Event Plug-Ins".
Styles: Incorporate stylesheet/javascript/msgcatalog/gif customizations from prior releases, as described in Chapter 12.
Validation: Use procedures in "Validating Identity System Customization Upgrades".
Identity System Customization Redeployment: ~30 minutes. If you perform the manual customization tasks in the preceding list before upgrading, you need only copy the required files to appropriate directories after upgrading components. This should significantly reduce the amount of downtime during the production environment upgrade.
Identity System Customization After Upgrading: ~1 hour to finish tasks described in the following topics in Chapter 12:
Identity System, Total Downtime: ~5 hours
Access System Downtime Assessment
Planning and Taking Inventory (of the current installed environment): Zero downtime. This task is performed outside the environment, before the upgrade. For more information, see "Planning Deliverables".
Preparing for the Access System Schema and Data Upgrade: ~1 hour and includes:
Developing Strategies for Upgrading in a Replicated Environment
Configuring the Challenge/Response Phrase at the Object Class Level
Configuring Unique Namespaces for Directory Connection Information
Preparing Your Directory Instances for the Schema and Data Upgrade
Adding an Earlier Access Manager to Use as a Master for the In-Place Method
Directory Server Backups: ~15 to 30 minutes. For more information, see "Backup and Recovery Strategies".
File system Backups: ~15 minutes. For more information, see "Backup and Recovery Strategies".
Access System Schema Upgrade: ~20 minutes
Access System Data Upgrade: ~2 hours
Access System Component Upgrades: ~5 minutes for each component instance (Policy Manager, Access Server, WebGate), which includes parameter/message upgrades and Web server configuration upgrades.
Access System Customization Upgrades (Zero Downtime): Several manual tasks can be performed ahead of the production environment upgrade and outside the shared environment. As a result, there is no system downtime for these activities:
Install and set up a fresh 10g (10.1.4.0.1) Access System to use when testing upgraded customizations, as described in the in the Oracle Access Manager Installation Guide.
Auditing and Access Reporting: Complete this task for the Access Server, as described in "Upgrading Auditing and Reporting for the Access Server".
Forms-based Authentication: Perform activities in "Upgrading Forms-based Authentication".
Custom Authentication and Authorization Plug-ins: "Recompiling and Redesigning Custom Authentication and Authorization Plug-Ins" is described.
Updating the ObAMMasterAuditRule_getEscapeCharacter in Custom C Code is described.
Validation: Validating Access System Customization Upgrades is described.
Access System Customization Redeployment: ~30 minutes. If you perform the manual customization tasks in the preceding list before upgrading, you need only copy the required files to appropriate directories after upgrading components. This should significantly reduce the amount of downtime during the production environment upgrade.
Access System Customization After Upgrading: ~1 hour to perform tasks in the following topics in Chapter 13:
Access System Total: ~5.5 hours of downtime
Therefore, to upgrade both the Identity and Access Systems in this environment will take about 11 hours for tasks that require system downtime.
Existing earlier Oracle Access Manager deployments can be classified into two primary categories: Extranet (B2B,G2C, B2C) and Intranet (B2E, G2E) deployments. These are, of course, generic categories. However, for the purposes of understanding deployment demographics these should provide relevant patterns.
For more information, see the topics:
Extranet deployments are those where you have:
A relatively large user population (over 20 thousand users)
The user population is being served through a relatively small number of applications (less than 20)
The applications are integrated with NetPoint (Oracle Access Manager), and are typically consolidated in a portal
The most typical characteristics for extranet deployments include:
A higher complexity on the Identity System deployment relative to the Access System
A large number of workflows (self-registration, self-service, delegated administration) typically involving Identity Event plug-ins (customizations)
Sophisticated delegated administration requirements, often involving various user types (at a minimum four levels of administrative roles/access) and reliance on ACLs, groups, and other objects.
User interface customizations (accomplished using XSL stylesheets, PresentationXML, and IdentityXML) because the majority of the requirements center on identity administration of a large number of users and ease of use is a paramount driver. The majority of implementations will exhibit front end user interfaces built on top of IdentityXML.
Features such as lost password management are very commonly configured.
A relatively small software footprint (for example, only a handful of servers—2 to 4 servers at each tier—often distributed between a few data centers), and a very low tolerance for downtime because the applications that rely on Oracle Access Manager are often business critical.
Commonly the directory environment is dedicated to Oracle Access Manager and the applications it supports. Therefore, there is a bit more control over the directory service in conjunction with Oracle Access Manager from an operational perspective. There are a relatively small number of stakeholders from the application side (typically belonging to a common line of business.)
Performing the upgrade to 10g (10.1.4.0.1) with minimal service disruption in such a highly complex environment can be challenging.
Intranet deployment environments are typically:
Internal facing portals with a relatively small user population (less than 20 thousand users)
The user population is being served through a relatively large number of applications (more than 20) integrated with NetPoint (also known as Oracle Access Manager)
The most typical characteristics for intranet deployments include:
A greater prevalence of the Access System customizations, if any, are typically:
On the front-end at the login page (or login front-end)
Or using custom built AccessGates
Or on the back-end using customized authentication or authorization plug-ins developed with the APIs
A relatively large number of applications (over 20) being protected where the emphasis is primarily on authentication and single-sign on (SSO), with a significant number of application-level integrations.
A high number of BEA WebLogic and IBM WebSphere Application Server integrations using Oracle Access Manager connectors for these servers.
Often the Identity System is either not widely deployed, or deployed only to an administrator user community (for example, the help desk, IT department, or system administrators).
Password management features are not typically configured or used, because Oracle Access Manager often relies on the same back end store as the NOS (AD), and it is rare to see self-registration workflows.
These environments tend to have a broad footprint, especially at the WebGate/AccessGate tier, with a high number of Web servers and Application servers with WebGate to Access Server ratios in the range of 10:1.
On the Access Server tier, intranet deployments tend to be global and geographically distributed, with a handful of servers deployed in each location.
The directory environment is often shared, because it is the employee directory or even the NOS directory (AD). Therefore, the number of dependencies associated to the directory is high (meta-directories, provisioning solutions, NOS logon, white pages, and the like). As a result, changes and operational impact to the directory is very rigorously managed. Many stakeholders need to be coordinated with in a change-control process, and tight operational windows are allowed. On the application front, there tends to be more flexibility on server availability, and applications tend to be "clustered" by line of business, geography, or security requirements. Therefore, the impact can be segregated.
This discussion introduces the paths available when upgrading from an earlier release to Oracle Access Manager 10.1.4, regardless of the method you choose. The path that is available to you depends upon your starting release (the release from which you are starting the upgrade) as described in:
A direct upgrade path is provided from releases as early as 6.1.1. You can use either method below when upgrading directly:
In-Place Method: You can use this method with Oracle Access Manager 10g (10.1.4.0.1) installers to perform a direct upgrade to 10g (10.1.4.0.1). After an in-place upgrade, apply patch release 10g (10.1.4.2.0) and then apply patch release 10g (10.1.4.3).
Zero Downtime Method: You can use this method with tools that are available with 10g (10.1.4.2.0). After a zero downtime upgrade, apply patch release 10g (10.1.4.3).
|
See Also: Part VI, if you are using the zero downtime upgrade method. You cannot use 10g (10.1.4.3) packages for upgrading. |
Following discussions provide more information about the direct path from a specific release:
Release 6.1.1 deployments are typically large in terms of the number of components deployed at each tier of the architecture, as well as other systems and applications. Oracle Access Manager 6.1.1 is an English only release.
Every environment requires some preparation before starting the upgrade, as discussed in Chapter 5 and Chapter 8. There are no additional caveats and conditions when upgrading directly from release 6.1.1.
During the upgrade, each component installer automatically implements product changes for each release between the starting release 6.1.1 and the 10.1.4 release. This includes automatically enabling the multi-language capability.
Release 6.5.0 introduced multi-language support for French and German in addition to providing and enabling English language messages.
To retain earlier multi-language functionality, you must include 10g (10.1.4.0.1) Language Packs in the same directory as the 10g (10.1.4.0.1) installation package that you use to upgrade the component. Otherwise, only the English language is used. You can install additional supported languages after the upgrade, as described in the Oracle Access Manager Installation Guide.
Table 1-3 discusses the various 6.5 releases. During the direct upgrade from any Oracle Access Manager 6.5.x release, each component installer automatically implements product changes for each release between release 6.5.0 and the later Oracle Access Manager release.
Table 1-3 Upgrade Paths from Oracle Access Manager 6.5 Releases
| Starting From | Upgrading To | Caveat |
|---|---|---|
|
6.5.0.x is an international release (English, German, French) |
10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
Before the upgrade, perform tasks in "Adding Packages for Release 6.5.0.x". See also, "Preparing Multi-Language Installations". |
|
6.5.1 is an English-only release that introduced support for Active Directory Application Mode (ADAM) as a back end directory. |
10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
No caveats or special requirements for this English-only release. In-Place: See details in Part II, Part III, Part IV, and Part V. Zero Downtime: Upgrade as described in Part VI. |
|
6.5.2.x is an English-only release |
10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
Before upgrading an installation patched to 6.5.2, you need to perform tasks in "Adding Packages for Release 6.5.2.x Patch". |
|
6.5.3.x is an English-only WebGate release |
10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
No caveats. In-Place: See details in Part II, Part III, Part IV, and Part V. Zero Downtime: Upgrade as described in Part VI. |
With the exception of release 7.0.4 (which is an international release that was available as part of Oracle Application Server 10g Release 2 (10.1.2)), all 7.x releases are English only. Typically, NetPoint 7.x environments are newer and less complex than NetPoint 6.5 or 6.1.1 environments. You can either upgrade to 10g (10.1.4.0.1) and apply the patch set or you can use the zero downtime method, as follows:
To retain earlier multi-language functionality (or to install new languages), you must include 10g (10.1.4.0.1) Language Packs in the same directory as the 10g (10.1.4.0.1) installation package. Otherwise, only the English language is used.
Table 1-4 provides a brief overview of 7.x releases. During the direct upgrade from any 7.x release, each component installer automatically implements product changes for each release between 7.0 and Oracle Access Manager 10.1.4 and enables multi-language capability.
Table 1-4 Upgrade Paths from Series 7.x Releases
| Starting From | Upgrading To | Caveat |
|---|---|---|
|
Release 7.0 |
10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
Include Language Packs to upgrade languages if these are installed. In-Place: See details in Part II, Part III, Part IV, and Part V. Zero Downtime: See Part VI. |
|
Release 7.0.1, and later, provide additional platform certifications and parameter and message updates. Going forward, new GIFs, XSL, HTML, images, or similar files can be included in a patch release. |
10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
No caveats other than including Language Packs to upgrade languages if these are installed. In-Place: See details in Part II, Part III, Part IV, and Part V. Zero Downtime: See Part VI. |
If you are upgrading from any Oracle Access Manager release earlier than 6.1.1, no direct upgrade path is available to Oracle Access Manager 10g (10.1.4.0.1) or later. In this case, an intermediate upgrade from your earlier release to release 6.1.1 is required.
Table 1-5 lists the various starting point scenarios and associated caveats for an intermediate upgrade.
Table 1-5 Upgrade Paths from Release 5.x through 6.1
| Starting From | Upgrading To | Caveats and Conditions |
|---|---|---|
|
Release 5.2 |
Release 6.1 Release 6.1.1 10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
To retain Publisher, you can upgrade only to Oracle Access Manager 6.1. If you abandon Publisher you can perform an intermediate upgrade to 6.1.1. From release 6.1.1 you can upgrade directly to Oracle Access Manager 10g (10.1.4.0.1). For information on the intermediate upgrade, contact Oracle Support at |
|
Release 6.0 |
Release 6.1 Release 6.1.1 10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
To retain Publisher, you can upgrade only to Oracle Access Manager 6.1. If you abandon Publisher you can complete an intermediate upgrade to 6.1.1. From release 6.1.1 you can upgrade directly to Oracle Access Manager 10g (10.1.4.0.1). For information on the intermediate upgrade, contact Oracle Support at |
|
Release 6.1 |
Release 6.1 Release 6.1.1 10g (10.1.4.0.1) In Place Method 10g (10.1.4.2.0) Zero Downtime Method |
To retain Publisher, no further upgrade is possible. If you abandon Publisher you can complete an intermediate upgrade to 6.1.1. From release 6.1.1 you can upgrade directly to Oracle Access Manager 10g (10.1.4.0.1). For information on the intermediate upgrade, contact Oracle Support at |
Specific details of the intermediate upgrade from earlier releases to release 6.1.1 are outside the scope of this manual. Before you start upgrading from a release earlier than 6.1.1, contact Oracle Support at:
http://www.oracle.com/support/contact.html
After upgrading to 6.1.1, you can proceed to 10.1.4 as follows:
In-Place Method: You can use this method with Oracle Access Manager 10g (10.1.4.0.1) installers to perform a direct upgrade to 10g (10.1.4.0.1). After an in-place upgrade, apply patch release 10g (10.1.4.2.0) and then apply patch release 10g (10.1.4.3). For more information, see "Obtaining Packages for Upgrades".
Zero Downtime Method: You can use this method with tools that are available with 10g (10.1.4.2.0). After a zero downtime upgrade, apply patch release 10g (10.1.4.3). For more information, see "Obtaining Packages for Upgrades".
