14 Validating the Entire System Upgrade

Activities in this chapter should be performed after upgrading the schema and data, after upgrading Identity System components, after upgrading Access System components, after upgrading integration components, SDKs, and customizations. Unless explicitly stated, topics in this chapter apply equally to both upgrade methods. Topics in this chapter include:

• Validating the Identity System Upgrade

• Validating Access System Upgrades

• Restarting On-the-fly User Data Migration for In-place Upgrades

• Deleting the Temporary Directory Server Profile

• Reverting Backward Compatibility

14.1 Validating the Identity System Upgrade

After upgrading, Oracle recommends that you perform tasks to validate that you can access and use the Identity System Console and applications. For more information about these tasks, see the Oracle Access Manager Identity and Common Administration Guide.

Note:

If you are using the zero downtime upgrade method, you will perform these tasks after upgrading the schema, the data, the clone system, and the original system. For more information, see "Validating Successful Operations in Your Environment".

To validate your Identity System upgrade

1. Identify the COREid System applications and functions that are affected by your upgrade and develop a plan to test these.

2. Delete all Web browser caches once the upgrade is complete.

3. Ensure that your Identity Server service and WebPass Web server instance are running.

4. Navigate to the Identity System Console from your browser by specifying the appropriate URL. For example:

   http://hostname:port/identity/oblix
   

   where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /identity/oblix connects to the Identity System Console.

   The Oracle Access Manager landing page should appear.

5. Landing Page Does Not Appear: Confirm that you have specified information accurately. Look for troubleshooting tips in Appendix G.

6. Perform any of the tasks listed next to verify operations, and use your own test plan as a guide:

   • View the directory server profile for this Identity Server by selecting Identity System Console, System Configuration, Directory Profiles, link_to_this_profile

   • Set up panels in the User Manager, Group Manager, Organization Manager.

   • Set up object-based searchbases in the User Manager.

   • Set up access controls in the User Manager, Group Manager, or Organization. Manager.

   • Create workflow definitions.

   • Configure options such as the mail server and session settings.

14.2 Validating Access System Upgrades

You can complete any of the next steps to validate that the Access System schema and data upgrade have been successful. For more information, see Oracle Access Manager Access Administration Guide.

Note:

If you are using the zero downtime upgrade method, you will perform these tasks after upgrading the schema, the data, the clone system, and the original system. For more information, see "Validating Successful Operations in Your Environment".

To verify a successful Access System upgrade

1. Identify the Access System functions that are affected by your upgrade and develop a plan to test these.

2. Ensure your Policy Manager Web server and WebPass Web server instance are running.

3. Delete all Web browser caches once the upgrade is complete

4. Navigate to the Access System Console from your browser by specifying the appropriate URL. For example:

   http://hostname:port/access/oblix
   

   where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.

   The Oracle Access Manager landing page should appear.

5. Landing Page Does Not Appear: Confirm that you have specified information accurately. Look for troubleshooting tips in Appendix G.

6. Log in to the Policy Manager/Access System Console as a Master Administrator.

7. Complete the following tasks, and refer to your own test plan to ensure that the Access System is working properly. For example:

   • Display configuration details for an authentication scheme by clicking the link that corresponds to the scheme.

   • Define or modify a policy domain.

   • Explore the Access System Console.

   • Access a protected resource to confirm that login is working.

8. Log out, as usual.

14.3 Restarting On-the-fly User Data Migration for In-place Upgrades

You can skip this discussion if you performed a zero downtime upgrade, or if you did not halt on-the-fly user data migration during an in-place upgrade.

You use the procedure here to restart on-the-fly user data migration only if you performed an in-place upgrade and only:

• When immediate (on-the-fly) user data migration was temporarily halted as described in Chapter 5. If on-the-fly user data migration was not halted, you can skip this procedure.

• After validating that your upgraded deployment is operating as expected and that no rollback to the earlier release is needed

Note:

If you roll back to an earlier release after performing activities here, any user data that has been migrated will not be reverted.

In the following procedure you must reconfigure the attributes used for challenge and response at both the tab level and the object class level.

Note:

If you performed an upgrade using the zero downtime method, skip this activity.

To restart on-the-fly user data migration

1. Tab Level: Reconfigure the Challenge and Response semantic types at the tab level, as follows:

   1. Click Identity System Console, then click User Manager Configuration, click Tabs.

   2. Select Employees from the list, then click Modify Attributes to open the Modify Attributes page.

   3. From the Attribute list select the attribute that is used for Challenge, set the Semantic Type to Challenge and the Display Type to Single Line Text, then click Save.

   4. From the Attribute list select the attribute that is used for Response, set the Semantic Type to Response and the Display Type to Password, then click Save.

   5. Click Done.

2. Object Class Level: Reconfigure the Challenge and Response semantic types at the object class level, as follows:

   1. Click Identity System Console, then click Common Configuration, click Object Classes.

   2. Select the person object class from the list, then click Modify Attributes to open the Modify Attributes page.

   3. From the Attribute list select the attribute that is used for Challenge, set the Semantic Type to Challenge and the Display Type to Single Line Text, then click Save.

   4. From the Attribute list select the attribute that is used for Response, set the Semantic Type to Response and the Display Type to Password, then click Save.

   5. Click Done.

3. Set the obVer attribute for oblixConfig (the configuration data root node in the LDAP directory server) to 10.1.4.0 as follows:

   ldapmodify.exe  -h <Host> \
        -p <Port> 
        -D <Bind DN> 
        -w <Bind Password> \
        -f <ldif file containing attribute to be modified>
   

   The format of LDIF file to be created is as follows. This example is for the Netscape Directory Server:

   dn: o=oblix,<configuration DN>
        changetype: modify
        replace: obver
        obver: 10.1.4.0
   

4. Restart all upgraded Identity Servers and Access Servers.

14.4 Deleting the Temporary Directory Server Profile

Regardless of the method you used for the Access System upgrade, an administrator created a temporary directory profile to grant the Access Server write access to policy data stored in the directory server. This temporary directory profile was required when the Access Server gathered configuration information stored in the WebGatestatic.lst file and updated the directory server during WebGate upgrades.

Note:

Do not perform this task until all earlier WebGates in your environment have been upgraded and verified to be working.

After upgrading all earlier WebGates and confirming proper operation of the upgraded WebGates, you can delete the temporary directory server profile.

To delete the temporary directory server profile

1. From the Access System Console, click the System Configuration tab.

2. Click Server Settings.

3. In the Configure LDAP Directory Server Profiles section, click the check box for the profile that you want to delete.

4. Click Delete.

5. When all earlier custom plug-ins and WebGates have been successfully upgraded and backward compatibility is no longer needed, proceed to "Reverting Backward Compatibility" next.

14.5 Reverting Backward Compatibility

Regardless of the upgrade method that you used, backward compatibility with earlier custom plug-ins (and WebGates/AccessGates) was enabled automatically during earlier Identity Server and Access Server upgrades.

After upgrading all older plug-ins, WebGates and AccessGates, and confirming that the entire system upgrade has been successful, Oracle recommends that you disable (revert) backward compatibility.

The steps you complete to revert backward compatibility are similar to those used to manually enable backward compatibility. For more information, see:

• Reverting Identity Server Backward Compatibility

• Reverting Access Server Backward Compatibility

14.5.1 Reverting Identity Server Backward Compatibility

After extending your custom Identity plug-ins to support UTF-8, you perform the steps in this procedure on every Identity Server in your environment whether backward compatibility was enabled automatically or manually.

To revert backward compatibility on Identity Servers

1. Upgrade all Identity System customizations as described in Chapter 12.

2. Redeploy all upgraded Identity System customizations and verify that all are working as expected.

3. Locate and open the Identity Server oblixpppcatalog.lst file in IdentityServer_install_dir\identity\oblix\apps\common\bin\oblixpppcatalog.lst.

4. Set the encoding flag from Latin-1 to encoding after the ApiVersion flag (if there is one) to provide backward compatibility for Latin-1 data. For example:

   From:

   userservcenter_view_pre;lib;;..\..\..\unsupported\ppp\ppp_dll\
        ppp_dll.dll;Publisher_USC_PreProcessingTest_PPP_Automation;;Latin-1
   

   To:

   userservcenter_view_pre;lib;;..\..\..\unsupported\ppp\ppp_dll\
        ppp_dll.dll;Publisher_USC_PreProcessingTest_PPP_Automation;;encoding
   

5. Repeat as needed for entries in this file.

6. Save the file.

7. Restart the Identity Server service.

8. Repeat for each Identity Server in the upgraded environment to revert backward compatibility.

14.5.2 Reverting Access Server Backward Compatibility

After verifying that your custom Access System plug-ins were redesigned to support UTF-8, and after upgrading all WebGates/AccessGates successfully, backward compatibility is no longer needed. In this case, Oracle recommends that you manually set "IsBackwardCompatible" Value="false" in all Access Server globalparams.xml files.

Whether backward compatibility was enabled automatically or manually, you perform the steps in this procedure on every Access Server in your environment.

To revert backward compatibility on Access Servers

1. Upgrade all Access System customizations as described in Chapter 13.

2. Redeploy all upgraded Access System customizations and verify that all are working as expected.

3. Locate and open the Access Server globalparams.xml file in AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml.

4. Set "IsBackwardCompatible" Value="false". For example:

   <SimpleList
        <NameValPair
              ParamName="IsBackwardCompatible"
               Value="false">
        </NameValPair>
   </SimpleList>
   

5. Save the file.

6. Restart the Access Server service.

7. Repeat for each Access Server in the upgraded environment.