Deployments
This documentation provides comprehensive guidance on deploying Endpoint Protector across various environments. Whether you are managing physical hardware, virtual appliances, cloud-based infrastructure, or integrating with existing management systems, this resource offers essential information and procedures.
This section covers a range of deployment methods, including:
- Physical and Virtual Appliances: Detailed instructions for configuration, deployment, and management.
- Cloud Platforms: Deployment strategies for AWS, GCP, and Azure, assuming existing cloud accounts and basic platform knowledge.
- Active Directory Integration: Leveraging Group Policy Objects for efficient client deployment.
- Third-party Management Tools: using JAMF and Microsoft Intune for streamlined deployment.
This section of the documentation provides best-effort guidance on deployment. It is optional and may not always reflect the latest interface or features, as third-party products can change frequently. For the most up-to-date information, refer to the official resources from the product vendor.
Staging the Server
To start using Endpoint Protector, you need to deploy a server instance. The server hosts all endpoint controls and behavior configuration and delivers the Endpoint Protector agent to endpoint systems. There are two principal options for server management; Customer-Managed or Provider- Managed. If Customer-Managed is a desired option, you can install the server On-Premise or in a Hosted-Cloud Environment.
With the On-Premise option for a Customer-Managed instance, you can set up a virtualized image in your LAN. Virtualization options include, but aren’t limited to: VMware and Hyper-V. The Hosted-Cloud method of deployment allows for use of a customer’s Amazon Web Services (AWS), Azure, or Google Cloud Platform (GCP) instance. See Virtual Appliance Formats for supported VM formats including VMware and Hyper-V, and Cloud Services for AWS, Azure, and GCP deployment details.
Alternatively, if a Provider-Managed setup is required, Netwrix can deploy an instance of Endpoint Protector in an isolated cloud environment. For details on the Provider-Managed option, speak with your Netwrix Account Manager.
To use the Endpoint Protector Server in a production environment, you need a License Key. After purchasing Endpoint Protector with the necessary modules, your Account Manager will assign a license that you can install in the Endpoint Protector Management Console (the configuration interface available on the Endpoint Protector Server).
The following sections describe the different methods for deploying Endpoint Protector, with step-by-step instructions and best practices.
Communication Between Endpoint Protector Server and Netwrix Servers
Communication between Endpoint Protector Server (apliance used by your company) and Netwrix servers is possible only when your server is connected to the internet.
When connected, Netwrix may access the following metadata information:
-
Server metrics:
- RAM
- Database version
- Web server version
- CPU type / number / frequency
- HDD size / partition / free space
- Operating system version
- Purchased product version
- Server serial number
- IP address
- MAC address of the server
-
Admin details:
- Name
- Email address
- Phone number
-
Licensing information:
- Number of licenses
- Validity
- Operating system platforms
- License utilization
- Module Activation Status
Netwrix collects this metadata strictly for licensing and statistical purposes. It doesn't include any customer-sensitive information or content stored or processed by your company.
Additionally, internet connectivity allows your company to:
- Download product updates
- Activate modules by communicating with Netwrix servers
The applicable privacy and security policies govern all communication with Netwrix servers.
Unified EPP Clients and Server Versioning
Starting with version 2509, Netwrix standardizes EPP product versioning. The versioning format follows a structured scheme that encodes the release year, month, target platform, and build metadata.
Key aspects of the new versioning system
Structured format: Version numbers follow the format:
YYMM.O.C.B
YYMM — Release year and month (e.g., 2603 = March 2026)
O — Target platform or component:
0= Server1= Windows Client2= Mac Client3= Linux Client4= Combined Win-Mac Environments (EE)
C — Custom/fork/build increment:
0= internal1= standard releases2+= customer-specific builds or hotfixes
B — Optional build number for internal tracking
Consistency across interfaces: This versioning format is applied across all UI pages where version numbers appear, including dashboards, reports, maintenance tools, and the EPP Client Notifier.
Examples of the New Versioning
| Description | Version |
|---|---|
| February 2026 server, standard build | 2602.0.1.0 |
| February 2026 Windows client, standard | 2602.1.1.0 |
| RHEL client, May 2026, custom #3 | 2605.4.3.0 |
| Server, April 2026, internal build #7 | 2604.0.0.7 |
This versioning system provides a transparent and easily navigable structure, improving your workflow.