Open

Release notes | 10.4

Table of contents

1. Introduction

These release notes provide information about the latest features of iProtect, including required software versions and hardware installation and operating manuals.

2. System requirements

This chapter lists the required hardware and software for iProtect, including the licensing scheme of iProtect upgrades and other important information.

2.1 Supported servers

For installation and support of the iProtect server, the system requirements of Ubuntu server are followed. This may differ depending on system use and size.
In addition, the duration of support is determined by the lifespan of the hardware. This is issued by the hardware manufacturer and described as MTBF (Mean Time Between Failure).

2.2 Hardware specification

The hardware specification depends on many variables, so the required specification is customer specific.

Guide lines for 2500 card users and 250 readers and 5 concurrent users*.

2.3 Software

The required operating system version for iProtect:

For iProtect 10.04 and Ubuntu 20.04, there is a TKH repository with all needed files for installing and maintaining the setup files.

The operating system can be downloaded from Ubuntu's default repository.

2.4 Update policy

TKH security works non-stop to improve its products and their safety.
From iProtect version 10.4, the software version from which you update and the software version to which you update must be taken into account.

Why is this change? The security policy prevents newly installed software from working or communicating with software that does not meet these security requirements, so that a roll-back will no longer work.

2.4.1 Which iProtect version supports which Pluto RootFS

To ensure a reliable and secure system, the following software versions are required:

2.5 Software and firmware

Software versions of the connected hardware are managed from iProtect by default.
Below you will find an overview of the most used hardware and the minimum version that are installed (provisioned) when updating iProtect.

2.6 Encrypted JDBC connection

Required .Jar files for iProtect v10.03.xx and higher:

• java-library-xx.x.x.jar

• keyprocessor-jdbc-xx.x.x.jar

• log4j-api-x.x.xx.jar

• log4j-core-x.x.xx.jar

• icu4j-73.1.jar

  • to ensure correct sort order for non ASCii characters (10.3.15+, 10.4+)

• tyrus-standalone-client-x.xx.jar

2.6.1 API documentation available (on request)

If desired, new API documentation is available:

• JDBC over SSL

• iProtect XML API v2.16

2.6 License

When a major version number changes, it should be taken into account in advance that a new license is necessary. Please contact TKH Security service department or your account manager for this.

2.7 Browser support

All tests are done with default browser settings, if some functionalities require changes to the settings, this will be mentioned in the specific manual. The following browsers are supported in iProtect:

3. End of support

• Sirius 1 support in combination with Reader manager version 6

3.1 Advance notice

Making use of the hta-tool can entail security risks. That was the reason we wanted to deprecate this.
Since many customers are still using this tool, an option has been added to continue using this hta tool. This usage is disabled by default.

The following option has been added to the dialog:

• Installation | Settings | System parameters, tab: Other, “HTA enable”.

3.2 Pre-announcement

3.2.1 Network controller

• Polyx Network controller: End of life: 31-12-2025

• Apollo 1: End of life: 31-12-2025

• iPU-8: End of life per: 31-12-2025

3.2.2 Support of INVR / License plate recognition on Polyx and IPU-8

iProtect 10.4 will be the last version which supports an iNVR Node on a iPU-8 or Polyx controller. If this situation occurs, the advise is to move the INVR node to a local server line.

4. iProtect server and application

This chapter describes the additions and/or changes of the application.

General improvements are:

• 64bit database.

• Log functionality by all services (for analyzing purposes).

• Sense maintenance: Reduce the amount of getdivalist calls.

• New date time format support carddata interpretation (DDxMMxYYYY where x could be any seperator).

• Output table increased form 8192 to 12280.

4.1 DOM API support with mobile devices

Establishing a close collaboration with DOM Security, we have developed a solution to gain access to both wired and battery-powered locks with a mobile device or traditional MIFARE DESFire tag or card. IPROTECT connects to the DOM controller(s) based on a REST API. The connection works in real time, so both systems are always fully synchronized. No more use of “old-fashioned” XML import and export files. Now, customers have one technology partner that offers a seamlessly integrated solution for hardware, software, mobile app, and cloud services.

For more information, please consult the manual: IPROTECT Access - DOMBox API-integration

4.2 Pager charging cabinet - Ooperon / Pager services

Effectiveness is important to prevent many 'expensive’ pagers from remaining unused in the charging station. When presenting a valid access card to a specific card reader, an event is sent automatically to the (Ooperon or Pager services) server containing the personal pager number, name, location and profile number (which are managed in iProtect). This immediately loads the profile of the employee into a charged available pager.

• The number of pagers in use is optimized as much as possible.

• Pager number and profile managed by iProtect.

• Pager requests logged in iProtect.

For more information, please consult the manual: *iProtect™ - Pager charging cabinet - Ooperon / Pager services

4.2.1 Extensive functionalities and support

• Support Ooperon CV4-v7 protocol

• Support Pager Services

• Single call or groups call

• Number of characters of display text can be limited

• Send the person's name to the pager or a separate pager name

• Personal name can be limited to number of characters (16)

4.3 Deister Key Cabinet

A key cabinet is a lockable cabinet that can hold a large number of KeyTags. These KeyTags are locked in specific positions that are monitored and controlled by the management software. iProtect reads all linked Deister cabinets, including panels and key positions. It is therefore important that the key cabinet(s) are correctly created and configured within the Deister software. By presenting an identification means (i.e. access card) to the reader that is connected to the key cabinet, the cabinet is unlocked. In iProtect you can define which person can take out one or more KeyTags. Every handling will processed and registered in iProtect.

4.3.1 Extensive functionalities and support

• Generate alarm if key fob is not returned in time

• Only allowed to take a KeyTag from Keycabinet when person is present

• Determine the maximum number of KeyTags is owned

For more information, please consult the manual: iProtect - Deister Key Cabinet

4.4 Functionality

iProtect contains many functionalities that can make it difficult for a system user to determine which fields should be used. To increase the user-friendliness of the user interface, only the functions that are actually used can now be enabled.

Functionality groups can be added and per group it can be defined which functionalities should be assigned to it. The functional group must then be added to a user group.

The following menu has been added:

• Installation | Authorization | Functionality group

The following option has been added to the dialog:

• Installation | Authorization | User group. Select “Functionality group”.

For more information, please consult the manual: *iProtect™ Functionality group

4.5 Check data through an external web service

An option has been added to (for example, by presenting an encrypted QR code to a reader) decode data and checked by an external provider/ Web service.

The following option has been added to the dialog:

• Installation | Hardware | Reader. Select “Authentication method”.

4.6 Output type added

To be able to send an output based on the LED behavior of the card reader, the following option has been added to the dialogs:

• Installation | Hardware | Output. Select “Source”.

• General | Settings | Logical programming | Logical expression. Select “Source”.

4.7 Output follows interlocking status

To be able to send an output based on the status of a group of doors (interlocking). Sending an output based on the status of a group of doors (locking)
This function allows multiple door groups (interlocking) to be physically linked together and extend the interlocking function.

The following option has been added to the dialog:

• Installation | Hardware | Output | Select “Source”

4.8 Structure of dialogues adjusted

To make the dialogues more readable, tabs have been added. After opening the dialog, only the primary fields will initially be shown.

The following option has been added to the dialog:

• Installation | Hardware | Node

• Installation | Hardware | Line, Select “Function of the line”, Virtual line.

4.9 Locking pulse

The following option has been added to the dialog:

• Installation | Hardware | Reader

  • Tab: Input/Output | Output

    • Locking pulse (new output type)

  • Tab: Door behavior | Door control | Unlock behavior:

    • Pulse open output + pulse close output

      • Requires the use of the <Closing pulse> output

        • Requires the use of the <Deadbold> input

        • Requires the setting <Unlocking behavior>

        • The <Door control> will now follow the <Pulse time for opening and closing>

        • The <Closing pulse> will follow the <Pulse time for opening and closing>

Basic function

4.10 Copy/Paste Card data interpretation

When selecting an existing Card data interpretation in the tree-view, copy- or paste options have been added.

The following option has been added to the dialog:

• Access | Settings | Card data interpretation

4.11 TANLock - Provisioner element added to the reader

In the Node dialog, a firmware element can now be selected and in the Reader dialog, the reader settings/configuration. Previously this was only possible to provision this from the Node.

The following option has been added to the dialog:

• Installation | Hardware | Node

• Installation | Hardware | Reader

4.12 UID support TANLock

With the TANLock reader, a 7 byte UID configuration can be set as a provisioner group.

The following option has been added to the dialog:

• Installation | Hardware | Reader

4.13 Authorization group is added to Guarded area group

An Authorization group is added to Guarded area group

The following option has been added to the dialog:

• Installation | Hardware | Alarm system | Guarded area group

4.14 Pincode field is moved to the person dialog

Because only 1 PIN code can be used, the PIN field that could be entered with the card has been moved to the person dialog.

The following option has been added to the dialog:

• General | Person

4.15 Enable NAT on Network controller

It is now possible to create two Nodes with the same IP-address communicating with the same Network controller.

The following option has been added to the dialog:

• Installation | Hardware | Line

4.16 Menu bar

The menu bar is changed. The menu options have moved to the left because “file” has been dropped. Instead, two entries have been added to the right side of the menu bar

4.16.1 Menu bar: Help and About

By pressing the question mark , help and about can be chosen.

4.16.2 Menu bar: Change password and Log out

To allow a system user to manage his or her own password, a menu entry has been added to the menu bar.

When pressing on the person-icon , the login password- and system language can be changed.

4.17 SimonsVoss Wireless online Keypad reader

The keypad reader can be used as an alternative access or as additional authentication for an SV wireless online reader by entering a PIN code into the keypad reader.

The access management of the PIN code cards takes place entirely in iProtect.

For more information, please consult the manual: https://tkhsecurity.atlassian.net/wiki/spaces/IP/pages/9847275597

4.18 Reader access rights events

If you add or remove a reader with a specific time zone directly to or from a Card (Reader list below the card), an event is generated in iProtect.

4.19 Number of intercom stations increased

The number of intercom stations to be connected is increased from 800 to 1200.

4.20 Online and offline readers in one reader group

It is possible to create a reader group of online- (Sirius-iX) and offline (OSS) readers.

4.21 Support re-calculation on card-numbers

It is possible to perform automatic expression on the source data read from the card to calculate the card number.

4.22 UNii intrusion panel improvements

• The UNii now supports UTF8 (previous ASCII), we have better support for various characters in all languages.

• Equip information record UNii version 3 implemented

4.23 TrakaWeb integration with salary number

When the connection with the TrakaWEB service is established, the following information is synchronized between the iProtect database and the TrakaWEB database for the cards that are member of the card group defined in the service details form:

• Person Name

• Salary number (in Traka: Staff Number)

• Card number

• Validity

• Expiration date

4.24 Support of License Plate Recognition camera

Our new supported IPC-ANPR camera, is a standalone and easy to install OSDP camera. LPR is performed entirely inside the camera, no LPR server needed. When using our new IPC-ANPR camera (License plate recognition) in OSDP mode, an option is added to be able to interpret data correctly. Introduced in version 10.4.14.

4.25 Active Directory (LDAP) - Automatic Card Activation

If someone’s status is updated in Active Directory (LDAP) to active or inactive, their card access rights will automatically turn on or off.  Introduced in version 10.4.14.

4.26 Support of Galaxy Flex intrusion panel

The Galaxy Flex panel is now compatible with iProtect’s intrusion features. Introduced in version 10.4.14.

4.27 Number of supported Alarm output has been increased

The number of alarm outputs supported within iProtect has been increased to 32,768 (was 16384). Introduced in version 10.4.14.

4.28 Adjustment handling Confirm mode

When no card queue is used, confirmation mode handling is modified.

How does it work?

When a second card is presented before the first is approved by the operator, both cards are processed together. If you’d prefer each card to be processed separately, the card queue option can be applied. . Introduced in version 10.4.14.

4.29 Read card before loop activation

A generic option has been added when using the loop function. It is now possible to create a wait function in 1/10 of seconds. So after presenting a valid access card, how long does it take before the loop is created.