Sentinel Key Troubleshooting

Troubleshooting Steps

Note: the following is only general advice, non-specific to our clients individual environments. While we know that in most cases virtualisation of the key is possible, it is not supported, and for the entirety of this guide we will assume that the USB key is hosted on a physical machine.

Prior to commencing any of the below steps, please navigate to our sentinel error code guide, located here, as your problem may be related to a specific issue with the key itself.

Throughout this guide, we will make use of an application called the 'sentinel monitoring tool', which will show a list of active keys available on the network at any given time. This application can be downloaded via the link below:

ftp://ftp.insulagroup.com.au/Shared%20Applications/Sentinel%20Monitoring%20Tool/

Importantly too, if you do not know where the key is plugged in on the network, this can be checked by opening up the Framework Configuration Utility application (installed alongside Framework ECM), then login with your Framework credentials and navigate to the key tab. The key server name is the server where the sentinel key is hosted.

Sentinel Monitoring Tool

This is the tool that is used to display available and accessible keys over a network, as well as your hard limit, licenses in use and highest # of licenses used.

In the below example, we see server 'FWRK01', with an imaginative IP of 192.168.1.x (actual IP address will be the IP of the server).

Because this is showing in the monitoring tool, I should be able to launch Framework ECM. You should utilise this tool to determine whether the client workstations application will be able to communicate back to the key via TCP/IP.

Further general tips:

• The client workstation should be able to ping the target machine
• It should also be able to resolve the host name via a ping -a or a nbtstat -A command (via IP address)
  NB: The above does apply in every circumstance, and is only used for troubleshooting purposes.

Scenario One:

As with other services, sometimes they will stop. The same applies to the sentinel services.

If the services cease normal operational status, the ability to communicate with the key will be severed. To resolve, you can restart the services in one of two ways.

NB: the following is only to be done on the server hosting the key, and only by an experienced IT resource.

Option one - restart manually via services console.

• Open run (windows key + r), type services.msc, press ok/enter.

• From the services list, sort by name, then scroll down to 'S...' and find the below three services

• If any of the services are currently not showing a status of running, right click and select start. Then proceed to test the Framework application.

If that does not resolve your issues, proceed with the below.

• Right click on the three sentinel services and select stop, proceed to do this for all three until it displays them as blank status (not running)

• Once all three are stopped, proceed to start them again by right clicking the service and selecting start

Option Two - Restart via Command Line

• Navigate to the below location on the server
• C:\Program Files (x86)\Insula Group Pty Ltd\Common Files\Bin
• From there, double click the batch file for 'Restart Sentinel Services'
• You can also find this under Start → Insula Software → Restart Sentinel Services

From the server, open up the Sentinel Monitoring Tool, or launch Framework ECM. If it launches, it should also launch from the client workstations.

Scenario Two:

On the Framework server, in some cases there may have been an override of the windows firewall rules that are in place to allow broadcasting of the sentinel key across the network. These are the 'sentinel...' rules defined under the inbound rules. This is typically displayed as a sentinel error 601 - no active key available on the network.

In some cases, these may be incorrectly set to the wrong profile (i.e. private instead of domain). Without the domain network profile active, the key will not be shown/available on the client workstations. This may have also been incorrectly disabled, if so, enabling this rule again should allow traffic back to the key machine.

The following is to be done on the server that is hosting the sentinel key. Note: this should only be undertaken by your IT resource.

• Open run (windows key + r) and type wf.msc, press ok/enter.

• On the left hand side, select into 'inbound rules'

• You will need to look for two components of the rule, firstly, what profiles is it set against, and what is the current status of the rule. As aforementioned, a disabled rule will result in an inability for client machines to communicate back to the key.

• If the rules are disabled, then proceed to enable these rules on the applicable profile. Your systems administrator should be able to determine which profile applies to your organisation.

E.g. Domain network, rule enabled only on applicable profile, all rules enabled.

• On the client workstation, bring up the sentinel monitoring tool, set the protocol as TCP/IP, press enter/ok.
• The list of servers should enumerate, and your server/machine should be available from the list.
• If the key is now available, launch Framework ECM.

Scenario Three:

If the sentinel key is not showing in device manager, it means one of two things:

• The key has been unplugged from the machine it was plugged into
• The key was plugged into a server prior to the sentinel protection installer being installed on the key machine

Extremely unlikely:

• The USB hub has stopped working

To resolve, you can try a few things

• Plug the key into a different port on the key machine and restart the services
• Schedule to move the key to another machine that is accessible to all client machines on the network, guide is located here