Internal SekureID Communication

From sbv.wiki
Revision as of 15:27, 1 July 2020 by Stage (Talk | contribs)

Jump to: navigation, search

This document an internal document for SBV to troubleshoot communication issues with SekureID clocks.

Typically, the client will notify SBV that punches are not showing in the software. Please be aware that a clock could be sending new punches, but there was an issue within the last few days and although the clock has now reconnected, these older punches are not appearing. This issue can also manifest as new employees not appearing in the clock because the clock is sending information but is not receiving information. Before getting the client involved you need to determine if there is (or was) a communication issue. For example, if tasks were not running then punches will not be in the software. Punches could also be unassigned and not on the time cards.

You will be using the SekureID utility and advanced troubleshooting can use SQL Server Management Studio. Avoid using queries that are SELECT * and instead use TOP N where N is the number of records that you need and use ORDER BY so that the information you are looking for appears first.

Sekureidshortcut.png

You will always want to select the Company (#1) and the Serial Number (#2) that you are troubleshooting.

Sekureidutility.png

Review Logs

From the Communication / Time Logs tab, click on Get Latest Punch Received button (#3). This is equivalent to this SQL:

SELECT TOP 1 * from TimeLog where SerialNumber = 'serial number' ORDER BY LocalPunchDateTime DESC

Another query that can be helpful is:

SELECT TOP 100 * from TimeLog where SerialNumber = 'serial number' ORDER BY LogID DESC

but when a clock has been reset, the LogID of the latest punch can be less than the highest LogID ever used in that clock.

The punch date and time will be displayed and whether it has been processed by the software. You can also click on Get Latest Processed Punch Received (#4) to see what the latest punch in the software should be. This is equivalent to this SQL:

SELECT TOP 1 * from TimeLog where SerialNumber = 'serial number' AND Processed = 1 ORDER BY LocalPunchDateTime DESC

If there is a significant time gap between these 2 punches then the software may not be processing the punches. See the Software Not Processing section.

Even if it is confirmed that the latest punch received is the latest punch made on the time clock, you will still check to see when the clock last communicated to the server. Click Get Latest Device Connection Changed Log (#5) and note when this was. Now click Request Connection Status From Single Clock (#6), wait a few seconds, then click Get Latest Device Connection Changed Log (#5) again. If the clock displays a log that indicates that it was just created and the value is true then the clock is communicating and responding. Refer to the Resend Time Logs section as the clock is communicating but the punches are not up to date. If there was no change from the first and second log, or the logs always have a false value then the clock is not communicating.

The equivalent SQL is:

SELECT TOP 1 * FROM AdminLog WHERE SerialNumber = 'serial number' AND MessageType = 'DeviceConnectionChanged' ORDER BY CreatedDateTime DESC

Client Involvement

Once it is determined that the clock is not communicating and that there are no recent punches, we now need to involve the client.

Ask the client is if there are any X’s on either of the icons in the top right corner of the time clock's main screen. You can refer to this page. Multiple reboots or removing the power for a few minutes and plugging back in may also need to be done by the client.

If after rebooting there are no X’s, punches will start to upload and you can use the Get Latest Punch Received button to confirm this. There may be a need to resend punches if the clock was offline for a long time. Refer to the Resend Time Logs section.

Resend Time Logs

A clock can be instructed to resend punches. This uses the GMT Time and a maximum time span of 24 hours. Punches that are already sent will not be duplicated.

Removing Session from the Hive (Advanced)

If the admin response is true and resending time logs was unsuccessful then removing the HiveMQ session may resolve the issue. Keep in mind, this is VERY rare and does not happen often so this is a “last result” thing to do. Doing this will not do any harm but shouldn't be done until you have exhausted all other possibilities.

Open a browser on SBV26 and go to http://localhost:8080

Enter the username of "admin" and enter the password of "hivemq".

Click on Clients on the left-hand side of the page and under Client ID, type in the serial number of the clock you are having an issue with.

Hive.png

Once you have the client open, you will see an option that says Remove Session. Click on that and click Yes to the question that it asks. Redo the admin and time log steps.

Removesession.png

Final Troubleshooting (Advanced)

If after multiple reboots and removing the HiveMQ session, there is still no communication then it could be a firewall issue. You will need to get IT involved. The clocks communicate on port 8883. As the clocks generally use DHCP then any device specific rules will need to use the MAC address which is found under menu / Settings / About device.

Software Not Processing

Search for locks using the SQL Server Management Studio on the server that the client's software is located on using the following query;

SELECT * FROM Lock

Sqllock.png

In the column that says LockableObjectType, you will have two types of numbers. One will be 134 and one will be 10. The 134 means that someone, either the automatic polling or a user is polling the one or multiple time clocks. The 10 is the task that processes the punches which makes a clock punch into a punch on the employee's time card.

Look at the LockDateTime column to see when the lock was actually taken. If it was within the last few minutes then chances are it is the automatic polling and processing from the task scheduler. If it was more than a few hours ago then it could be when the software doing the overnight task it lost connection or communication to the clock and it created a lock which holds for about 12 hours. In order to release this lock you can copy and paste the query below into SQL.

DELETE FROM Lock where PkLockID = "The ID of the lock you want to release"

Deletelock.png

If we have latest punches and they are processed then there is no issue – we give client an example “We see punches, e.g. # 12345, is there a specific employee that you do not see punches for?” as it could be that they didn’t check since the punches came in.

If we have latest punches and they are not processed (there is a ‘0’ under the Processed column) then resolution is in the software, e.g. lock on processing, or lock on employee – “the clock is communicating successfully. The punches had not been processed onto the time cards”.