Server support (classic)


Although Nexthink is a solution designed for monitoring employee devices, you can apply the same monitoring techniques to servers to some extent. It is possible to install Collector on Windows Virtual Desktop (WVD) / Citrix / RDS servers, where each server is roughly equivalent to having a group of end-user devices. Nexthink also supports the installation of Collector on other types of Windows servers. Therefore, a new type of device is available in Nexthink, server.

Collector reports the same analytics from a server as from the device of an employee, except for some security-related information. The technology that Collector uses to retrieve security information is not available on server-type operating systems, so data in the following areas is missing:

  • Antivirus

  • Antispyware

  • Firewall

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

Traffic reduction

The typically higher network activity of servers with respect to employee devices often generates a lot of connections and events that might saturate Engine. Engine has 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, 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, Engine aggregates the connections as one connection where the value of the domain is multiple.

When this occurs, individual information about the connections is lost, but the system keeps the amount of traffic information stored in Engine to a reasonable level. Otherwise, the explosion of connections could drastically reduce the history available in Engine. Even with the traffic reduction policy in place, you should expect a slight reduction in the available history in Engine if you install 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 Engine at the expense of losing the individual information of more connections.

Taxonomy of servers

The following is a classification of servers according to their function. Depending on the function of the server, you should be aware of the chances that 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 employee devices. Do not install Collector on servers of the bot class.

Instance configuration

Contact Nexthink Support to enable a traffic reduction policy for your instance. Depending on the types of servers that you have, our engineers adjust the settings as 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 employee devices they serve.

Only non-client servers

  • Destination reduction policy: aggressive

  • Compute service on servers: false

If possible, assign non-client servers to an Engine instance separated from those used by employee devices.

Mixed setup

  • Destination reduction policy: aggressive

  • Compute service on servers: true

If you are using Fidner (classic), in the case of a mixed setup with client-like and non-client servers, you might want to compute a service for client-like servers and actual clients (employee devices) only.

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

  1. Create a category called, for example, Compute services.

  2. Add two keywords to the categories without auto-tagging rules: yes and no.

  3. Manually tag all your employee 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:

Whenever possible, assign WVD / Citrix / RDS servers to the same Engine instances of the employee devices that they serve and group non-client servers in separate ones.

Remote action support

Because a server can host multiple sessions simultaneously, meaning that there can be more than one current interactive user, the system executes remote actions on servers only when you run them as local system.

Campaigns support

Campaigns are 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 campaigns on servers, remember to set the option Enable for all devices when installing Collector. The default option Enable except on servers explicitly disables the delivery of campaigns to servers.

Compatibility of Collector with Receive Segment Coalescing (RSC)

Collector versions or higher are 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 from 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.

Last updated