This section provides information about general troubleshooting issues found in Administration Console:
Section 30.1.6, Moving the Primary Administration Console to New Hardware
Section 30.1.7, Converting a Secondary Administration Console into a Primary Console
Section 30.1.11, (Linux) Exception Processing IdentityService_ServerPage.JSP
Section 30.1.12, Backup and Restore Failure Because of Special Characters in Passwords
Section 30.1.17, Incorrect Health Is Reported on Access Gateway
Section 30.1.18, Administration Console Does Not Refresh the Command Status Automatically
Section 30.1.20, Error: Tomcat did not stop in time. PID file was not removed
Section 30.1.21, Access Manager Upgrade Hangs While Upgrading eDirectory
The following options allow you to view the status of multiple devices and identify the devices that are not healthy.
If your Access Manager components are not behaving in the way you have configured them to run, you might want to check the system to see if any of the components have configuration or network problems.
In Administration Console Dashboard, click Troubleshooting > Configuration.
All of the options should be empty, except the Cached Access Gateway Configurations option (see Step 4) and the Current Access Gateway Configurations option (see Step 5). If an option contains an entry, you need to clear it. Select the appropriate action from the following table:
Option |
Description and Action |
---|---|
Device Pending with No Commands |
If you have a device that remains in the pending state, even when all commands have successfully executed, that device appears in this list. Before deleting the device from this list, check its Command Status. If the device has any commands listed, select the commands, then delete them. Wait a few minutes. If the device remains in a pending state, return to this troubleshooting page. Find the device in the list, then click Remove. Administration Console clears the pending state. |
Other Known Device Manager Servers |
If a secondary Administration Console is in a non-reporting state, perhaps caused by hardware failure, its configuration needs to be removed from the primary Administration Console. As long as it is part of the configuration, other Access Manager devices try to contact it. If you cannot remove it by running the uninstall script on the secondary Administration Console, you can remove it by using this troubleshooting page. Click Remove next to the console that is in the non-reporting state. All references to the secondary Administration Console are removed from the configuration database. |
Access Gateways with Corrupt Protected Resource Data |
If you modify the configuration for a protected resource, update Access Gateway with the changes, then review the configuration for the protected resource and the changes have not been applied, the configuration for the protected resource is corrupted. Click Repair next to the protected resource that has a corrupted configuration. You should then be able to modify its configuration, and when you update Access Gateway, the changes should be applied and saved. |
Access Gateways with Duplicate Protected Resource Data |
After an upgrade, if you get errors related to invalid content for policy enforcement lists, you need to correct them. The invalid elements that do not have an associated resource data element are listed in this section. Click Repair. |
Access Gateways with Protected Resources Referencing Nonexistent Policies |
Protected resources have problems when policies are deleted before their references to the protected resources are removed. If you have protected resources in this condition, they are listed in this section. Click the Repair button to remove these references. Then verify that your protected resources have the correct policies enabled. Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources, then change to the Policy View. |
Access Gateways with Invalid Alert Profile References |
You can create XML validation errors on your Access Gateway Appliance if you start to create an alert profile (click Access Gateways > Edit > Alerts > New), but you do not finish the process. The incomplete alert profile does not appear in the configuration for Access Gateway, so you cannot delete it. If such a profile exists, it appears in the Access Gateways with Invalid Alert Profile References list. Click Remove. You should then be able to modify its configuration, and when you update Access Gateway, the changes should be applied and saved. |
Devices with Corrupt Data Store Entries |
If an empty value is written to an XML attribute, the device with this invalid configuration appears in this list. Click Repair to rewrite the invalid attribute values. |
When you have finished repairing or deleting invalid Access Gateway configurations, click the Access Gateways link, then click Update > OK.
(Optional) Verify that all members of an Access Gateway cluster have the same configuration in cache:
Click Troubleshooting > Configuration.
Scroll to the Cached Access Gateway Configuration option.
Click View next to the cluster configuration or next to an individual Access Gateway.
This option allows you to view Access Gateway configuration that is currently residing in browser cache. If Access Gateway belongs to a cluster, you can view the cached configuration for the cluster as well as the cached configuration for each member. The + and - buttons allow you to expand and collapse individual configurations. The configuration is displayed in XML format
To search for particular configuration parameters, you need to copy and paste the text into a text editor.
(Conditional) After viewing Access Gateway configuration (see Step 4) and discovering that an Access Gateway does not have the current configuration, select Access Gateway in the Current Access Gateway Configurations section, then click Re-push Current Configuration.
The Policies page displays the policies that are in an unusable state because of configuration errors.
In Administration Console Dashboard, click Troubleshooting > Policies.
If you have configured a policy without defining a valid rule for it, the policy appears in this list.
Select the policy, then click Remove.
The Version page displays all the installed components along with their currently running version. Use this page to verify that you have updated all components to the latest compatible versions. There are two steps to ensuring that your Access Manager components are running compatible versions:
All components of the same type should be running the same version. If you have components that display multiple versions, identify the components that need to be upgraded and upgrade them to the newer version.
All components need to be running versions that are compatible with each other.
To view the current version of all Access Manager devices:
In Administration Console Dashboard, click Troubleshooting.
Click Version.
A list of the devices with their version information is displayed. If a device also has an Embedded Service Provider, the version of the Embedded Service Provider is also displayed.
The User Sessions page helps you to find users logged into your system and also helps to terminate their sessions if required. It displays the active user details for each Identity Server. You can search for a user with the user ID and terminate the session(s).
In Administration Console Dashboard, click Troubleshooting > User Sessions.
Specify the user ID and click Search. If a match is found, it lists the IP address of Identity Server and its sessions.
Click Terminate Sessions to terminate the sessions of the specific user.
NOTE:User details are fetched once per administration session. The last updated date is displayed. To refresh the data, click on Refresh.
For more information about user sessions, see Section 30.3.28, Terminating an Existing Authenticated User from Identity Server.
The Policies page displays the policies that are in an unusable state because of configuration errors.
In Administration Console Dashboard, click Troubleshooting > Policies.
If you have configured a policy without defining a valid rule for it, the policy appears in this list.
Select the policy, then click Remove.
The System Alerts page displays how many unacknowledged alerts have been generated for all the devices imported into this Administration Console.
In Administration Console Dashboard, click Alerts.
To acknowledge and clear the alerts for a device, select the name of the server, then click Acknowledge Alerts.
The following columns display information about the alerts for each server.
Column |
Description |
---|---|
Server Name |
Specifies the name of the server receiving alerts. Click the server name to view more information about an alert before acknowledging it. |
Severe |
Indicates how many severe alerts have been sent to the server. |
Warning |
Indicates how many warning alerts have been sent to the server. |
Informational |
Indicates how many informational alerts have been sent to the server. |
In Administration Console, you can create a .ldif file that you can export for diagnostic purposes:
Log in as root.
On Linux: Change to the /opt/novell/devman/bin directory and run the following command:
./amdiagcfg.sh
On Windows: Go to the C:\Program Files (x86)\Novell\bin directory and run the following command:
./amdiagcfg.bat
Specify the Access Manager administrator’s password.
Specify the path where you want to store the diagnostic file.
Specify a name for the diagnostic file. The system adds .xml automatically as file extension.
Press Enter.
The Diagnostic Configuration Export utility is almost identical to the backup utility because it also creates a LDIF file with an addition of an XML Dump file. Passwords from the final LDIF file are removed by a program called Strippasswd.
Strippasswd removes occurrences of passwords in the LDIF file and replaces them with empty strings. If you look at the LDIF file, you will see that password strings are blank. You might see occurrences within the file or text that looks similar to password=“String”. These are not instances of passwords, but rather definitions that describe passwords as string types.
With every Access Manager release you must copy the corresponding XML style sheet file (XSL file) to the same directory where the XML file is located. This helps in displaying the information in correct format. The XSL file is located at /opt/novell/devman/bin.
The XML file along with XSL file or LDIF file (if required) can then be sent to NetIQ Support for help in diagnosing configuration problems.
If you use Administrative Tools > Services on Windows to stop Tomcat, Tomcat does not shut down cleanly and displays an error. To continue, click OK.
The following command sometimes produces an error:
net stop Tomcat7
Whichever method you use to stop Tomcat, Tomcat is stopped. Wait a minute before restarting Tomcat.
You can troubleshoot by configuring component logging. Click Devices > Identity Server > Edit > Auditing and Logging.
For more information, see Section 30.16, Using Log Files for Troubleshooting.
If a secondary console fails, you need to remove its configuration from the primary console before installing a new secondary console. If the failed console is part of the configuration, other Access Manager devices try to contact it.
On the primary console, click Troubleshooting.
In the Other Known Device Manager Servers section, click Remove next to the secondary console that is failed.
Remove traces of the secondary console from the configuration datastore:
In the Access Manager menu bar, select View Objects.
In the Tree view, select novell.
Delete all objects that reference the failed secondary console.
You should find the following types of objects:
SAS Service object with the hostname of the secondary console
An object that starts with the last octet of the IP address of the secondary console
DNS AG object with the hostname of the secondary console
DNS IP object with the hostname of the secondary console
SSL CertificateDNS with the hostname of the secondary console
SSL CertificateIP with the hostname of the secondary console
Install a new secondary console. For installation instructions, see Section 9.1, Installing Secondary Versions of Administration Console.
If you do not have any secondary consoles:
Perform a backup. For instructions, see Section 28.2, Backing Up the Access Manager Configuration.
Install Administration Console of the same type (Linux or Windows) on the new hardware using the same DNS name and IP address.
Restore the configuration. For instructions, see Section 28.3, Restoring the Access Manager Configuration.
If you have secondary consoles, you need to re-create the replica ring. When you install secondary consoles, they are added to the replica ring of the configuration datastore. The Access Manager backup script does not back up the replica ring information. It backs up only the Access Manager configuration information. The following instructions explain how you can re-create the replica ring when you install the primary Administration Console on new hardware.
Perform a backup. For instructions, see Section 28.2, Backing Up the Access Manager Configuration.
Down any secondary consoles.
Install Administration Console on the new hardware using the same DNS name and IP address that is used for the existing Primary Console.
Restore the configuration. For instructions, see Section 28.3, Restoring the Access Manager Configuration.
Remove any secondary consoles from the configuration:
In Administration Console Dashboard, click Troubleshooting.
In the Other Known Device Manager Servers section, use the Remove button to remove any secondary consoles.
Uninstall the secondary consoles. For instructions, see Uninstalling the Administration Console in the NetIQ Access Manager 4.3 Installation and Upgrade Guide.
Reinstall the secondary consoles as secondary consoles to the new primary console.
NOTE:Taking the backup of Administration Console configuration on one platform such as Linux and restoring it to another platform such as on Windows or vice versa is not supported.
To convert a secondary Administration Console into a primary Administration Console, a recent backup of Administration Console must be available. For information about how to perform a backup, see Section 28.2, Backing Up the Access Manager Configuration. A backup is necessary to restore the certificate authority (CA).
If the failed server holds a master replica of any partition, you must use ndsrepair to designate a new master replica on a different server in the replica list.
WARNING:Perform these steps only if the primary Administration Console cannot be restored. If you have a recent backup, you can restore the primary Administration Console to new hardware. This is an easier configuration task than converting a secondary console into a primary console. See Section 30.1.6, Moving the Primary Administration Console to New Hardware.
This conversion includes the following tasks:
If your primary Administration Console is running, you must log in as the administrator and shut down the service.
Linux: Start YaST, click System > System Services (Runlevel), then select to stop the ndsd service.
Windows: Open the Control Panel, click Administrative Tools > Services, then select to stop the x64 NDS Server.
Changing the master replica to reside on the new primary Administration Console makes this Administration Console into the certificate authority for Access Manager. You need to first designate the replica on the new primary Administration Console as the master replica. Then you need to remove the old primary Administration Console from the replica ring.
At secondary Administration Console, log in as root.
Change to the /opt/novell/eDirectory/bin directory.
Run DSRepair with the following options:
./ndsrepair -P -Ad
Select the one available replica.
Select Designate this server as the new master replica.
Run ndsrepair -P -Ad again.
Select the one available replica.
Select View replica ring.
Select the name of the failed primary server.
Select Remove this server from replica ring.
Specify the DN of the admin user in leading dot notation. For example:
.admin.novell
Specify password.
Type I Agree when prompted.
Continue with Restoring CA Certificates.
At secondary Administration Console, log in as an administrator.
Change to the C:\Novell\NDS directory.
Start the NDSCons.exe program.
Select dsrepair.dlm.
In the Parameters box, specify -A, then click Start
Click Partitions > Root > Designate This Server As The New Master Replica.
Open Partitions > Root, select the server, and verify that the replica is the master replica.
Run dsrepair again with -A in the Parameters box.
Click Partitions > Root, then select the name of the failed primary server.
From the menu, click Partitions > Replica Rings > Remove Server From Ring.
Specify the DN of the admin user in leading dot notation. For example:
.admin.novell
Specify password.
Continue with Restoring CA Certificates.
Perform the following steps on the machine that you are promoting to be a primary console.
Copy your most recent Administration Console backup files to your new primary Administration Console.
On a Windows 2012 server, open the Registry Editor using the regedit command.
Traverse to \HEKY_LOCAL_MACHINE\SOFTWARE\NOVELL\AccessManager\Devman key.
Update the value of the key with the IP address of the new Primary Administration Console.
Change to the backup bin directory:
Linux: /opt/novell/devman/bin
Windows Server 2012: \Program Files (x86)\Novell\bin
Verify the IP address in the backup file. The IP_Address parameter value should be the IP address of the new Primary Administration Console.
Open the backup file:
Linux: defbkparm.sh
Windows: defbkparm.properties
Verify that the value in the IP_Address parameter is the IP address of your new primary console.
Save the file.
Run the certificate restore script:
Linux: sh aminst-certs.sh
Windows: aminst-certs.bat
When prompted, specify the administrator’s password and location of the backup files.
Continue with Verifying the vcdn.conf File.
Verify whether the vcdn.conf file contains IP address of the new Administration Console. If it contains IP address of the failed primary Administration Console, replace it with the new IP address.
Change to the Administration Console configuration directory:
Linux: opt/novell/devman/share/conf
Windows Server 2012: \Program Files (x86)\Novell\Tomcat\webapps\roma\WEB-INF\conf
Run the following command in the command line interface to restart Administration Console:
Linux: /etc/init.d/novell-ac restart or rcnovell-ac restart
Windows: net stop Tomcat7
net start Tomcat7
Continue with Deleting Objects from the eDirectory Configuration Store.
Objects representing the failed primary Administration Console in the configuration store must be deleted.
Log in to the new Administration Console, then click Troubleshooting.
In the Other Known Device Manager Servers section, select the old primary Administration Console, then click Remove.
Remove traces of the failed primary Administration Console from the configuration datastore:
In the Access Manager menu bar, select View Objects.
In the Tree view, select novell.
Delete all objects that reference the failed primary Administration Console.
You should find the following types of objects:
SAS Service object with the hostname of the failed primary console
An object that starts with the last octet of the IP address of the failed primary console
DNS AG object with the hostname of the failed primary console
DNS IP object with the hostname of the failed primary console
SSL CertificateDNS with the hostname of the failed primary console
SSL CertificateIP with the hostname of the failed primary console
NCP server object
Continue with Performing Component-Specific Procedures.
If you have installed the following components, perform the cleanup steps for the component:
If you had an Identity Server installed with your failed primary Administration Console, you need to clean up the configuration database to remove references to this Identity Server.
Log in to Administration Console.
Remove Identity Server:
Click Devices > Identity Servers.
Select Identity Server that was installed with the primary Administration Console.
Remove it from the cluster, then delete it.
If you installed a third Administration Console used for failover, you must manually perform the following steps on that server:
Open the vcdn.conf file.
Linux: /opt/novell/devman/share/conf
Windows Server 2012: \Program Files (x86)\Novell\Tomcat\webapps\roma\WEB-INF\conf
In the file, look for the line that is similar to the following:
<vcdnPrimaryAddress>10.1.1.1</vcdnPrimaryAddress>
In this line, 10.1.1.1 represents the failed primary Administration Console IP address.
Change this IP address to the IP address of the new primary Administration Console.
Restart the Administration Console by entering the following command from the command line interface:
Linux: /etc/init.d/novell-ac restart OR rcnovell-ac restart
Windows: Use the following commands:
net stop Tomcat7
net start Tomcat7
For each Access Gateway Appliance imported into Administration Console, edit the settings.properties file on Access Gateway if the primary Administration Console was not configured as the Audit Server. The settings.properties file is required for JCC Communication between devices and Administration Console.
If the primary Administration Console was configured as an Audit Server, you must edit the config.xml file and the settings.properties file on Access Gateway and edit the CurrentConfig and WorkingConfig XML documents in the configuration store on the new primary Administration Console.
When the Primary Administration Console Was not Configured as the Audit Server
At Access Gateway Appliance, log in as the root user.
Open a terminal window and shut down all services by entering the following command:
/etc/init.d/novell-appliance stop
Edit the settings.properties file:
Enter: vi /opt/novell/devman/jcc/conf/settings.properties
Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.
Enter :wq! to save and exit.
At Access Gateway Appliance, start all services by entering the following commands:
/etc/init.d/novell-appliance start
(Conditional) Repeat this process for each Access Gateway that has been imported into Administration Console.
When the Primary Administration Console Was Configured as the Audit Server
On the secondary Administration Console Dashboard, click Auditing.
In Server Listening Address, change the IP address to the new primary Administration Console’s IP address.
Click Apply > OK.
(Conditional) Repeat this procedure for each Access Gateway that has been imported into Administration Console.
For each Access Gateway Service imported into Administration Console, edit the settings.properties file on Access Gateway if the primary Administration Console was not configured as the Audit Server.
If the primary Administration Console was configured as an Audit Server, you must edit the config.xml file and the settings.properties file on Access Gateway and edit the CurrentConfig and WorkingConfig XML documents in the configuration store on the new primary Administration Console.
At Access Gateway Service, log in as the root or the Administrator user.
Shut down all Access Gateway Services.
Linux: Enter the /etc/init.d/novell-appliance stop command.
Windows: Click Control Panel > Administrative Tools > Services, then stop the following services:
Apache Tomcat JCCServer
Stopping Apache Tomcat causes Apache 2.2 to also stop.
(Conditional) If your audit server was on the primary Administration Console, replace the old IP address with the new primary Administration Console IP address:
On the secondary Administration Console Dashboard, click Auditing.
In the Server Listening Address field change the IP address to the secondary Administration Console’s IP address.
Click Apply > OK.
Edit the settings.properties file:
Change to the directory and open the file.
Linux: /opt/novell/devman/jcc/conf
Windows: \Program Files\Novell\devman\jcc\conf
Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.
Save and exit.
At Access Gateway Service, start all services by entering the following command:
Linux: /etc/init.d/novell-appliance start OR rcnovell-appliance start
Windows: Click Control Panel > Administrative Tools > Services, then start the following services:
Apache Tomcat JCCServer
Starting Apache Tomcat causes Apache 2.2 to also start.
(Conditional) Repeat this process for each Access Gateway Service that has been imported into Administration Console.
For each Linux Identity Server imported into Administration Console, perform the following steps:
Log in as the root user.
Open a terminal window and shut down all services by entering the following commands:
/etc/init.d/novell-jcc stop OR rcnovell-jcc stop
/etc/init.d/novell-idp stop OR rcnovell-idp stop
Edit the settings.properties file:
Enter vi /opt/novell/devman/jcc/conf/settings.properties
Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.
Enter :wq! to save and exit.
Start the services by entering the following commands:
/etc/init.d/novell-jcc start OR rcnovell-jcc start
/etc/init.d/novell-idp start OR rcnovell-idp start
For each Windows Identity Server imported into Administration Console, perform the following steps:
Open a terminal window and shut down all services by entering the following commands:
net stop JCCServer
net stop Tomcat7
Edit the settings.properties file:
Change to the following directory:
Windows Server 2012: \Program Files (x86)\Novell\devman\jcc\conf
Open the settings.properties file.
Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.
Save your changes.
Start the services by entering the following commands:
net start JCCServer
net start Tomcat7
After the secondary console has been promoted to be the primary console, uninstall Administration Console software of the old primary Administration Console. Before uninstalling, make sure the machine is disconnected from the network. For instructions, see Uninstalling the Administration Console in the NetIQ Access Manager 4.3 Installation and Upgrade Guide.
If you want to use the old primary console as a secondary console, you need to first uninstall Administration Console software. Connect the machine to the network, then reinstall the software, designating this console as a secondary console.
The configuration datastore is an embedded version of eDirectory. If it becomes corrupted, you can run DSRepair to fix it. Or, you can restore a recent backup. To restore a backup, see Section 28.3, Restoring the Access Manager Configuration.
To run DSRepair:
In a browser, enter the following URL.
http://<ip_address>:8028/nds
Replace <ip_address> with the IP address of your Administration Console.
At the login prompt, enter the username and password of the admin user for Administration Console.
The NDS iMonitor application is launched. For more information, see Accessing iMonitor.
In the View bar, select the Repair icon.
For more information about DSRepair, see the following:
Click the Help icon.
Do not use two instances of the same browser to simultaneously access the same Administration Console. Browser sessions share settings, which can result in problems when you apply changes to configuration settings. However, you can use two different brands of browsers simultaneously, such as Internet Explorer and Firefox to avoid the session conflicts.
If you experience problems logging in to Administration Console, you might need to restart Tomcat.
In a terminal window on the console machine, restart Tomcat:
Linux: Enter the following command:
/etc/init.d/novell-ac restart OR rcnovell-ac restart
Windows: Enter the following commands:
net stop Tomcat7
net start Tomcat7
If this does not solve the problem, check the log file:
Linux: /opt/novell/nam/adminconsole/logs/catalina.out
Windows Server 2012: \Program Files (x86)\Novell\Tomcat\logs\stdout.log
Check for the following error:
Error Starting up core services. Application manager is Shutting down the Device Manager suite. Shutting down Device Manager suite.
(Linux) If you see this error, check the status of eDirectory:
Enter the following command:
/etc/init.d/ndsd status
If the status command returns nothing, start eDirectory manually.
Enter the following command:
/etc/init.d/ndsd start
Restart Tomcat.
(Windows) If you see this error, check the status of eDirectory:
Enter the following command:
net start "nds server0"
If the service has been started, this command returns a message that the service has been started. If the service has been stopped, its starts eDirectory.
Verify that the agent is running. Click Control Panel > Novell eDirectory Services, then verify that the Server box does not contain an agent closed message.
If the agent is closed, run dsrepair.
Restart Tomcat.
If you see the message Exception processing IdentityService_ServerPage.jsp on a Linux Administration Console, it is an indication that the system has run out of available file handles. You need to use the command line to increase the ulimit value (ulimit -n [new limit]), which sets the number of open file descriptors allowed.
To set this value permanently, you can create the /etc/profile.local file with the ulimit value, such as:
ulimit -n 4096
You can make changes to /etc/security/limits.conf file with a line just to change the limit for a specific user. In this case: novlwwuser. Add the following line:
novlwww soft nofile [new limit]
Administration passwords with special characters such as dollar signs might cause the ambkup utility to fail. The ambkup utility creates a command line for the ICE utility, and the special characters might be interpreted by it. If you must use special characters, and this issue arises, modify the defbkparm file so that the special characters are escaped.
For example, if the administrator’s password is mi$$le, then the field DS_ADMIN_PWD should be mi\$\$le.
This file is located in the following directory:
Linux: /opt/novell/devman/bin/defbkparm.sh
Windows Server 2012: \Program Files (x86)\Novell\bin\defbkparm.properties
When you try to create an Identity Server cluster configuration with an eDirectory user store and with the Install NMAS SAML method option enabled and you have not installed the dependent packages, the following error message is displayed:
Warning: Failed to create SAML Affiliate Object com.novell.security.japi.nmas.LoginMethodModel.getLsmWINNNTStatus()I
One of the installation requirements for the Linux Administration Console is to install the compat and the libstdc++ packages.On SLES 11, the compat package contains the libstdc++ library. Identity Server also requires the compat package. For more information about installing these packages, see TID 7006437.
If the Audit Events from Access Gateway behind NAT are not seen in the Audit Server, do the following:
Click Auditing In Administration Console Dashboard and verify if values are provided for the Server Listening IP Address, Server Public NAT IP Address, and Port Numbers fields.
If the values are not provided for the Server Listening IP Address, Server Public NAT IP Address, and Port Numbers fields, enter the values, then click Apply.
If you change the existing values and click Apply, the following message is displayed:
Step 1: Update all Access Gateways. Step 2: To update the configuration files in Administration Console, see the context-sensitive help. Step 3: Reboot all servers to start using the new configuration.
Click OK.
Update Access Gateway whose events are not seen.
Restart Access Gateway.
If Server Listening IP Address, Server Public NAT IP Address and Port Numbers are valid and still have problems, repush the configuration.
Change the port number to some invalid port number, then click Apply.
NOTE:Do not update or restart Access Gateway as the message indicates.
Change the invalid port number again to the valid port number, then click Apply.
The configuration is repushed and works successfully.
Update Access Gateway whose events are not seen.
Restart Access Gateway.
Administration Console fails to change Access Gateway listening IP address of the Reverse Proxy. The health status of Access Gateway on Administration Console displays failure to start the protected resource with old Listening IP address. However, when protected resource is viewed (Devices > Access Gateways > Access Gateway or Access Gateway Cluster > Proxy), Administration Console displays the new IP Address has been selected as listening IP address of the Reverse Proxy.
To workaround this issue:
Click Devices > Access Gateways.
Click the Health icon of Access Gateway that has the problem.
Note the Reverse Proxies that have the problem.
Click Devices > Access Gateways > Edit.
For each of the Reverse Proxies that have the problem, do the following:
Click Reverse Proxy.
Select the cluster member from the list.
Select the new IP address on which the proxy service will listen to.
Unselect the old IP address on which proxy service was listening to.
Click OK.
An alert is displayed as "Select at least one listening address for the service."
Click OK.
Again select Listening IP Address.
Click OK.
If the update link is enabled, click it. If not, do the following:
Click Edit for the cluster that has problem.
Click the Proxy name link.
Click Proxy service name in the Proxy Service list.
Enter the description and click OK.
After the device command status moves to Succeeded, verify the health status of Access Gateway.
Even after successful installation or upgrade of Access Gateway, the health shows failure in starting ESP. After an fresh import of Access GatewayAccess Manager Appliance in Administration Console, Access Gateway Health displays “ESP Failed to initialize : Unable to read <keystorefilelocation>”. The keystore file can be Connector, Signing, Encryption or Truststore.
To workaround this issue:
On Access Gateway, go to the <keystorefilelocation> location as specified in the health error message.
Delete the keystore/truststore indicated in the ESP error message.
In Administration Console Dashboard, click TroubleShooting > Certificates.
Enable the keystore device or cluster that has been deleted in the Access Gateway and it needs to be re-pushed.
Click Re-Push Certificate.
Restart server provider of Access Gateway.
In Administration Console, if the Stop Service on Audit Server Failure option is enabled, Access Gateway services are stopped and show the Health status reports services as down when the Audit server is not functioning or reachable,.
If the Stop Service on Audit Server Failure option is disabled, Access Gateway Service comes up but the related Health status still reports the services as being down.
To workaround this issue restart Tomcat.
The automatic refresh feature to retrieve device health is disabled when total number of Access Gateway devices imported to an Administration Console page is more than 20. This feature is disabled to prevent the performance overhead in getting the health of 20 or more devices simultaneously.
To workaround this issue an administrator can manually refresh the page to get the health status of the devices.
Access Manger supports only the 128-bit SSL communication among Administration Console, Identity Server, and browsers.
If you want to enable the weak ciphers (not recommended), see Section 17.7, Configuring the SSL Communication.
While stopping Tomcat for Administration Console, Access Gateway, or Identity Server, you may get this error message:
Tomcat did not stop in time. PID file was not removed.
Ignore this message. Tomcat will be forcibly stopped if it does not stop normally.
On Windows 2012 R2 Server, the Access Manager upgrade hangs while upgrading eDirectory. This occurs because the nservmsg.dll file gets locked. This is a random issue.
To workaround this issue, perform the following steps:
Manually stop the Windows Event Log service.
On the upgrade pop-up screen, click Retry.
Restart the Windows Event Log service manually again and proceed with the upgrade.