Local and shared content
Starting from Nexthink V6.17, almost every item that a user creates in the Finder is centralized, meaning that the item is added to a content manager that resides in the same Appliance as the Portal. In its turn, the content manager synchronizes all connected Engines to hold a copy of every added item. The result is that all Engines share the same user-created content, offering a unified experience to Finder users.
There are a few exceptions and special cases that we detail below.
The following table classifies items according to their level of sharing:
Local to Engine
Local to Finder
Even if most of the content is replicated in all Engines, some types of replicated items belong exclusively to the user that created them. Thus, when connecting to an Engine with the Finder, only the owner of that content is able to see it. Investigations, one-clicks and the alerts in the My alerts section fall into this category of items.
Many of the items that are replicated by the content manager are shared by all users. However, these items are usually associated to a configuration option in the profile of the user, so that only the users with the corresponding option ticked are able to manipulate their content. For instance, although all users can see the visible scores of an object, only those whose profile allows system configuration can manage the scores. For a list of all the profile options, see how to define user profiles.
Services, for instance, are also visible to all users, although only those with the specific permission in their profile can modify the definition of a service. Similarly, while categories and keywords can be managed by users with the right permission only, their effect on objects (that is, the tags) are visible to everyone. Other types of items such as metrics, campaigns and remote actions are removed from the left-hand panel of the Finder as well when users do not have the permission to modify them.
Content local to the Engine
Although tags do not really qualify as user-created content, they deserve to be mentioned in this section about locality, as tags are the only items which are local to the Engine and that users can modify.
Tags are neither centralized nor shareable. A tag is the result of applying a keyword of a category to an object either manually, automatically, or with the help of text files. Objects (devices, destinations, etc) live in the database of each Engine; therefore, objects are local to an Engine, and so are the tags applied to an object. The locality of tags has some important implications that we explain with the following example.
Suppose that you have a setup with two Engines and one Portal, and in both Engines there is a destination with the same IP address. In fact, even if it is logically the same destination, there are two destination objects: one per Engine. If you create a category and a keyword to automatically tag the destinations with that IP address as, for instance, a Mail server, both Engines will tag the destination identically, though separately. Indeed, categories and keywords are centralized, so the auto-tagging condition on the IP address applies to all Engines.
Now let us imagine that you connect to one of the Engines and that you manually tag the mentioned destination as a Proxy server, overriding the auto-tagging rule. Now you find that the same destination is tagged as Mail server in one Engine and as Proxy server in the other, which is probably not what you want. Therefore, be careful when you apply tags manually (or with text files) to objects, because tags are not shared among Engines. To modify tags, a user must have a profile that allows editing of applications and object tags.
Content local to the Finder
A few types of items are stored in the computer that runs the Finder. These items are not implicitly shared with any other copy of the Finder or with any other Nexthink component:
Store information on how to connect to the Portal (user name, authentication method, etc.).
Launch external operations based on the data displayed in the Finder. Custom actions can be exported and imported into another Finder (see below).
The case of alerts
When a user creates an investigation-based alert with the Finder, the alert is stored in the centralized content manager and replicated in all Engines, but it is enabled only in the Engine to which the Finder is connected. All other Engines will remain with the alert disabled until it is explicitly enabled. This mechanism prevents a user from exceeding the limit of enabled alerts in other Engines different from the Engine to which the Finder is connected.
Exporting and importing content
Even if most of the content created by users with the Finder is centralized, you can still share it manually by exporting items to the clipboard or to a file and, optionally, create a content pack. Because content is shared by all Engines connected to a Portal, exporting content is specially useful in multi-environment setups with more than one Portal. For instance, it is custom to create content in a pre-production environment and then export it to a production environment only once every item has been thoroughly tested.
Manually export and import your investigations, one-clicks, alerts, categories, metrics, scores, remote actions, and services from the Finder.
Although local to the Finder, custom actions are also exportable. Share your custom actions with other copies of the Finder by exporting them to XML files:
Click the sprocket icon in the top right part of the Finder window.
Select Custom actions... to display the list of available custom actions.
Select one or more entries in the list by clicking on them. Use Ctrl+click to select more than one entry, Shift+click to select a group of consecutive entries, or Ctrl+A to select them all.
Right-click your selection and choose Export... from the menu.
Type in a name for the XML file.
To import custom actions into a Finder, click the Import... button at the bottom of the list of custom actions and select the file to import. If an imported custom action exists already in the list, it is duplicated.
Centralizing content via roles
Administrators can assign owned content such as investigations, one-click investigations, investigation-based alerts, and remote actions to other users by making them role-based. Once linked to a role, an item is seen by all the users playing that role and not just by the user that created the item. To add investigations, one-clicks, or alerts to a role, administrators typically use the manual method of exporting items to the clipboard.