Frequently Asked Questions
This page covers the most common questions and issues you may encounter during EPP server migrations.
This page primarily covers migrating to 2608. Until Netwrix releases 2608 (expected late August 2026), legacy 5.x customers who need to migrate sooner can still follow the temporary Migrating from a Legacy 5.x Server to 2510/2604 path instead. Entries that differ between the two targets carry a 2510/2604 path: marker. Netwrix will remove this distinction, and these marked notes, once 2608 ships.
1. Migrating Directly from 5.9.4.2 to 2608
Yes. Once your server is on exactly 5.9.4.2, you can deploy the 2608 base image directly and restore your backup onto it — there's no need to route through the older 2510/2604 platform first. See Migrating from a Legacy 5.x Server to 2608.
If you're on any version older than 5.9.4.2 (5.7.0.0–5.9.4.1), you must first apply the cumulative patch to reach 5.9.4.2, create the backup there, and then deploy 2608. Attempting to restore a backup from 5.7.x, 5.8.x, 5.9.x, or 5.9.4.1 directly onto 2608 will fail at the import step.
Consider a fresh deployment instead: If the source server is on a very old or long-obsolete EPP version, consider a clean deployment of the 2608 image rather than the full migration path. Reconfiguring EPP on a fresh base installation can sometimes be faster and less risky than upgrading through multiple intermediate versions — especially in smaller environments or where you don't need historical log data. Discuss this option with your Netwrix account team or Support before committing to the upgrade path.
2510/2604 path: The same 5.9.4.2 requirement applies if you need to migrate before 2608 ships — see Migrating from a Legacy 5.x Server to 2510/2604. The only difference is the deployment target (2510/2604 instead of 2608).
2. Reaching 2604 Before Migrating to 2608
Not strictly, but Netwrix recommends it. If you're on 2509, 2510, 2601, or 2602, 2608 accepts a direct backup restore from your current version — but the 2604 → 2608 path is the most thoroughly tested in Netwrix labs. Netwrix has validated other source versions in that range less extensively for this specific migration. See Migrating from the Current Image Platform to 2608.
If you're already on 2604, migrate directly to 2608.
3. Log Data Handling When Migrating to 2608
This answer applies to self-hosted deployments — on-premises or customer-managed cloud-hosted (AWS, Azure, GCP). SaaS is the one exception: since Netwrix migrates SaaS appliances directly, Netwrix carries historical log data over as part of that managed migration. After migration, SaaS customers see two tabs in the Reports menu: one for historical data still held in MySQL, and one for current data captured and stored in CrateDB going forward. Everything in this answer applies only to the self-hosted migration paths covered in this guide.
The migration doesn't carry log data over automatically, and this isn't new behavior. The System Configuration Backup for migration has never included log data or file shadows — only policies, users, groups, and device rules.
2608 introduces CrateDB, a new database component dedicated to log storage. CrateDB ships empty on a freshly deployed 2608 server; MySQL continues to own configuration and EPP objects (Computers, Users, Groups), and CrateDB only stores new log data going forward. The migration doesn't convert or copy any historical log data from your old server into it.
If you need historical logs for compliance or forensics, export them via System Maintenance → Audit Log Backups before migrating, or keep your old server VM available. See the prerequisites section of either migration article for the full guidance.
2510/2604 path: CrateDB doesn't exist on this platform — this entire question doesn't apply. The System Configuration Backup limitation (no logs or file shadows) still applies the same way, though.
4. Client Bridge Version Requirement for the 2608 Client
No. Any client on 5.9.4.3 Hotfix 1 or on any 2511–2605 client version can upgrade directly to the 2608 client — there's no new intermediate/bridge version for this jump.
The historical CoSoSys-to-Netwrix signature bridge (5.9.4.3 Hotfix 1) applies only to endpoints still running an old CoSoSys-signed client (5.9.4.1 or older). See Client Upgrade Management for the full compatibility table.
2510/2604 path: The target client here is 2605, not 2608, but the bridge logic is identical — clients on 5.9.4.1 or older still need 5.9.4.3 Hotfix 1 first before they can receive the 2605 client. See the Certificate Bridge section in Migrating from a Legacy 5.x Server to 2510/2604.
5. Updating EE Clients Immediately After Migration
Yes. Since the 2509 release, Enforced Encryption changed its communication logic with the Endpoint Protector Server. Regular EPP clients can remain on an older supported version for a period after migration, but you must update EE clients to the latest version immediately after the server migration completes — don't treat this as a lower-priority, staged rollout.
Delaying the EE client upgrade can cause EE-protected drives to lose synchronization with the server or fail to communicate correctly. See Enforced Encryption Client Requires Immediate Update in Client Upgrade Management for the full guidance.
6. Restoring a 2509 Backup onto a 2510 Server
This entry applies only if you're still deploying on the older 2509/2510 image line. If you're migrating to 2608, see Migrating Directly from 5.9.4.2 to 2608 and Reaching 2604 Before Migrating to 2608 instead.
Netwrix supports this. Restoring a 2509 configuration backup onto a 2510 server migrates the configuration — the OS remains 2510. After you patch it to 2604, the result is functionally equivalent to a native 2510-based deployment at 2604. The only practical difference is disk sizing, as the 2509 base image has a smaller default disk allocation than 2510. If disk capacity is sufficient, this path is fully valid.
7. Backup Import Returns a 500 Error
This most commonly occurs with large backups or under-resourced VMs, specifically during backup import.
Steps:
- Verify the target VM meets the free-disk minimum in Server Requirements.
- Verify the backup file isn't corrupted — re-download from the source server.
- Verify you created the backup on a version your target accepts. 2608: 5.9.4.2 for the legacy path, or 2509/2510/2601/2602/2604 for the current-image path. 2510/2604 path: only exactly 5.9.4.2 is accepted.
- Try increasing PHP upload limits temporarily (see Backup File Exceeds 200 MB Import Limit).
- If none of these steps resolves it, contact Netwrix Support with the server logs from
/var/log/epp/.
If 500 errors continue after you complete the migration — recurring every few days and clearing only after a full server reboot — see Recurring HTTP 500 Errors Resolved Only by a Full Reboot instead. That's a different, ongoing issue rather than a one-time import failure.
8. Network/IP Settings Not Saving on the New Server
This is a known product issue that affected 2509 and early 2510 builds, where the IP configuration page fails to save if you fill only one DNS field. Netwrix fixed it in patch 2604 — this workaround only applies if you're on an unpatched 2509/early 2510 environment.
Workaround (unpatched 2509/early 2510 only): Fill both the Primary and Secondary DNS fields. Use 8.8.8.8 (Primary) and 8.8.4.4 (Secondary) if you don't have a secondary internal DNS server.
9. Email Alerts Not Working After Migration
The backup doesn't always fully restore SMTP credentials, and you typically need to re-enter them manually after migration.
Steps:
- Navigate to System Configuration → System Settings → Email Configuration.
- Re-enter the SMTP server address, port, username, and password.
- Use the Send Test Email function to confirm delivery.
- Re-verify that alert rules are enabled under Alerts.
10. Active Directory Sync Is Broken After Migration, Users/Groups Are Missing
AD/LDAP connectivity credentials may need re-entry after migration.
Steps:
- Navigate to System Configuration → Active Directory / LDAP.
- Click Test Connection — if it fails, re-enter the bind DN and password.
- Run a manual sync and verify the imported object count against your expected directory size.
AD Sync can complete without errors but only import a partial set of users or groups. Always cross-check the count, not just the "success" status.
11. SSO / Entra ID Login Fails After Migration to 2608
You may need to refresh Entra ID / SSO application registrations after migration.
Steps:
- Navigate to System Configuration → SSO.
- Verify Tenant ID, Client ID, and Client Secret are correct.
- Test login in an incognito browser window.
- If the issue persists, re-register the EPP application in your Azure AD / Entra ID tenant.
Alternative — SCIM integration: Since version 2601, EPP supports SCIM as an alternative to SSO-based user provisioning. If SSO continues to cause issues post-migration, consider switching to SCIM integration for directory synchronisation and user management.
12. EPP Clients Not Communicating After Migration
See also Endpoints Not Checking In After Migration in Troubleshooting for a same-IP-strategy and firewall-focused checklist for this scenario.
Checklist:
- Confirm the new server's IP/FQDN is reachable from endpoints (firewall, DNS).
- Confirm you enabled client communications on the server (System Configuration → System Settings).
- Confirm you uploaded the client packages to the server — 2608 (the target version), plus 5.9.4.3 Hotfix 1 only if any endpoints are still below that bridge version.
- Check the Device Control → Computers page and sort by Last Seen.
- If clients were on 5.9.4.1 or older and you didn't deploy 5.9.4.3 Hotfix 1 first, they can't receive the 2608 client package directly — deploy 5.9.4.3 Hotfix 1 first via your software distribution tool before upgrading to 2608. See Client Upgrade Management for the full client upgrade path.
- Verify that firewall rules allow HTTPS connections on the configured EPP communication port.
- Consider reinstalling the EPP Client if it appears corrupted.
13. Audit Log Backup Running Without Completing
This is a known issue on 2510 with 2604 patch. Netwrix fixed it in 2608.
Steps:
- Navigate to System Maintenance → Audit Log Backups.
- If a job has been running more than 4 hours, attempt to cancel it from the UI.
- If the cancel option is unresponsive, contact Netwrix Support — you may need a backend intervention to reset the job state.
- Don't start new Audit Log Backup jobs until you resolve the stuck job.
14. Artifact Logs Unavailable After Migration
This is a known issue. Contact Netwrix Support for the latest fix status and remediation steps.
15. The Log Report Page Isn't Loading / Export Is Failing
This can occur after migration due to backend indexing activity on the newly restored database.
Steps:
- Try a hard browser refresh (Ctrl+Shift+R).
- Log out and log back in.
- Try filtering for a smaller date range — very large log queries time out on newly migrated servers.
- If the issue persists across all filters and date ranges, contact Netwrix Support.
16. The Server Isn't Sending CAP (Content Aware Protection) Reports After Migration
Steps:
- Verify Content Aware Protection policies are active (Content Aware Protection → Policies).
- Check that the CAP Dashboard shows recent activity.
- Generate a test transfer that the system should detect and confirm whether it appears in CAP logs.
- If policies are active but the server isn't generating or sending reports, contact Netwrix Support — this is a known post-migration defect.
17. eDiscovery Is Showing a Token Error After Migration
This is a known product defect that can appear after migration.
Steps:
- Navigate to eDiscovery and note the exact error message.
- Try logging out and back in (token refresh).
- If the error persists, contact Netwrix Support with the error details.
18. Backend Security Updates Are Crashing the Server After Upgrading to 2601
This is a known product defect on 2601.
Steps:
- Don't repeatedly attempt to apply backend updates if the server crashes on the first attempt.
- Take a VM snapshot before any retry.
- Contact Netwrix Support immediately — you need a targeted fix.
19. Activating 2608 in an Air-Gapped or Offline Environment
Air-gapped activation requires an Offline Activation Patch specific to 2608. This is a separate patch from the EPP software cumulative patch; request it from Netwrix Support in advance.
Steps:
- Contact Netwrix Support or your account team before the migration maintenance window.
- Request the Offline Activation Patch for 2608 for your specific environment.
- Also request any offline CAP / eDiscovery activation patches if your license includes those modules.
- Stage all offline patches and have them ready before taking the server offline for migration.
2510/2604 path: Request the Offline Activation Patch for 2510 instead — the rest of the procedure is the same.
20. ELS for PHP Installation Failing
This applies only when migrating onto the 2509–2604 image line — including the temporary 5.x → 2510/2604 path. 2608 no longer uses the php_els entitlement — if your license still contains that field, 2608 ignores it, and this issue doesn't apply.
This can occur in some migration paths onto 2509–2604 when EPP doesn't correctly recognize the license. See Verifying the php_els License Entitlement (2509–2604 Only) in Troubleshooting for the full verification walkthrough. If ELS still shows as inactive after re-import, contact Netwrix Support — some cases require a manual backend fix.
21. The Effective Rights Report Is Empty After Migration
This is a known reporting layer issue that doesn't affect actual policies or enforcement. Netwrix fixed it in 2608 — migrate to 2608 to resolve it. If you're not yet ready to migrate, contact Netwrix Support for interim guidance.
2510/2604 path: This issue is still present on 2510/2604 — the fix ships only in 2608.
22. Complete Migration Process Duration
Approximate time estimates based on real migration experience. The legacy 5.x path includes the 5.9.4.2 cumulative patch step; the current-image path (2509–2604) skips it.
| Activity | Estimated Duration | Applies To |
|---|---|---|
| 5.9.4.2 cumulative patch installation | 15–60 minutes | Legacy 5.x path only |
| Background DB tasks post-patch | Up to 24 hours (scheduled at 9 PM nightly) | Legacy 5.x path only |
| System backup creation | 5–30 minutes depending on config size | Both paths |
| New 2608 VM deployment and network config | 30–60 minutes | Both paths |
| Trial license activation on 2608 | 5 minutes | Both paths |
| Upgrade fresh 2608 image to latest patch | 15–30 minutes | Both paths |
| Backup restore on 2608 | 15–45 minutes | Both paths |
| License re-import and verification | 5–10 minutes | Both paths |
| Client package uploads | 10–20 minutes | Both paths |
| Integration reconfiguration and testing | 30–90 minutes | Both paths |
| Endpoint check-in verification | 30–60 minutes after re-enabling communications | Both paths |
| Total end-to-end | ~4–8 hours active work + 24h stabilization window | Legacy 5.x path |
| Total end-to-end | ~3–6 hours active work + 24h stabilization window | Current-image path |
Plan for a full business day of active migration work, plus a 24-hour monitoring period before you consider the environment fully stable, regardless of which path you take.
23. Running the Old Server Alongside the New 2608 Server
Yes, and Netwrix recommends it — at least temporarily. The old server:
- Retains all historical event logs and file shadows (not migrated to 2608).
- Serves as your rollback if you discover critical issues post-migration.
- Provides a source for compliance or forensic purposes if any applicable regulation requires retention of historical data.
Keep the old server offline after you validate the new 2608 environment. Activate access to it only on demand (e.g. for a compliance review or rollback). Leaving it online unnecessarily increases the attack surface, particularly if the old server was running 5.9.4.2 or earlier, which no longer receives security patches.
Decommission the old server only after:
- All endpoints successfully communicate with 2608.
- You verified all integrations.
- You satisfied compliance and retention requirements for historical logs (exported or confirmed in SIEM).
- You created a full post-migration backup on 2608 and stored it securely.
Keeping two live EPP Server instances in production at the same time can have licensing implications. Contact your Netwrix account team to adjust licensing accordingly before running the old and new servers in parallel for an extended period.
2510/2604 path: Everything in this answer applies the same way — substitute "2510/2604" for "2608" until 2608 ships in late August 2026.
24. Reverting to an Older Version
Netwrix doesn't support reverting or downgrading an EPP Server to an older version, on any migration or upgrade path. If you discover critical issues after migrating, you can only rely on your own backups — specifically, the pre-migration VM snapshot of your old server. This is why keeping the old server VM alive and taking a snapshot before migration is mandatory.
Check that the version on your pre-migration snapshot is still supported before you roll back to it. Rolling back to a version past its support lifecycle leaves you without security patches or Netwrix Support — see Netwrix Endpoint Protector Server Supportability before deciding to roll back.
Contact Netwrix Support before attempting any rollback.
For additional assistance, contact Netwrix Customer Support at support.netwrix.com.