Listed below are some problems and their possible causes, and information to help troubleshoot these problems:
Unable to Connect to Instant Messaging Redirect Server from Client
Unable to Log into Instant Messenger through the XMPP/HTTP Gateway
Messages Not Archived With Sun JavaTM System Portal Server 7 2006Q1 or Later
Instant Messenger Resource Customizations Lost After patchrm and patchadd
Catastrophic Installation Failure Leaves Server in an Inconsistent State
Instant Messaging Services Do Not Appear in the Access Manager Console (amconsole
)
You must use a client that support XMPP redirection in order to successfully deploy the redirect server. Use Instant Messenger 2006Q1 or later, or if you use a third party client, ensure that the client that supports XMPP redirection.
If the XMPP/HTTP Gateway is serving two domains and the im.jnlp file contains an argument for only one domain, users not in the listed domain cannot authenticate. For example, if the im.jnlp file contains the following argument:
<argument>domain=mydomain.siroe.com</argument> |
Users who attempt to log in from a domain other than mydomain will receive errors and cannot authenticate. To work around this problem, you need to configure Instant Messenger to authenticate to other domains.
Open the im.jnlp resource file.
Remove the domain argument entry.
For example, remove:
<argument>domain=mydomain.siroe.com</argument> |
Download Instant Messenger again.
Run Instant Messenger.
The Login page appears.
Click More Detail.
The Login page expands to show connection settings for the client.
In the Server text box, enter the URL to the gateway and append ?to=domain.
For example, if the user is part of mydomain.siroe.com, append the following to the URL:
?to=mydomain.siroe.com |
To test the configuration, log in using a valid username and password.
If you have set up a Portal Archive with Sun Java System Portal Server 7 2006Q1 or later and your messages are not being archived, ensure that the iim_arch.portal.search parameter is set in iim.conf:
iim_arch.portal.search="Portal Server Search URL" |
Where Portal Server Search URL is the Search URL for the Portal Server. For example:
iim_arch.portal.search="http://portal.siroe.com:8080/search1/search" |
(Issue Number: 6361796) The patchrm and patchadd processes redeploy the client resources. When this occurs, all customized files are overwritten. You need to back up any customized files you want to save before performing these actions.
By default, Instant Messaging uses the mail attribute to determine the email address to which it forwards instant messages when a recipient is offline. If your directory does not use the mail attribute for email addresses, you need to configure Instant Messaging to use the same attribute as your directory.
Open iim.conf.
See iim.conf File Syntax for instructions on locating and modifying iim.conf.
Change the value of the iim_ldap.user.mailattr parameter to the attribute your directory uses to contain email addresses in user entries.
If Calendar pop-ups are not being delivered as expected, you can troubleshoot the configuration as described in this section. For instructions on setting up Calendar pop-ups, see Chapter 16, Using Calendar Pop-up Reminders.
The most common error in Calendar pop-up configuration is incorrectly entered parameter names in the configuration files. This includes typos and misspelled parameter names. Ensure that you have correctly entered all of the configuration parameters and values in iim.conf and ics.conf. If you have already configured pop-ups, use Table A–11 to compare your entries with the required parameters.
If your Instant Messaging and Calendar Server configuration files are correct, but pop-ups are still not arriving as expected, ensure the Calendar client and Instant Messenger are configured correctly.
Log into the Calendar client.
Ensure that the time zone settings are correct.
If you are using Calendar Express, select Tools->Options->Settings from the menu.
Schedule an email reminder.
If you are using Calendar Express, select Tools->Options->Settings from the menu.
Save your settings.
Log into Instant Messenger with the same user.
Select Tools->Settings.
The Settings dialog box appears.
Select the Alerts tab.
Check the Show Calendar Reminders checkbox and click OK.
Leave the Instant Messenger user logged in.
Check to see whether or not the user received the email alert and pop-up at the time configured in the Calendar client.
If you did not receive the email alert, the Calendar client is incorrectly configured. Refer to the Calendar client documentation for further troubleshooting information.
If you received the email alert, but not the Calendar pop-up, and you are sure that you have configured both servers and clients correctly, check the xmppd.log for further information. You may need to set this log to a more verbose setting, for example DEBUG. For instructions on changing the log level, see To Set Log Levels for Instant Messaging Components Using iim.conf Parameters.
If you are using SSO with Sun Java System Access Manager, the Access Manager server and Instant Messaging server must be configured to use the same web container.
The following are the possible causes for this problem:
Wrong codebase in the applet page.
Application/x-java-jnlp-file MIME type not defined in the web container configuration.
Plug-in of Java Web Start not installed or functional.
No compatible Java version available.
Security exception, cannot verify signature of .jar files.
Where to get the necessary information:
In the Java Web Start or plug-in errors (exception stack trace, launch page.)
In the applet page source on the browser.
The following are the possible causes for this problem:
Either the Instant Messaging server or the multiplexor is not running.
Incorrect multiplexor host or port names used in the Applet descriptor file (.jnlp or .html).
Different SSL settings used between Instant Messenger and the multiplexor.
Client and server version mismatch.
Where to get diagnostic information:
Instant Messaging server and multiplexor log files.
Instant Messenger logs.
Instant Messenger About dialog box, Details tab.
The following are the possible causes for this problem:
Problems while accessing the LDAP server, such as the LDAP server is not running, or a provisioning error, such as a schema violation, has occurred.
End user not found.
Invalid credentials.
Invalid Instant Messenger session.
Where to get diagnostic information:
Instant Messaging server, Identity authentication, and LDAP log files.
In deployments using Sun Java System Access Manager, ensure that the user entries in your Directory contain the iplanet-am-managed-person objectclass. The Instant Messaging server uses this object class when it searches for valid users in an Access Manager deployment. For more information about this object class and how Access Manager uses it, refer to the Sun Java System Access Manager documentation.
The following are the possible causes for this problem:
The server cannot validate the session token.
Instant Messaging channel is not configured properly. For example, incorrect Instant Messaging server host, port, or both.
Plug-in or Java Web Start is not installed or is not functional.
End user not found and the Instant Messaging server cannot find the end user when performing an LDAP lookup.
Where to get diagnostic information:
Instant Messaging server and Instant Messaging channel logs.
The following are the possible causes for this problem:
Content is actually archived but the end user has insufficient rights to access it.
The content has not yet been committed to the database.
The archive provider has been disabled in the Instant Messaging server.
Where to get diagnostic information:
Instant Messaging server and the archive log files.
The following are the possible causes for this problem:
Incorrect server identification.
Mismatch in the SSL settings.
Where get diagnostic information:
The Instant Messaging server log file for both servers.
If a catastrophic error occurs while installing or uninstalling Instant Messaging, the system might be left in an inconsistent state. This results in both install and uninstall being unable to complete. In this circumstance, you must manually remove all the Instant Messaging components so that a fresh install can be attempted. The clean up procedure consists of removing packages and registry information.
Back up any information you might need in a future installation.
See Backing Up Instant Messaging Data for instructions.
Manually edit the product registry information.
For Solaris 9, issue the following command:
prodreg(1) |
For all other operating systems:
Edit productregistry.xml and remove all Instant Messaging XML elements from the file.
By default, the productregistry XML file is stored in the following locations:
Solaris: /var/sadm/install/productregistry
Linux: /var/tmp/productregistry
Remove the following packages or RPMs if they are still present:
SUNWiim
SUNWiimc
SUNWiimd
SUNWiimid
SUNWiimin
SUNWiimjd
SUNWiimm
SUNWiimc-l10n
SUNWiimd-l10n
SUNWiimid-l10n
SUNWiimin-l10n
amconsole
)If Instant Messaging uses Access Manager policies in
a Sun Java System Application Server deployment, you need to restart the Application Server when
you finish configuring Instant Messaging. If you do not restart the Application Server, Instant Messaging services
will not appear in the Access Manager console (amconsole
).