This pre-releases the TMF641 API version2 that supports multiple ServiceItems in one ServiceOrder. The implementation of the new ServiceOrder required a different set of NMS tables to support the per-ServiceItem states and their effect on the ServiceOrder state.

Version 2 is superseding version 1 but is not replacing it. Both will be available side by side for some time before it is obsoleted. Note that no history is carried over from version 1 to version 2.

A new Operating System file repository was added to NetYCE to manage the numerous image files of the different vendors and hardware-models of your networking devices.

The repository consists of two parts. First of all the disk-space where the files are stored and monitored is part of the file-transfer directory tree of the application which allows all your devices access using all common protocols (scp, sftp, ftp, tftp). This disk space can be shared using Network File System (NFS) among all NetYCE servers or any Unix based server to act as a distributed disk-share without duplication of files. Active monitoring of all file activity (adding, updating, moving, deleting) will automatically adjust the OS repository to reflect these changes.

Secondly, the user front-end form, which can be found under 'Operate - OS repository', allows the user to organize the image files into file-sets associated with a Vendor and a Device type. Each file-set created is intended to assist the user in finding or selecting the image files needed to a specific device-type and OS version or feature set. As image files can be used for many device-types, the repository keeps track of shared usage and status.

Finally, a couple of Scenario commands were added to locate image files in the repository for use in OS upgrade scenarios. These commands will also allow access to the meta-data of each file-set to simplify copy and activation actions.

We added support for the variables <current_template> and <current_vendor> that will have the active template name during its generation. This allows for marking the start and end of each template and can be used in conditionals.

However, a few shortcomings with this approach were observed: first, all templates will need modification - an unpleasant task. Second, when a sub-template is done, config generation returns to its parent to process the remaining lines of that template. It is often hard to locate which template that was, especially when a deeper template tree was used.

To resolve these issues, an automatic 'current template' marker option has been added that use these new variables. It will insert comment lines in the generated output at the template 'start', template 'done' and template 'resume' places.

This feature is controlled by the “Template_markers” Tweak: When its Num_value equals 1 - print 'start' template info; when 2 - also include 'done'; when 3 - also include 'resume' comments. The default is to include none (0).

When the templates are used hierarchical, the message text indentation follows the levels.

The new Re-schedule job option is available from the 'Job logs' pop-up window. It is accessed from the Job-logs and the Scheduled-jobs forms.

In order to re-schedule a job the job 'scenario' and 'command' files must still be present on the server. By default this period is 30 days and can be modified using the “Age_result_files” tweak.

Another requirement is that the job must have been executed, or at least be running.

If these conditions are not met, the Re-schedule button will not be available.

The implementation allows for EDITING the job “command” and “scenario” sections before re-scheduling which will also allow for all the usual options. It is available for both the command-job and the basic-command-job.

Customers can now format a legal or other customized message on at the login page. To configure, access the 'Settings' page of the 'Admin - Setup' menu and select the 'Tweaks' category. Find the variable 'Login_legal_message' in the list. Set the num value of this tweak to 1 to display the message in the description field. The message can be formatted using html tags and is displayed centered below the login box.

As per RFC-952 the hostname restrictions have been relaxed to allow leading numbers too. Hostnames were previously enforced to start with a letter, rejecting leading numbers and other characters.

The updated validation still rejects hostnames with leading dashes (-) or with dots (.) in them.

Retrieving a backup of a device configuration uses one of four file-transfer protocols, depending on the device capabilities and preference. Due to a wide variety of dependencies like firewalls, management vrf, permissions, dialogs and more, these transfers may take some doing before it works reliably.

To circumvent these issues, all our Vendor modules will now fall back to CLI configuration 'screen-scraping' should the file transfer fail. The device configuration will be read from the device by listing it on the display. Although not the most efficient method, but it will allow for the collection of backup configurations and validation of compliance rules.

Additional Syslog patterns have been added to the NCCM configuration file. These patterns are vendor specific and are used to detect a configuration change. The system will then setup a session to the device to retrieve the latest configuration and store it in the NCCM. A subsequent compliance check is also automatic.

When reviewing the configurations in the NCCM tool 'Backup - Configuration' the configuration differences (or fill config) are displayed using censoring where passwords are hidden from view. Only higher level users are allowed to view the configuration uncensored.

On request of customers we lowered the required permission level to 'operator' to view uncensored configurations. We also changed the default to uncensored if the user permissions allow.

It turns out that rules (either include or exclude) on SiteCode work for some Node-groups, but no all.

Node-groups on the 'yce' scope work, those on 'all' or 'cmdb' do not.

There are different sql's and mappings for each of these scopes to match YCE and CMDB node attributes. One sql typo error was found for the YCE nodes in the 'all' scope and one mapping typo error in the CMDB nodes.

The fix is available in version 8.0.0 as of build 20211230

On occasion, some obsoleted nodes could still be listed in the NCCM for configuration retrieval. We fixed the situations where this could occur.

We fixed the Vendor_type filter in the NCCM polling status grid

Jobs that are submitted using a scenario that contained parsing errors resulted in an aborted job as expected, but without any indication of the problem in the job logs.

This issue has been corrected. Now the job logs will show the parsed scenario including line numbers and an error message indicating the failing line.

Dismissed system alerts no longer re-appear spontaneously

Command parsing header recognition improved

Some users failed to properly setup the NetYCE downloadable trial VM. Analysis showed that a specific sequence of actions and prompt answers resulted in a system that would not allow users to login due to a non-operational (morbo) backend.

Although the issue could be corrected by following the prompts more carefully, we implemented precautions against the this and similar setup situations.