10.4 Troubleshooting Session Broker Issues

This section provides information on how to troubleshoot Session Broker issues, including providing information on specific areas, and providing information on steps you can take to troubleshoot Session Broker on your system.

10.4.1 Troubleshooting Tools

  • TCPCON

    Go to Protocol Information, the click TCP > TCP Connections. Confirm that both TCP port 5001 and 5002 are listening.

  • Generate unencrypted Session Broker sessions

    When creating the Session Broker keys, use the command createnullsessionbrokerkey instead of createsessionbrokerkey. Doing this allows trace information to be obtained where username, context, authentication profile, and other user authentication attributes are visible.

  • PKTSCAN.NLM

    This allows administrators to take traces of traffic from the iChain servers going to the Session Broker servers. This can be used to verify that communication exists in both directions, and that they correct request/response data is being exchanged.

  • SB command line parameters

    Loading SB with the -d <n> option spawns a debug Session Broker screen with verbose information in it.

    n=1 Broker Listens n=2 Broker Activity n=3 Client Connects n=4 Packet detail n=5 Debug (includes everything)

    See Figure 10-2.

    Figure 10-2 Session Broker Screen

10.4.2 Troubleshooting Steps

The following are various steps you can take to troubleshoot your Session Broker issues:

  • Verify that the latest patches are installed on your system.

    All the latest iChain 2.3 patches are available at the Novell® Support Web site. They start with ic23*.exe. Check the patches to see if updates exist to either the Session Broker server (sb.nlm) or the Session Broker clients (proxy.nlm).

  • Verify that the Session Broker keys exist and are installed.

    The error “Unable to initialize the Session Broker” is often triggered if the floppy disk used to copy the keys is not formatted or includes hidden files.

  • Verify that “get authentication sessionbrokerenable” returns a yes.

  • Verify that sb.nlm loads without errors on the primary and secondary (if one exists) Session Broker servers.

    If errors are reported on the SB debug screen, they are often related to the initialization of the Session Broker keys. After the keys are generated, the Session Broker server must be rebooted.

  • Verify that no LDAP errors exist in the Proxy Console screen of the iChain servers.

    At startup, all iChain servers generate LDAP requests to the ISO object to get the Session Broker configuration attributes. If any LDAP communication issues exist, the iChain servers might not get the Session Broker information, and might result in issues.

    LAN traces with PKTSCAN can also confirm that LDAP information was received correctly.

  • Verify that authentication with no SB works properly.

    If the main proxy authentication engine has problems with authenticating users, the Session Broker services are also likely to fail.

  • Verify that the issue being experienced is not load-related.

    We recommend that a dedicated Session Broker server be used. In cases where the Session Broker server is running on an iChain server with accelerators enabled, try to create a dedicated Session Broker server to see if your problem still exists.