The 'Search' function of the Main Build form (located below the Client grid) has been reworked for greater ease-of-use. Wildcard support ('*' and '?) has been extended and is used more explicit.

The search results will now include devices from the CMDB.

The main Nodes grid will now include CMDB-nodes that are not present as YCE-nodes (modeled nodes). Any CMDB node assigned to an existing Client or Site will be listed. For now the CMDB nodes are listed using the Node-class 'CMDB'.

When importing policies from HP Network Automation (HPNA) the vendor families HP uses must be mapped against the NetYCE vendor-types. An updated mechanism now allows for more precise mappings and assignments to multiple vendor-types. Where required the mapping can be customized.

The field 'Device_status' has been added to the CMDB nodes. This field is equivalent to the YCE nodes Device-status and accepts the same list of values.

Not all NetYCE supported vendors have build-in support for configuration parsing. When attempting to perform such parsing in job scenarios or compliancy policies, the results would be blank or a failure. No messages to inform the user of the lacking support were included though. This has been corrected.

The configuration parsing support for a NetYCE vendor-module refers to the automatic detection of the configuration blocks within a full configuration. It allows to detect the start and end of code blocks for interfaces and vlans and such which can then be parsed. Additionally, the configuration will also expand any ranges for vlans or interfaces to create 'implicit' code blocks.

An overview of the capabilities for all NetYCE vendor-modules is given in the Supported devices article.

Note that Compliancy policies als have support for user-defined start and end lines to identify a code block. When using this option these, any build-in code block detection is ignored and is available for all vendors.

Support for 25-Gigabit ehernet ports has been added to the vendors modules 'HP_c7', Cisco_Nexus', 'Cisco_XE' and 'Huawei_CE'.

Compliance uses the configurations retrieved by the backup process of NCCM. The stored configurations are automatically censored to protect sensitive information like passwords.

Complicance conditions that would test on cencored information would fail because the sensitive information was replaced by censored. To permit these compliance conditions the configurations retrieved from the NCCM will not be censored by default.

For customers that desire strict censoring the NCCM Tweak 'Cmpl_censor_config' can be set.

A new vendor module has been added. The CNE line of Corvil products is now supported by the “Corvil_CNE” module.

The form “Hardware models” of the 'Design“ menu has been renewed to align it with the design and implementation of the other forms.

No functional changes were made that a user should be aware off. However, the backend was modified to use different tables. In case custom relations or reports ware created using the 'Model' table, please change these references to 'Hardware_model'.

Altough Aruba is part of HP, we determined there were several distinct product families within Aruba that could not be properly supported using a single vendor module. Aruba should be a vendor within its own rights supporting its product families.

The Aruba family currently supported is known as 'Mobility Controller' and consequently the vendor module 'HP_Aruba' was renamed to 'Aruba_MC'. When installing the update, all references to Aruba will automatically be modified to reference the new name.

And, by means of a workaround, configuration file transfers are now also supported using the “scp” protocol.

The eVPN form is not available without the required package license.

The “eVPN” form of the 'Build” menu is reworked to conform to the look and feel of the other forms in the NetYCE GUI. Its operation is generally unchanged. The form now also allows for the addition and deletion of eVPN connection records.

The permissions per role and per field can be modified to suit customer needs. Please request NetYCE support to assist in modifying the Ayth_permissions table for this.

The form “OS-images” of the 'Build“ menu has been renewed to conform to the look and feel of the other forms in the NetYCE GUI. Its operation is generally unchanged.

NetYCE configuration files can be edited using the “System - System - Edit configs” tool. This tool allows to make changes to a configuration file and update any changes to other NetYCE servers if applicable.

As this tool itself is configured using a configuration file, customer specific configuration files can be integrated on demand. With this release two newly introduced configuration files are added to this list.

These are the “YCE System events” confuration file that defines the System event signalling targets and options and the “YCE Compliance signals” to defines the Compliance signalling targets and options.

The relation 'Domain' that is part of the standard distribution has been updated to properly include the IPv6variable values. Since the IPv6 addresses are stored in a binary format they require conversion into string for use in relations. This conversion has now been added to this relation.

Compliancy verification relies on a recent configuration backup. When such a configuration is missing, the configuration is retrieved using the NCCM poller before policies can be executed. However, should retrieving the configuration fail for any reason, the policy is not aborted but will continue to execute any command rules that may apply. And, due to the failing configuration, the node will again be included in the next polling cycle to retry the configuration backup. As a result, the node is continuously polled for its configuration including the command rules.

When correcting this behaviour two additional issues were identified and corrected. First that Compliancy initiated configuration polls did not use or modify the NCCM retry counter (never giving up) and secondly that the command rules did not use the existing ssh/telnet connection to the node but had to re-login for each command. These shortcomings were resolved.

An additional error message form HP C7 devices while transferring (configuration) files was added to the vendor module to popperly handle this situation.

Usability and stability fixes have been incorporated in the Compliancy operation. Some timeout issues were addressed as well as the popper re-use of device connections to fetch command responses along with the configuration. Also the HPNA policies importer was improved to match device families to NetYCE vendor modules.

Several fixes were applied to the F5 BigIP vendor module:

When the F5 file transfer using ftp, scp or sftp would fail for some reason, no error message was given. This is now corrected. Additional error failure situations are now included.

The configuration file created for backup (NCCM) purposes will now be removed afterwards to conserve disk space.

Parsing the F5 BigIP configuration for compliance could fail due to the inclusion of comment strings at unexpected places. The parsing syntax has been modified to allow these comments. It should be noted that these comment strings (starting after a '#') are considered part of the configuration and should be incorporated in the complicance conditions.

The set of policies governing the conditions under which Infoblox Aliases (for Host-records) or CNAME-records could be created and cleared were so strict that attempting to do so using the scenario functions dns_set_alias and dns_clear_alias would always fail.

These scenario functions were reworked to allow proper functioning. Please see the Scenario commands - dns_add_alias article to learn about the modified options these functions use.