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 on Windows Virtual Desktop (WVD) / 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, although it applies to the traffic of all types of devices. When a device 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 device 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 (WVD, 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. Installation on a web proxy is therefore not recommended.

Bot (Scanner, Stress test)

Not supported, since just one server may behave as thousands of end-user devices. Do not install the Collector on servers of the bot class.

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 (WVD / Citrix / RDS) servers.

Log in to the CLI of the Engine.
Open the configuration file for editing: sudo vi /var/nexthink/engine/01/etc/nxengine.xml
Write the following settings in the corresponding 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.
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:

CODE

<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 (WVD / Citrix / RDS) servers

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

Whenever possible, assign the WVD / 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:

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

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

Act support

Because server can host multiple sessions simultaneously (that is, there can be more than one current interactive user), remote actions are executed on servers only when they are run as local system .

Engage support

Engage is supported on WVD / Citrix / RDS servers when a full desktop session is streamed (app streaming does not support Engage) and .NET framework 3.5 or later is installed on the streamed desktop.

To enable Engage for servers, remember to set the option Enable for all devices when installing the Collector, as the default option Enable except on servers explicitly disables the delivery of campaigns to servers.

Compatibility of Collector with Receive Segment Coalescing (RSC)

The Collector version 6.30.2.4 or higher is compatible with Receive Segment Coalescing, a technology present in Windows Server 2012 and later that improves the reception of network traffic by offloading network processing from the CPU to the network interface. Windows desktop operating systems also support RSC since Windows 8, but the use of RSC is usually limited to Windows servers with high input traffic.

The driver of a network interface that is compatible with RSC can coalesce multiple TCP segments received and present them as a single larger segment to the networking layer of the operating system.

RELATED TASKS

RELATED REFERENCES