Server support

Contents

Server support

Overview

Although Nexthink is a solution designed for monitoring the devices of the end-users, the same monitoring techniques may be applied to servers to some extent. In Nexthink V5, it is possible to install the Collector in Citrix / RDS servers, where each server is roughly equivalent to having a group of end-user devices. Starting from V6, Nexthink also supports the installation of the Collector in other types of Windows servers (note that V5.3 offers server support for specific Windows Server versions as well). Therefore, a new type of device is available in Nexthink: the server.

The Collector reports basically the same analytics from a server as from the device of an end-user, except for some security-related information. Indeed, the technology used by the Collector to retrieve security information is not available on servers, so data on the following areas is missing:

  • Antivirus
  • Antispyware
  • Firewall

Also keep in mind that, as for normal devices, the Collector does not report incoming connections for servers. Only outgoing connections are recorded.

Sizing your installation

Servers usually generate much more activity than end-user devices. As a rule of thumb for sizing your installation, consider that a server is equivalent to 20 end-user devices. Calculate the number of Engines that you need according to the following formula, where S is the number of servers and D is the number of end-user devices in your setup:

  • Number of Engines = (20 * S + D) / 6000

The hardware requirements for the Engines apply.

Traffic reduction

The typically higher network activity of servers with respect to end-user devices often generates lots of connections and events that might saturate the Engine. Therefore, the Engine has set in place a strategy to reduce the traffic of servers. When a server connects to too many destinations or opens too many ports in a burst, the Engine can automatically decide to aggregate these connections into a single connection, setting its port or its destination value to multiple. In the case of a server launching a burst of web connections to many domains, the Engine aggregates the connections as one connection where the value of the domain is multiple.

In this manner, individual information about the connections is lost, but the amount of traffic information stored in the Engine is kept to a reasonable level. Otherwise, the explosion of connections could drastically reduce the history available in the Engine. Even with the traffic reduction policy in place, you should expect a slight reduction on the history available in the Engine if you install the Collector on servers.

The strategy for reducing traffic is configurable (see below). Choose between normal and aggressive, depending on whether you prefer to aggregate connections gently or almost right away. An aggressive policy lets you keep a longer history in the Engine at the expense of losing the individual information of more connections.

Taxonomy of servers

Find below a classification of servers according to their function. Depending on the function of the server, you should be aware of the chances that the Engine reduces server traffic.

Client-like (Citrix, RDS)
Supported from V5. Traffic reduction rare.
Application (Mail, SQL Database)
Traffic reduction depending on load.
Agent manager (SCCM)
Traffic reduction probable.
UDP server (DNS)
Traffic reduction certain.
Proxy (Web proxy)
Expect to have web traffic reduction and bigger Collector usage of your network.
Bot (Scanner, Stress test)
Not supported, since just one server may behave as thousands of end-user devices.

Engine configuration

Set the traffic reduction policy by editing the configuration file of the Engine. In addition, configure whether you want the outgoing traffic of servers to be used in the computation of services. Usually, this only makes sense for client-like (Citrix / RDS) servers.

  1. Log in to the CLI of the Engine.
  2. Open the configuration file for editing:
    sudo vi /var/nexthink/engine/01/etc/nxengine.xml
  3. Write the following settings in the correspoding section of the configuration file:
    • In the aggregation section, set destination_reduction_policy to normal or aggressive.
    • In the service section, set compute_service_on_server to true or false.
  4. Save your changes and exit:
    :wq

Alternatively, use the nxinfo command to change the configuration settings of the Engine. For instance, to set the destination reduction policy to normal and turn on the computation of services on servers, type in:

  • sudo nxinfo config -s aggregation.destination_reduction_policy=normal
  • sudo nxinfo config -s service.compute_service_on_server=true

After modifying the settings, find the following lines with the provided values in the configuration file:

<aggregation>
  <destination_reduction_policy>normal<destination_reduction_policy>
</aggregation>
<service>
  <compute_service_on_server>true<compute_service_on_server>
</service>


Depending on the types of servers that you have, use the settings described below.

Only client-like (Citrix / RDS) servers

  • Destination reduction policy: normal.
  • Compute service on servers: true.

Whenever possible, assign the Citrix / RDS servers to the same Engines of the end-user devices that they serve.

Only non-client servers

  • Destination reduction policy: aggressive.
  • Compute service on servers: false.

If possible, assign non-client servers to an Engine separate from those used by end-user devices.

Mixed setup

  • Destination reduction policy: aggressive.
  • Compute service on servers: true.

In the case of a mixed setup with both client-like and non-client servers, you may want to compute a service for client-like servers and actual clients (end-user devices) only.

To compute services selectively, manually tag those devices that you want to include in the computation and set a condition on the services for taking into account only those tagged devices. For instance:

  1. Create a category called, for example, Compute services.
  2. Add two keywords to the categores without auto-tagging rules: yes and no.
  3. Manually tag all your end-user devices and client-like servers with the keyword yes and the non-client servers with the keyword no.
  4. Add a condition on devices in the definition of each service to include in the service only those devices tagged with the yes keyword:

ComputeServices.png


Whenever possible, assign Citrix / RDS servers to the same Engines of the end-user devices that they serve and group nonclient servers in separate Engines.