The various vendors use for their CLI different operating modes or 'states'. Separate states usually exist for requests (like 'show') and configuration changes. NetYCE vendor modules would loose track of the effective state when a configuration job was instructed to drop from configuration mode but was later to be expected to resume from the same mode.

Enhancements were made to the vendor modules to keep track of the current state and automatically assume the required state from the job context to result in a more reliable job handling.

Under the Admin menu the 'Edit configs' tool is available to view and change the various NetYCE configuration files. Depending on the type of the configuration file, changes are automatically synchronized between the different NetYCE servers or remain local.

Of all available configuration files only a few were visible in the 'Edit config' tool. For every configuration file, an entry is needed in the YCE config-file synchronization configuration file to define its permissions and synchronization options.

Now most configuration files have a pre-defined entry that will automatically be included in the Edit configs tool should they exist. Customer configuration files can be added by creating an entry manually.

To simplify the use of the Edit config tool, configuration files are grouped under various headings. Groups and headings can be customized.

The NetYCE system setup scripts that configure the networking and server roles have been reworked to further support CentOS/RHEL 7.x. The main enhancement is in the support of IPv6. All NetYCE communication channels now support IPv4/IPv6 dual-stack connections which can be setup using the newer version of net_setup.pl and yce_setup.pl.

To allow dynamic IP-addresses (DHCP, autoconf) the new yce_netmon daemon process will be used to transparently reconfigure the NetYCE server when an IP-address changes.

Although the net_setup / yce_setup scripts can be used on CentOS/RHEL versions 6.x and 7.x, the IPv6 support is restricted to version 7.x.

To replace a customer-special tool for Client mergers, a new general purpose tool has been created to allow the migration and merger of Sites (locations). The new tool will allow the user to first create a 'Site migration' entry that defines to which Client the site can be moved (migrated) to, or to which Client and Site the devices can be merged into.

After the creating the definition of the planned migration or merger, the user can move all or selected devices to their new location. Various options to migrate any IP-plan based supernets are handled by the tool.

This function does not apply to CMDB nodes. Their Client and Site assignments do not depend on interdependent modelled objects and can be modified directly in the CMDB form.

The popup forms to launch Service-types to 'Add node' and service 'Tasks' have been replaced with new forms offering the same functions. This was done to conform to the look and feel of the other forms in the NetYCE GUI.

To be more consistent in the button labels, the 'add node' is now named 'New' and is available under the main build 'Nodes' grid as well as the 'Services' grids. The service 'Task' button is still part of the 'Edit Service' form.

Gradually NetYCE development has been reworking the Web-based GUI to use more industry-standard frameworks to replace the original in-house developed framework. With the last form now redeveloped, the initial loading of the NetYCE menus by the browser has become much more efficient.

As a consequence, the menu is now loaded after the login resulting in a cleaner login page.

The scrollable table grids that allow pagination have been changed slightly. These grids are used in several forms like the 'Logs' and 'CMDB' forms. Where previously the number of visible lines were variant but always showed 50 entries per page, the updated version shows a constant 20 lines using a default paging of 20.

Several issues have been addressed within Compliance.

• Efficiency improvements on (very) large configurations like F5. With 400,000 or more lines per configuration, efficiency optimizations in parsing multiple rules and conditions proved very worthwhile.
• F5 BigIP configuration blocks parsing when {..} on same line
• Compliance rule matching pattern fix when anchoring at start or end of a line
• The NetYCE process monitoring caused CPU intensive compliance tasks (like the large F5 configurations) to be treated as 'runaway' processes upon which they were aborted. The CPU monitoring of Compliance processes have been adjusted to be very forgiving.
• Not all nodes being included within a Compliance run.
• Importing compliance policies from HPNA required a fix for command rule conditions.
• NetYCE 'command jobs' were not consistently triggering a compliance check.
• Customized syslog events definitions to signal config changes were overwritten when updating NetYCE version.
• Compliance reporting model is in the process of being reworked to add rule-based reports using customer defined report-templates. The updated data model is now in place, the front-end will follow shortly.

The F5 BigIP vendor module has been cleared of several minor problems that could prevent NCCM configuration backups and Compliance checks.