Content centralization when updating the Appliance
Overview
When updating the Appliance to V6.17 or later from a previous version of Nexthink, a set of elements that were previously local to each Engine become centralized:
Investigations
One-click investigations
Investigation-based alerts
My alerts
Global alerts
The centralization of content offers users a unified experience with the Finder across all Engines. Users find their own set of investigations and alerts no matter the Engine to which they connect from the Finder, without having to manually replicate their content on every Engine. Therefore, centralization specially benefits Finder users that work in a multi-Engine setup. For Finder users that work in a single-Engine setup, the user experience remains the same after centralization.
The centralization process
Centralization takes place automatically during the upgrade of the Appliance to V6.17 or later. As usual, the Appliance that runs the Portal gets upgraded first. Subsequently, each Engine gets upgraded. As soon as an Engine restarts, it tries to reconnect to the Portal. When an upgraded Engine re-establishes connection with the Portal, the Portal retrieves the content to be centralized from the Engine. As other Engines connect in turn, their content is added to the Portal. For its part, the Portal sends a replica of the centralized content to all the already connected Engines. In case of the presence of duplicated or similar content in more than one Engine before centralization, the Portal adopts different merge strategies that are discussed below.
At the end of the process, all Engines are synchronized with respect to user-defined content. The same user sees therefore the same content regardless of the Engine to which the Finder is connected. However, different users may see different content. Only the owner (the creator) of an investigation, a one-click, or a user-specific alert is able to see it and manage it from the Finder.
Centralization runs to completion in around one minute for large multi-Engine setups. Measurements in test environments indicate a duration of the centralization process of approximately 15 seconds for a setup with 20 Engines, 100 users and 2 000 items to centralize. Note however that this duration highly depends in the quantity of total content to centralize and, specially, in the quality of the connection between Portal and Engines. If for any reason an Engine is disconnected from the Portal, its content will not be centralized until it is connected back again.
Merge strategies
Some of the content to be centralized may reside in more than one Engine because a user recreated or copied it to several Engines. Besides, part of the copied items may have been modified in a few Engines. For instance, the definition of an investigation in one Engine may be different from the definition of a similar investigation with the same name in another Engine, because the time frame, conditions, or display fields were changed.
Thus, centralization classifies similar items according to three criteria:
The folder path where the items are located in the Finder.
The name given to the items.
The definition of the items.
Based on the previous criteria, centralization considers three cases for merging repeated or similar content:
Real duplicates
Items that are located in the same folder, share the same name, and have the same definition.
False duplicates
Items that are located in the same folder, share the same name, but have a different definition.
Rest of items
Items that do not fall into any of the two previous categories.
Let us illustrate how the different centralization strategies work with an example that covers the three cases. Although the example features the tree of investigations of a user in two different Engines, the principles described equally apply to trees of one-clicks and alerts and to setups with more than two Engines.
Real duplicates
Real duplicates are merged into a single item during centralization. Here, Investigation 2 is found in Folder A in the tree of investigations of both Engine 1 and Engine 2, and we assume that the investigation holds the same definition in both Engines.
False duplicates
False duplicates are detected during centralization and copied into a separate subfolder. In the example, we find Investigation 1 in Folder A of the tree of investigations in both Engine 1 and Engine 2, but the definition of this investigation is different on each Engine. From the screen capture of the example itself, we can deduce that Investigation 1 on Engine 1 is different from Investigation 1 on Engine 2 because of their associated icon: while the former is an investigation on devices, the latter is an investigation on users. They just happen to be located in the same folder and have the same name.
Assuming that the content of Engine 1 was centralized first, Investigation 1 from Engine 1 is placed directly into Folder A of the merged investigation tree. On the other hand, because of the path and name collision, Investigation 1 from Engine 2 is copied to a subfolder Engine 2 within Folder A, as depicted in the figure.
Rest of items
Items that do not collide in name and folder path simultaneously are just copied with their own name to the same location in the merged investigation tree as they had in their original Engine before centralization.
Status of alerts
Because centralization gathers alerts from all connected Engines, each Engine ends up with the same or more investigation-based alerts than it had before upgrading. To avoid exceeding the limit of enabled alerts per Engine during upgrade, alerts stay enabled only on the Engines where they were originally enabled. That is, the definition of alerts are replicated on all Engines, but not their status. Thus, alerts that appear on an Engine as a result of the centralization process are disabled by default. This is valid both for global alerts and for user-specific alerts (those in the section My alerts of each user). Similarly, newly created alerts are only enabled on the Engines in which they are created.
To enable a replicated alert on a particular Engine:
Log in to the Finder.
Connect to the specific Engine on logon.
Go to the Settings section on the left-hand side accordion of the main window.
Choose the type of alerts to see from the drop-down list:
Select Global alerts to see the alerts that are global to all users (only users with the right permissions can manage global alerts).
Select My alerts to see the alerts that are specific to your user account.
Right-click the name of the alert and select Enable on current Engine.
Remember that enabling an alert will fail if the limit of enabled alerts has been reached on that Engine.
Monitoring the centralization process
Following the centralization from the Portal
To follow the centralization process from the Portal:
Log in to the Portal as a central administrator.
Click the ADMINISTRATION drop-down menu at the top of the window.
Select the Engines dashboard.
Look at the status line at the bottom of the table with the list of connected Engines.
The status line holds a list of the Engines for which centralization is still pending:
Troubleshooting centralization
If the centralization process is unable to complete in an Engine, the Portal displays the following message in the status line:
Content centralization failed for the following N Engine(s):
To retry the centralization process on an Engine where it failed:
Log in to the Portal as a central administrator.
Click the ADMINISTRATION drop-down menu at the top of the window.
Select the Engines dashboard.
Click the chain icon to disconnect the failed Engine from the Portal.
Wait until the connection status light turns red.
Click again the chain icon to connect back the Engine to the Portal.
Wait for the Portal to attempt the centralization again.
If the problem persists, please contact Nexthink Support.
Logging in to the Finder during upgrade
As explained above, centralization is a fast process. However, in the unlikely event that a user tries to log in to the Finder while the centralization procedure is going on, the Finder displays the following message to ask the user to log in later:
RELATED TASKS
Last updated
