Troubleshoot the AD Bridge Database

If the information in your reports or the events displayed in the Operations Dashboard seem incomplete, perform the following series of diagnostic tests sequentially:

Check the Endpoints

To troubleshoot potential endpoint problems:

  1. Log on to a computer that you suspect might have a problematic endpoint and confirm that events are logged in the local event database. Run the following command as root or as an AD user with administrator privileges:
    /opt/pbis/bin/eventlog-cli –s – localhost
  2. Note the ID of the last event. If you run the following command, the last ID in this database should match the ID if the events are getting to the collector properly. If the IDs do not match, there is a configuration issue with one of the endpoints.
    cat /var/lib/pbis/db/eventfwd-next-record.db
  3. If no recent events are displayed or if the command returns errors, make sure that the eventlog service is running:
    /opt/pbis/bin/lwsm status eventlog
  4. If it is not running, check /var/log/messages to find out why and report the information to BeyondTrust Technical Support. Then, restart the service:
    /opt/pbis/bin/lwsm start eventlog
  5. If recent events are present but are not being forwarded, make sure that the event forwarding service is running:

    /opt/pbis/bin/lwsm status eventfwd
  6. If it is not running, check /var/log/messages to try to identify the cause and report the information to BeyondTrust Technical Support. Then, restart the service:

    /opt/pbis/bin/lwsm start eventfwd
  7. Check the event forwarding service's configuration in the AD Bridge registry to make sure that it properly identifies a collector server and, if the collector server is identified by its IP address, its collector-principal. If you modify the settings of the eventfwd service, you must restart the service for the changes to take effect.

    Example of a configuration that uses the host name of its collector:

    [HKEY_THIS_MACHINE\Services\eventfwd\Parameters]
     "Collector"="w2k3-r2.example.com"
    
  8. Make sure the collector can be resolved:

    [root@rhel5d bin]# nslookup w2k3-r2.example.com
    Server:         192.168.1.20
    Address:        192.168.1.20#53
    Name:   w2k3-r2.example.com
    Address: 192.168.1.20
    
  9. Make sure the collector server can be reached:

    [root@rhel5d bin]# ping w2k3-r2.example.com
    PING w2k3-r2.example.com (192.168.1.20) 56(84) bytes of data.
    64 bytes from 192.168.1.20: icmp_seq=1 ttl=128 time=1.40 ms
    
  10. If the collector is identified by IP address, make sure the collector-principal is properly set. For example, if the collector server is at IP address 192.168.1.255 and has a Kerberos machine name of EventCollector in the AD domain example.com, the collector-principal parameter would be:

    collector-principal = host/EventCollector@EXAMPLE.COM
  11. Check /var/log/messages for errors.

  12. Stop the eventfwd service and then run it from the command line to display error information about the event forwarder's communication with the collector server:

    /opt/pbis/bin/lwsm stop eventfwd
    /opt/pbis/sbin/eventfwd --loglevel debug

    After you run eventfwd from the command line, stop it with CTRL-C and then restart it:

    /opt/pbis/bin/lwsm start eventfwd

After you verify that the endpoint is properly receiving events and forwarding them to a collector server, check the collector. If there are recent events, make a note of the last event's time stamp, event category, and event description.

To check whether the collector received the event, see Check the AD Bridge BTCollector.