If you are upgrading Access Manager to Access Manager 7 2005Q4, the ampre70upgrade script does not remove any Access Manager localized packages that you have on your system.
Workaround: Before you upgrade to Access Manager 7 2005Q4, use the pkgrm command to manually remove any localized Access Manager packages that are installed on your system.
After Access Manager and Application Server are upgraded to Java ES 2005Q4 versions, the Access Manager AMConfig.properties file has an old version of Application Server.
Workaround: Before you run the Delegated Administrator configuration program (config-commda), change the following property in the AMConfig.properties file:
After upgrading Access Manager, the node agent server.policy file isn't updated.
Workaround: Replace the server.policy file for the node agent with the following file:
After upgrading Access Manager from version 2005Q1 to version 2005Q4, the Session Property Condition is not displayed as a choice in the policy Condition list if you try to add a Condition to a policy.
Workaround: Select the Session Property Condition type in the policy configuration service template at the corresponding realm.
After upgrading Access Manager from version 2005Q1 to version 2005Q4, the Identity Subject, a newly added policy subject type, is not displayed as a choice in the policy subject list.
Workaround: Select the Identity Subject type as a default subject type in the policy configuration service template.
During the upgrade of Access Manager from Java ES 2004Q2 to Java ES 2005Q4, the upgrade from Java ES 2004Q2 to Java ES 2005Q1 failed. Access Manager was being deployed on Application Server, which was also being upgraded from Java ES 2004Q2 to Java ES 2005Q4. The classpath in the domain.xml file did not have Access Manager JAR file paths.
Workaround: Follow these steps:
Before running the amupgrade script, re-index Directory Server, because of a problem with the comm_dssetup.pl script.
Add entries for Access Manager to the server.policy file of the node agent. A copy of server.policy from the default server policy (/var/opt/SUNWappserver/domains/domain1/config/server.policy) is sufficient.
Update the classpath in the domain.xml file of the node agent as follows. Copy the classpath-suffix and relevant classpath from the server-classpath attributes of the java-config element from the server.xml file to the respective attributes in the java-config element of domain.xml. The java-config element can be found under the config element in domain.xml.
After Access Manager was upgraded from version 6 2005Q1 to version 7 2005Q4, the amadmin --version command returned the wrong version: Sun Java System Access Manager version 2005Q1.
Workaround: After you upgrade Access Manager, run the amconfig script to configure Access Manager. When you run amconfig, specify the full path to the configuration (amsamplesilent) file. For example, on a Solaris system:
# ./amconfig -s ./config-file
# ./amconfig -s /opt/SUNWam/bin/config-file
The user's role does not display under an organization that was not created in Access Manager. In debug mode, the following message is displayed:
ERROR: DesktopServlet.handleException() com.iplanet.portalserver.desktop.DesktopException: DesktopServlet.doGetPost(): no privilige to execute desktop
This error becomes evident after the Java ES installer migration scripts are run. The ContainerDefaultTemplateRole attribute is not automatically added to the organization when the organization is migrated from an existing directory information tree (DIT) or from another source.
Workaround: Use the Directory Server console to copy the ContainerDefaultTemplateRole attribute from another Access Manager organization and then add it to the affected organization.