Preparation for deployment

This section describes steps you must take before deploying Kaspersky Security Center.

Planning Kaspersky Security Center deployment

This section provides information about the most convenient options for deployment of Kaspersky Security Center components on an organization's network, depending on the following criteria:

• Total number of devices
• Units (local offices, branches) that are detached organizationally or geographically
• Separate networks connected by narrow channels
• Need for internet access to the Administration Server

Typical schemes of protection system deployment

This section describes the standard deployment schemes of a protection system in an enterprise network using Kaspersky Security Center.

The system must be protected against any type of unauthorized access. We recommend that you install all available security updates for your operating system before installing the application on your device and physically protect Administration Server(s) and distribution point(s).

You can use Kaspersky Security Center to deploy a protection system on a corporate network by means of the following deployment schemes:

• Deploying a protection system through Kaspersky Security Center, in one of the following ways:
  • Through Administration Console
  • Through Kaspersky Security Center Web Console

  Kaspersky applications are automatically installed on client devices, which in turn are automatically connected to the Administration Server by using Kaspersky Security Center.

  The basic deployment scheme is protection system deployment through Administration Console. Using Kaspersky Security Center Web Console allows you to launch installation of Kaspersky applications from a browser.

• Deploying a protection system manually using stand-alone installation packages generated by Kaspersky Security Center.

  Installation of Kaspersky applications on client devices and the administrator's workstation is performed manually; the settings for connecting client devices to the Administration Server are specified when Network Agent is installed.

  This deployment method is recommended in cases when remote installation is not possible.

Kaspersky Security Center also allows you to deploy your protection system using Microsoft Active Directory group policies.

About planning Kaspersky Security Center deployment in an organization's network

One Administration Server can support a maximum of 100,000 devices. If the total number of devices on an organization's network exceeds 100,000, multiple Administration Servers must be deployed on that network and combined into a hierarchy for convenient centralized management.

If an organization includes large-scale remote local offices (branches) with their own administrators, it is useful to deploy Administration Servers in those offices. Otherwise, those offices must be viewed as detached networks connected by low-throughput channels; see section "Standard configuration: A few large-scale offices run by their own administrators".

When detached networks connected with narrow channels are used, traffic can be saved by assigning one or several Network Agents to act as distribution points (see table for calculation of the number of distribution points). In this case, all devices on a detached network retrieve updates from such local update centers. Actual distribution points can download updates both from the Administration Server (default scenario), and from Kaspersky servers on the internet (see section "Standard configuration: Multiple small remote offices").

Section "Standard configurations of Kaspersky Security Center" provides detailed descriptions of the standard configurations of Kaspersky Security Center. When planning the deployment, choose the most suitable standard configuration, depending on the organization's structure.

At the stage of deployment planning, the assignment of the special certificate X.509 to the Administration Server must be considered. Assignment of the X.509 certificate to the Administration Server may be useful in the following cases (partial list):

• Inspecting secure socket layer (SSL) traffic by means of an SSL termination proxy or for using a reverse proxy
• Integration with the public keys infrastructure (PKI) of an organization
• Specifying required values in certificate fields
• Providing the required encryption strength of a certificate

Selecting a structure for protection of an enterprise

Selection of a structure for protection of an organization is defined by the following factors:

• Organization's network topology.
• Organizational structure.
• Number of employees in charge of the network protection, and allocation of their responsibilities.
• Hardware resources that can be allocated to protection management components.
• Throughput of communication channels that can be allocated to maintenance of protection components on the organizational network.
• Time limits for execution of critical administrative operations on the organization's network. Critical administrative operations include, for example, the distribution of anti-virus databases and modification of policies for client devices.

When you select a protection structure, it is recommended first to estimate the available network and hardware resources that can be used for the operation of a centralized protection system.

To analyze the network and hardware infrastructure, it is recommended that you follow the process below:

1. Define the following settings of the network on which the protection will be deployed:
   • Number of network segments.
   • Speed of communication channels between individual network segments.
   • Number of managed devices in each of the network segments.
   • Throughput of each communication channel that can be allocated to maintain the operation of the protection.
2. Determine the maximum allowed time for the execution of key administrative operations for all managed devices.
3. Analyze information from steps 1 and 2, as well as data from load testing of the administration system. Based on the analysis, answer the following questions:
   • Is it possible to serve all the clients with a single Administration Server, or is a hierarchy of Administration Servers required?
   • Which hardware configuration of Administration Servers is required in order to deal with all the clients within the time limits specified in step 2?
   • Is it required to use distribution points to reduce load on communication channels?

Upon obtaining answers to the questions in step 3 above, you can compile a set of allowed structures of the organization's protection.

On the organization's network you can use one of the following standard protection structures:

• One Administration Server. All client devices are connected to a single Administration Server. Administration Server functions as distribution point.
• One Administration Server with distribution points. All client devices are connected to a single Administration Server. Some of the networked client devices function as distribution points.
• Hierarchy of Administration Servers. For each network segment, an individual Administration Server is allocated and becomes part of a general hierarchy of Administration Servers. The primary Administration Server functions as distribution point.
• Hierarchy of Administration Servers with distribution points. For each network segment, an individual Administration Server is allocated and becomes part of a general hierarchy of Administration Servers. Some of the networked client devices function as distribution points.

Standard configurations of Kaspersky Security Center

This section describes the following standard configurations used for deployment of Kaspersky Security Center components on an organization's network:

• Single office
• A few large-scale offices, which are geographically detached and run by their own administrators
• Multiple small offices, which are geographically detached

Standard configuration: Single office

One or several Administration Servers can be deployed on the organization's network. The number of Administration Servers can be selected either based on available hardware, or on the total number of managed devices.

One Administration Server can support up to 100,000 devices. You must consider the possibility of increasing the number of managed devices in the near future: it may be useful to connect a slightly smaller number of devices to a single Administration Server.

Administration Servers can be deployed either on the internal network, or in the DMZ, depending on whether internet access to the Administration Servers is required.

If multiple Servers are used, it is recommended that you combine them into a hierarchy. Using an Administration Server hierarchy allows you to avoid dubbed policies and tasks, and handle the whole set of managed devices as if they are managed by a single Administration Server (that is, search for devices, build selections of devices, and create reports).

Standard configuration: A few large-scale offices run by their own administrators

If an organization has a few large-scale, geographically separate offices, you must consider the option of deploying Administration Servers at each of the offices. One or several Administration Servers can be deployed per office, depending on the number of client devices and hardware available. In this case, each of the offices can be viewed as a "Standard configuration: Single office". For ease of administration, it is recommended to combine all of the Administration Servers into a hierarchy (possibly multi-level).

If some employees move between offices with their devices (laptops), create Network Agent connection profiles in the Network Agent policy. Network Agent connection profiles are only supported for Windows and macOS devices.

Standard configuration: Multiple small remote offices

This standard configuration provides for a headquarters office and many remote small offices that may communicate with the HQ office over the internet. Each of the remote offices may be located behind a Network Address Translation (NAT), that is, no connection can be established between two remote offices because they are isolated.

An Administration Server must be deployed at the headquarters office, and one or multiple distribution points must be assigned to all other offices. If the offices are linked through the internet, it may be useful to create a Download updates to the repositories of distribution points task for the distribution points, so that they will download updates directly from Kaspersky servers, local or network folder, not from the Administration Server.

If some devices at a remote office have no direct access to the Administration Server (for example, access to the Administration Server is provided over the internet but some devices have no internet access), distribution points must be switched into connection gateway mode. In this case, Network Agents on devices at the remote office will be connected, for further synchronization, to the Administration Server—but through the gateway, not directly.

As the Administration Server, most probably, will not be able to poll the remote office network, it may be useful to turn this function over to a distribution point.

The Administration Server will not be able to send notifications to port 15000 UDP to managed devices located behind the NAT at the remote office. To resolve this issue, you can enable the mode of continuous connection to the Administration Server in the properties of devices acting as distribution points (Do not disconnect from the Administration Server check box). This mode is available if the total number of distribution points does not exceed 300. Use push servers to make sure that there is continuous connectivity between a managed device and the Administration Server. Refer to the following topic for details: Using a distribution point as a push server.

How to select a DBMS for Administration Server

When selecting the database management system (DBMS) to be used by an Administration Server, you must take into account the number of devices covered by the Administration Server.

SQL Server Express Edition has limitations on the memory volume used, number of CPU cores used, and maximum size of the database. Therefore, you cannot use SQL Server Express Edition if your Administration Server covers more than 10,000 devices, or if Application Control is used on managed devices. If the Administration Server is used as Windows Server Update Services (WSUS) server, you cannot use SQL Server Express Edition either.

If the Administration Server covers more than 10,000 devices, we recommend that you use SQL Server versions with fewer limitations, such as: SQL Server Workgroup Edition, SQL Server Web Edition, SQL Server Standard Edition, or SQL Server Enterprise Edition.

If the Administration Server covers 50,000 devices (or less), and if Application Control is not used on managed devices, you can also use MySQL 8.0.20 and the later versions.

If the Administration Server covers 20,000 devices (or fewer) and if Application Control is not used on managed devices, you can use MariaDB Server 10.3 as the DBMS.

If the Administration Server covers 10,000 devices (or less), and if Application Control is not used on managed devices, you can also use MySQL 5.5, 5.6, or 5.7 as the DBMS.

MySQL versions 5.5.1, 5.5.2, 5.5.3, 5.5.4, and 5.5.5 are no longer supported.

If you are using SQL Server 2019 as a DBMS and you do not have cumulative patch CU12 or later, you have to perform the following after installing Kaspersky Security Center:

1. Connect to SQL Server using SQL Management Studio.
2. Run the following commands (if you chose a different name for the database, use that name instead of KAV):

   USE KAV

   GO

   ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF

   GO

3. Restart the SQL Server 2019 service.

Otherwise, using SQL Server 2019 may result in errors, such as "There is insufficient system memory in resource pool 'internal' to run this query."

Selecting a DBMS

When installing Administration Server, you can select the DBMS that Administration Server will use. When selecting the database management system (DBMS) to be used by an Administration Server, you must take into account the number of devices covered by the Administration Server.

The following table lists the valid DBMS options, as well as the restrictions on their use.

Restrictions on DBMS

If you are using SQL Server 2019 as a DBMS and you do not have cumulative patch CU12 or later, you have to perform the following after installing Kaspersky Security Center:

1. Connect to SQL Server using SQL Management Studio.
2. Run the following commands (if you chose a different name for the database, use that name instead of KAV):

   USE KAV

   GO

   ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF

   GO

3. Restart the SQL Server 2019 service.

Otherwise, using SQL Server 2019 may result in errors, such as "There is insufficient system memory in resource pool 'internal' to run this query."

Concurrent use of the SQL Server Express Edition DBMS by Administration Server and another application is strictly forbidden.

Managing mobile devices with Kaspersky Endpoint Security for Android

Mobile devices with installed Kaspersky Endpoint Security for Android (hereinafter referred to as KES devices) are managed by means of the Administration Server. Kaspersky Security Center supports the following features for managing KES devices:

• Handling mobile devices as client devices:
  • Membership in administration groups
  • Monitoring, such as viewing statuses, events, and reports
  • Modifying local settings and assigning policies for Kaspersky Endpoint Security for Android
• Sending commands in centralized mode
• Installing mobile apps packages remotely

Administration Server manages KES devices through TLS, TCP port 13292.

Providing internet access to Administration Server

The following cases require internet access to the Administration Server:

• Regular updating of Kaspersky databases, software modules, and applications
• Updating third-party software

  By default, internet connection is not required for Administration Server to install Microsoft software updates on the managed devices. For example, the managed devices can download the Microsoft software updates directly from Microsoft Update servers or from Windows Server with Microsoft Windows Server Update Services (WSUS) deployed in your organization's network. Administration Server must be connected to the internet in the following cases:

  • When you use Administration Server as WSUS server
  • To install updates of third-party software other than Microsoft software
• Fixing third-party software vulnerabilities

  Internet connection is required for Administration Server to perform the following tasks:

  • To make a list of recommended fixes for vulnerabilities in Microsoft software. The list is created and regularly updated by Kaspersky specialists.
  • To fix vulnerabilities in third-party software other than Microsoft software.
• Managing devices (laptops) of out-of-office users
• Managing devices in remote offices
• Interacting with primary or secondary Administration Servers located in remote offices
• Managing mobile devices

This section describes typical ways of providing access to the Administration Server over the internet. Each of the cases focusing on providing internet access to the Administration Server may require a dedicated certificate for the Administration Server.

Internet access: Administration Server on a local network

If the Administration Server is located on the internal network of an organization, you might want to make TCP port 13000 of the Administration Server accessible from outside by means of port forwarding. If mobile device management is required, you might want to make accessible port 13292 TCP.

Internet access: Administration Server in DMZ

If the Administration Server is located in the DMZ of the organization's network, it has no access to the organization's internal network. Therefore, the following limitations apply:

• The Administration Server cannot detect new devices.
• The Administration Server cannot perform initial deployment of Network Agent through forced installation on devices on the internal network of the organization.

This only applies to the initial installation of Network Agent. Any further upgrades of Network Agent or the security application installation can, however, be performed by the Administration Server. At the same time, the initial deployment of Network Agents can be performed by other means, for example, through group policies of Microsoft Active Directory.

• The Administration Server cannot send notifications to managed devices through port 15000 UDP, which is not critical for the Kaspersky Security Center functioning.
• The Administration Server cannot poll Active Directory. However, results of Active Directory polling are not required in most scenarios.

If the above limitations are viewed as critical, they can be removed by using distribution points located on the organization's network:

• To perform initial deployment on devices without Network Agent, you first install Network Agent on one of the devices and then assign it the distribution point status. As a result, initial installation of Network Agent on other devices will be performed by the Administration Server through this distribution point.
• To detect new devices on the internal network of the organization and poll Active Directory, you must enable the relevant device discovery methods on one of the distribution points.

To ensure a successful sending of notifications to port 15000 UDP on managed devices located on the internal network of the organization, you must cover the entire network with distribution points. In the properties of the distribution points that were assigned, select the Do not disconnect from the Administration Server check box. As a result, the Administration Server will establish a continuous connection to the distribution points while they will be able to send notifications to port 15000 UDP on devices that are on the organization's internal network (it can be an IPv4 or IPv6 network).

Internet access: Network Agent as connection gateway in DMZ

Administration Server can be located on the internal network of the organization, and in that network's DMZ there can be a device with Network Agent running as a connection gateway with reverse connectivity (Administration Server establishes a connection to Network Agent). In this case, the following conditions must be met to ensure internet access:

• Network Agent must be installed on the device that is in the DMZ. When you install Network Agent, in the Connection gateway window of the Setup Wizard, select Use Network Agent as a connection gateway in DMZ.
• The device with the installed connection gateway must be added as a distribution point. When you add the connection gateway, in the Add distribution point window, select the Select → Add connection gateway in DMZ by address option.
• To use an internet connection to connect external desktop computers to the Administration Server, the installation package for Network Agent must be corrected. In the properties of the created installation package, select the Advanced → Connect to Administration Server by using a connection gateway option, and then specify the newly created connection gateway.

For the connection gateway in the DMZ, Administration Server creates a certificate signed with the Administration Server certificate. If the administrator decides to assign a custom certificate to Administration Server, it must be done before a connection gateway is created in the DMZ.

If some employees use laptops that can connect to Administration Server either from the local network or over the internet, it may be useful to create a switching rule for Network Agent in the Network Agent's policy.

About distribution points

A device with Network Agent installed can be used as a distribution point. In this mode, Network Agent can perform the following functions:

• Distribute updates (these can be retrieved either from the Administration Server or from Kaspersky servers). In the latter case, the Download updates to the repositories of distribution points task must be created for the device that serves as the distribution point:
  • Install software (including initial deployment of Network Agents) on other devices.
  • Poll the network to detect new devices and update information about existing ones. A distribution point can apply the same device discovery methods as the Administration Server.

Deployment of distribution points on an organization's network has the following objectives:

• Reducing the load on the Administration Server.
• Optimizing traffic.
• Providing the Administration Server with access to devices in hard-to-reach spots of the organization's network. The availability of a distribution point on the network behind a NAT (in relation to the Administration Server) allows the Administration Server to perform the following actions:
  • Send notifications to devices over UDP on the IPv4 or IPv6 network
  • Poll the IPv4 or IPv6 network
  • Perform initial deployment
  • Act as a push server

A distribution point is assigned for an administration group. In this case, the scope of the distribution point includes all devices within the administration group and all of its subgroups. However, the device that acts as the distribution point may not be included in the administration group to which it has been assigned.

You can make a distribution point function as a connection gateway. In this case, devices in the scope of the distribution point will be connected to the Administration Server through the gateway, not directly. This mode can be useful in scenarios that do not allow the establishment of a direct connection between the Administration Server and managed devices.

If you use a Linux-based device as a distribution point, we strongly recommend increasing the limit of file descriptors for the klnagent service, because if the scope of the distribution point includes many devices, the default maximum number of files that can be opened may not be enough.

Increasing the limit of file descriptors for the klnagent service

If the scope of a Linux-based distribution point includes many devices, the default limit of files that can be opened (file descriptors) may not be enough. To avoid this, you can increase the limit of file descriptors for the klnagent service.

To increase the limit of file descriptors for the klnagent service:

1. On the Linux-based device that acts as a distribution point, open the /lib/systemd/system/klnagent64.service file, and then specify the hard and soft limits of the file descriptors in the LimitNOFILE parameter of the [Service] section:

   LimitNOFILE=<soft_resource_limit>:<hard_resource_limit>

   For example, LimitNOFILE=32768:131072. Note that the soft limit of the file descriptors must be less or equal to the hard limit.

2. Run the following command to ensure that the parameters are specified correctly:

   systemd-analyze verify klnagent64.service

   If the parameters are specified incorrectly, this command can output one of the following errors:

   • /lib/systemd/system/klnagent64.service:11: Failed to parse resource value, ignoring: 32768:13107

     If this error occurs, the symbols in the LimitNOFILE line were specified incorrectly. You must check and correct the entered line.

   • /lib/systemd/system/klnagent64.service:11: Soft resource limit chosen higher than hard limit, ignoring: 32768:13107

     If this error occurs, the soft limit of the file descriptors you entered is more than the hard limit. You must check the entered line and ensure that the soft limit of the file descriptors is less or equal to the hard limit.

3. Run the following command to reload the systemd process:

   systemctl daemon-reload

4. Run the following command to restart the Network Agent service:

   systemctl restart klnagent

5. Run the following command to ensure that the specified parameters are applied correctly:

   less /proc/<nagent_proc_id>/limits

   where the <nagent_proc_id> parameter is the identifier of the Network Agent process. You can run the following command to obtain the identifier:

   ps -ax | grep klnagent

For the Linux-based distribution point, the limit of files that can be opened is increased.

Calculating the number and configuration of distribution points

The more client devices a network contains, the more distribution points it requires. We recommend that you not disable automatic assignment of distribution points. When automatic assignment of distribution points is enabled, Administration Server assigns distribution points if the number of client devices is quite large and defines their configuration.

Using exclusively assigned distribution points

If you plan to use certain specific devices as distribution points (that is, exclusively assigned servers), you can opt out of using automatic assignment of distribution points. In this case, make sure that the devices that you intend to make distribution points have sufficient volume of free disk space, are not shut down regularly, and have Sleep mode disabled.

Number of exclusively assigned distribution points on a network that contains a single network segment, based on the number of networked devices

Number of exclusively assigned distribution points on a network that contains multiple network segments, based on the number of networked devices

Using standard client devices (workstations) as distribution points

If you plan to use standard client devices (that is, workstations) as distribution points, we recommend that you assign distribution points as shown in the tables below in order to avoid excessive load on the communication channels and on Administration Server:

Number of workstations functioning as distribution points on a network that contains a single network segment, based on the number of networked devices

Number of workstations functioning as distribution points on a network that contains multiple network segments, based on the number of networked devices

If a distribution point is shut down (or not available for some other reason), the managed devices in its scope can access the Administration Server for updates.

Hierarchy of Administration Servers

An MSP may run multiple Administration Servers. It can be inconvenient to administer several separate Administration Servers, so a hierarchy can be applied. A "primary/secondary" configuration for two Administration Servers provides the following options:

• A secondary Administration Server inherits policies and tasks from the primary Administration Server, thus preventing duplication of settings.
• Selections of devices on the primary Administration Server can include devices from secondary Administration Servers.
• Reports on the primary Administration Server can contain data (including detailed information) from secondary Administration Servers.

The primary Administration Server only receives data from non-virtual secondary Administration Servers within the scope of the options listed above. This limitation does not apply to virtual Administration Servers, which share the database with their primary Administration Server.

Virtual Administration Servers

On the basis of a physical Administration Server, multiple virtual Administration Servers can be created, which will be similar to secondary Administration Servers. Compared to the discretionary access model, which is based on access control lists (ACLs), the virtual Administration Server model is more functional and provides a larger degree of isolation. In addition to a dedicated structure of administration groups for assigned devices with policies and tasks, each virtual Administration Server features its own group of unassigned devices, own sets of reports, selected devices and events, installation packages, moving rules, etc. The functional scope of virtual Administration Servers can be used both by service providers (xSP) to maximize the isolation of customers, and by large-scale organizations with sophisticated workflows and numerous administrators.

Virtual Administration Servers are very similar to secondary Administration Servers, but with the following distinctions:

• A virtual Administration Server lacks most global settings and its own TCP ports.
• A virtual Administration Server has no secondary Administration Servers.
• A virtual Administration Server has no other virtual Administration Servers.
• A physical Administration Server views devices, groups, events, and objects on managed devices (items in Quarantine, applications registry, etc.) of all its virtual Administration Servers.
• A virtual Administration Server can only scan the network with distribution points connected.

Information about limitations of Kaspersky Security Center

The following table displays the limitations of the current version of Kaspersky Security Center.

Limitations of Kaspersky Security Center

Network load

This section contains information about the volume of network traffic that the client devices and Administration Server exchange during key administrative scenarios.

The main load on the network is caused by the following administrative scenarios in progress:

• Initial deployment of anti-virus protection
• Initial update of anti-virus databases
• Synchronization of a client device with Administration Server
• Regular updates of anti-virus databases
• Processing of events on client devices by Administration Server

Initial deployment of anti-virus protection

This section provides information about traffic volume values after Network Agent 14 and Kaspersky Endpoint Security for Windows are installed on the client device (see the table below).

The Network Agent is installed using forced installation, when the files required for setup are copied by Administration Server to a shared folder on the client device. After installation, the Network Agent retrieves the distribution package of Kaspersky Endpoint Security for Windows, using the connection to the Administration Server.

Traffic

After Network Agents are installed on the client devices, one of the devices in the administration group can be assigned to act as distribution point. It is used for distribution of installation packages. In this case, traffic volume transferred during initial deployment of anti-virus protection varies significantly depending on whether you are using IP multicasting.

If IP multicasting is used, installation packages are sent once to all running devices in the administration group. Thus, total traffic becomes N times smaller, where N stands for the total number of running devices in the administration group. If you are not using IP multicasting, the total traffic is identical to the traffic calculated as if the distribution packages are downloaded from the Administration Server. However, the package source is the distribution point, not the Administration Server.

Initial update of anti-virus databases

The traffic rates during initial update of anti-virus databases (when starting the database update task for the first time on a client device), are as follows:

• Traffic from a client device to Administration Server: 1,8 MB.
• Traffic from Administration Server to a client device: 113 MB.
• Total traffic (for a single client device): 114 MB.

The data may vary slightly depending upon the current version of the anti-virus database.

Synchronizing a client with the Administration Server

This scenario describes the state of the administration system when intensive data synchronization occurs between a client device and the Administration Server. Client devices connect to the Administration Server with the interval defined by the administrator. The Administration Server compares the status of data on a client device with that on the Server, records information in the database about the last client device connection, and synchronizes data.

This section contains information about traffic values for basic administration scenarios when connecting a client to the Administration Server (see table below). The data in the table may vary slightly depending upon the current version of the anti-virus database.

Traffic

Overall traffic volume varies considerably depending on whether IP multicasting is used within administration groups. If IP multicasting is used, the total traffic volume decreases approximately by N times for the group, where N stands for the total number of devices included in the administration group.

The volume of traffic at initial synchronization before and after an update of the databases is specified for the following cases:

• Installing Network Agent and a security application on a client device
• Moving a client device to an administration group
• Applying a policy and tasks that have been created for the group by default, to a client device

The table specifies traffic rates in case of changes to one of the protection settings that are included in the Kaspersky Endpoint Security policy settings. Data for other policy settings may differ from data displayed in the table.

Additional update of anti-virus databases

The traffic rates in case of an incremental update of anti-virus databases 20 hours after the previous update are as follows:

• Traffic from a client device to Administration Server: 169 KB.
• Traffic from Administration Server to a client device: 16 MB.
• Total traffic (for a single client device): 16.3 MB.

The data in the table may vary slightly depending upon the current version of the anti-virus database.

Traffic volume varies significantly depending on whether IP multicasting is used within administration groups. If IP multicasting is used, the total traffic volume decreases approximately by N times for the group, where N stands for the total number of devices included in the administration group. 

Processing of events from clients by Administration Server

This section provides information about traffic volume values when a client device encounters a "Virus detected" event, which is then sent to the Administration Server and registered in the database (see table below). 

Traffic

Data in the table may vary slightly depending upon the current version of the anti-virus application and the events that are defined in its policy for registration in the Administration Server database. 

Traffic per 24 hours

This section contains information about traffic rates for 24 hours of the administration system's activity in a "quiet" condition, when no data changes are made either by client devices or by the Administration Server (see table below).

Data presented in the table describe the network's condition after standard installation of Kaspersky Security Center and completion of the Quick Start Wizard. The frequency of synchronization of the client device with Administration Server was 20 minutes; updates were downloaded to the Administration Server repository once per hour.

Traffic rates per 24 hours in idle state

Preparing to mobile device management

This section provides the following information:

• About Exchange Mobile Device Server intended for management of mobile devices over the Exchange ActiveSync protocol
• About iOS MDM Server intended for management of iOS devices by installing dedicated iOS MDM profiles on them
• About management of mobile devices that have Kaspersky Endpoint Security for Android installed

Exchange Mobile Device Server

An Exchange Mobile Device Server allows you to manage mobile devices that are connected to an Administration Server using the Exchange ActiveSync protocol (EAS devices).

How to deploy an Exchange Mobile Device Server

If multiple Microsoft Exchange servers within a Client Access Server array have been deployed in the organization, an Exchange Mobile Device Server must be installed on each of the servers in that array. The Cluster mode option must be enabled in the Exchange Mobile Device Server Installation Wizard. In this case, the set of instances of the Exchange Mobile Device Server installed on servers in the array is called the cluster of Exchange Mobile Device Servers.

If no Client Access server array of Microsoft Exchange Servers has been deployed in the organization, an Exchange Mobile Device Server must be installed on a Microsoft Exchange Server that has Client Access. In this case, the Standard mode option must be enabled in the Setup Wizard of the Exchange Mobile Device Server.

Together with the Exchange Mobile Device Server, Network Agent must be installed on the device; it helps integrate the Exchange Mobile Device Server with Kaspersky Security Center.

The default scan scope of the Exchange Mobile Device Server is the current Active Directory domain in which it was installed. Deploying an Exchange Mobile Device Server on a server with Microsoft Exchange Server (versions 2010, 2013) installed allows you to expand the scan scope to include the entire domain forest in the Exchange Mobile Device Server (see section "Configuring the scan scope"). Information requested during a scan includes accounts of Microsoft Exchange server users, Exchange ActiveSync policies, and users' mobile devices connected to the Microsoft Exchange Server over Exchange ActiveSync protocol.

Multiple instances of Exchange Mobile Device Server cannot be installed within a single domain if they run in Standard mode being managed by a single Administration Server. Within a single Active Directory domain forest, multiple instances of Exchange Mobile Device Server (or multiple clusters of Exchange Mobile Device Servers) cannot be installed either—if they run in Standard mode with an expanded scan scope that includes the entire domain forest and if they are connected to a single Administration Server.

Rights required for deployment of Exchange Mobile Device Server

Deployment of an Exchange Mobile Device Server on Microsoft Exchange Server (2010, 2013) requires domain administrator rights and the Organization Management role. Deployment of an Exchange Mobile Device Server on Microsoft Exchange Server (2007) requires domain administrator rights and membership in the Exchange Organization Administrators security group.

Account for Exchange ActiveSync service

When an Exchange Mobile Device Server is installed, an account is automatically created in Active Directory:

• On Microsoft Exchange Server (2010, 2013): KLMDM4ExchAdmin***** account with the KLMDM Role Group role.
• On Microsoft Exchange Server (2007): KLMDM4ExchAdmin***** account, a member of the KLMDM Secure Group security group.

The Exchange Mobile Device Server service runs under this account.

If you want to cancel the automatic generation of an account, you need to create a custom one with the following rights:

• When using Microsoft Exchange Server (2010, 2013), the account must be assigned a role that has been allowed to execute the following cmdlets:
  • Get-CASMailbox
  • Set-CASMailbox
  • Remove-ActiveSyncDevice
  • Clear-ActiveSyncDevice
  • Get-ActiveSyncDeviceStatistics
  • Get-AcceptedDomain
  • Set-AdServerSettings
  • Get-ActiveSyncMailboxPolicy
  • New-ActiveSyncMailboxPolicy
  • Set-ActiveSyncMailboxPolicy
  • Remove-ActiveSyncMailboxPolicy
• When using a Microsoft Exchange Server (2007), the account must be granted the access rights to Active Directory objects (see the table below).

  Access rights to Active Directory objects

  Access	Object	Cmdlet
  Full	Thread "CN=Mobile Mailbox Policies,CN=<Organization name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain name>"	Add-ADPermission -User <User or group name> -Identity "CN=Mobile Mailbox Policies,CN=<Organization name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain name>" -InheritanceType All -AccessRight GenericAll
  Read	Thread "CN=<Organization name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain name>"	Add-ADPermission -User <User or group name> -Identity "CN=<Organization name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain name>" -InheritanceType All -AccessRight GenericRead
  Read/write	Properties msExchMobileMailboxPolicyLink and msExchOmaAdminWirelessEnable for objects in Active Directory	Add-ADPermission -User <User or group name> -Identity "DC=<Domain name>" -InheritanceType All -AccessRight ReadProperty,WriteProperty -Properties msExchMobileMailboxPolicyLink, msExchOmaAdminWirelessEnable
  Extended right ms-Exch-Store-Active	Mailbox repositories of Exchange server, thread "CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Organization name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<Domain name>"	Get-MailboxDatabase | Add-ADPermission -User <User or group name> -ExtendedRights ms-Exch-Store-Admin

iOS MDM Server

iOS MDM Server allows you to manage iOS devices by installing dedicated iOS MDM profiles on them. The following features are supported:

• Device lock
• Password reset
• Data wipe
• Installation or removal of apps
• Use of an iOS MDM profile with advanced settings (such as VPN settings, email settings, Wi-Fi settings, camera settings, certificates, etc.)

iOS MDM Server is a web service that receives inbound connections from mobile devices through its TLS port (by default, port 443), which is managed by Kaspersky Security Center using Network Agent. Network Agent is installed locally on a device with an iOS MDM Server deployed.

When deploying an iOS MDM Server, the administrator must perform the following actions:

• Provide Network Agent with access to the Administration Server
• Provide mobile devices with access to the TCP port of the iOS MDM Server

This section addresses two standard configurations of an iOS MDM Server.

Standard configuration: Kaspersky Device Management for iOS in DMZ

An iOS MDM Server is located in the DMZ of an organization's local network with internet access. A special feature of this approach is the absence of any problems when the iOS MDM web service is accessed from devices over the internet.

Because management of an iOS MDM Server requires Network Agent to be installed locally, you must ensure the interaction of Network Agent with the Administration Server. You can ensure this by using one of the following methods:

• By moving the Administration Server to the DMZ.
• By using a connection gateway:
  1. On the device with iOS MDM Server deployed, connect Network Agent to the Administration Server through a connection gateway.
  2. On the device with iOS MDM Server deployed, assign Network Agent to act as connection gateway.

Standard configuration: iOS MDM Server on the local network of an organization

An iOS MDM Server is located on the internal network of an organization. Port 443 (default port) must be enabled for external access, for example, by publishing the iOS MDM web service on reverse proxy that supports Kerberos constrained delegation.

Any standard configuration requires access to Apple web services for the iOS MDM Server (range 17.0.0.0/8) through TCP port 2197. This port is used for notifying devices of new commands by means of a dedicated service named APNs.

Managing mobile devices with Kaspersky Endpoint Security for Android

Mobile devices with installed Kaspersky Endpoint Security for Android (hereinafter referred to as KES devices) are managed by means of the Administration Server. Kaspersky Security Center supports the following features for managing KES devices:

• Handling mobile devices as client devices:
  • Membership in administration groups
  • Monitoring, such as viewing statuses, events, and reports
  • Modifying local settings and assigning policies for Kaspersky Endpoint Security for Android
• Sending commands in centralized mode
• Installing mobile apps packages remotely

Administration Server manages KES devices through TLS, TCP port 13292.

Information about Administration Server performance

This section presents the results of performance testing of the Administration Server for different hardware configurations, as well as the limitations on connecting managed devices to the Administration Server.

Limitations on connection to an Administration Server

An Administration Server supports management of up to 100,000 devices without a loss in performance.

Limitations on connections to an Administration Server without a loss in performance:

• One Administration Server can support up to 500 virtual Administration Servers.
• The primary Administration Server supports no more than 1000 sessions simultaneously.
• Virtual Administration Servers support no more than 1000 sessions simultaneously.

Results of Administration Server performance testing

Results of Administration Server performance testing have allowed us to determine the maximum numbers of client devices with which Administration Server can be synchronized for specified time intervals. You can use this information to select the optimal scheme for deploying anti-virus protection on computer networks.

Devices with the following hardware configurations (see the tables below) were used for testing:

Administration Server hardware configuration

Hardware configuration of the SQL Server device

Administration Server supported creation of 500 virtual Administration Servers.

The synchronization interval was 15 minutes for every 10,000 managed devices (see the table below).

Summarized results of Administration Server load testing

If you connect Administration Server to a MySQL or SQL Express database server, it is not recommended to use the application to manage more than 10,000 devices. For the MariaDB database management system, the maximum recommended number of managed devices is 20,000.

Results of KSN proxy server performance testing

If your enterprise network includes a large amount of client devices and they use the Administration Server as KSN proxy server, the Administration Server hardware must meet specific requirements to be able to process the requests from the client devices. You can use the testing results below to evaluate the Administration Server load on your network and plan the hardware resources to provide for normal functioning of the KSN proxy service.

The tables below show the hardware configuration of the Administration Server and SQL Server. This configuration was used for testing.

Administration Server hardware configuration

SQL Server hardware configuration

The table below shows the results of the test.

Summarized results of KSN proxy server performance testing

Network settings for interaction with external services

Kaspersky Security Center uses the following network settings for interacting with external services.

Network settings

For proper interaction of Kaspersky Security Center with external services, consider the following recommendations:
- Unencrypted network traffic must be allowed on ports 443 and 1443 on the network equipment and proxy server of your organization.
- When Administration Server interacts with Kaspersky update servers and Kaspersky Security Network servers, it is necessary to avoid hijacking network traffic with certificate substitution (

To download updates through the HTTP or HTTPS protocol by using the klscflag utility:

1. Run the Windows command prompt by using administrator rights, and then change your current directory to the directory with the klscflag utility. The klscflag utility is located in the folder where Administration Server is installed. The default installation path is <Disk>:\Program Files (x86)\Kaspersky Lab\Kaspersky Security Center.
2. If you want to download updates through the HTTP protocol, run one of the following commands:
   • On the device with Administration Server installed:

     klscflag.exe -fset -pv klserver -s Updater -n DisableKLHttps -t d -v 1

   • On a distribution point:

     klscflag.exe -fset -pv klnagent -s Updater -n DisableKLHttps -t d -v 1

   If you want to download updates through the HTTPS protocol, run one of the following commands:

   • On the device with Administration Server installed:

     klscflag.exe -fset -pv klserver -s Updater -n DisableKLHttps -t d -v 0

   • On a distribution point:

     klscflag.exe -fset -pv klnagent -s Updater -n DisableKLHttps -t d -v 0