How to migrate your Cloud Service Detector to a new Enforce Server

Products

• Data Loss Prevention Cloud Detection Service
• Data Loss Prevention Cloud Detection Service for ICAP
• Data Loss Prevention Cloud Detection Service for REST
• Data Loss Prevention Cloud Package
• Data Loss Prevention Cloud Service for Email
• Data Loss Prevention

Issue/Introduction

For a reason such as the following, your Cloud Detection Server (aka CDS or Detector) needs to be enrolled on a new Enforce server:

1. You added your Detector to the wrong Enforce server (e.g., Prod to QA, or vice versa)
2. You purchased the Cloud Service after a trial and are moving the Detector to a Production environment
3. You have undergone some kind of Disaster Recovery scenario and Enforce is unrecoverable

In each case above, without further work, the Detector remains “bound” as far as the Gateway is concerned to a specific Enforce ID. This is true even if Enforce is “lost” or permanently down.

 

Environment

Release :

Component :

Cause

Firstly, the Cloud Detector as installed on your old Enforce Server will need to be deleted from that server.

This step is required if the old Enforce Server is still operational, if it is not deleted from Enforce, the Detector will “re-bind” when the Enforce server reconnects to the Gateway (as it will after a service restart, or if 24 hours has elapsed).

Even if Enforce has undergone hard failure and is no longer operational, the Detector is in a “bound” state (waiting for Enforce to reconnect) and cannot be enrolled in a new Enforce Server – not until this operation is performed.

 

Therefore, the most important step in unbinding must include verification by Technical Support that the CDS has in fact been deleted from the old Enforce server (or that the Enforce server is completely decommissioned).

Resolution

Scenario-based steps which Support will be following

A. New bundle required, meaning that you are going to same Enforce server as original (e.g., Enforce recovery from backup)

1. Please help the Support team to verify these specific details:
   1. Existing DetectorID from Enforce Server entry for Cloud Detector
   2. Existing EnforceID from Enforce Server entry
   3. Your setup for traffic coming to this Detector: Note that mail flow from MTAs, and/or content requests from REST or ICAP sessions, will essentially be skipping DLP while the Detector is unbound.
2. Skip to C below.

B. New Enforce server required, meaning that you are going to new Enforce server with new Enforce-ID (upgraded hardware, or similar move)

1. Take steps needed to dissociate traffic going to the Detector – the reason for this is because any data cached from old Enforce will not persist to new Enforce Server / database (it will create .BAD files in /incidents directory on new Enforce server).
   1. To disable DLP in WSS – follow Scanning level instructions for WSS to select “No Scanning” option for ICAP traffic.
   2. To disable DLP in CASB (CloudSOC) – choose “Edit > De-activate” in DLP Appliance entry in CloudSOC console. NOTE: Please do NOT “Remove” the Appliance, choose De-activate option.
   3. To disable Emails for Cloud Service – customers need to disable their Transport Rule for O365, Gmail, or on-prem (as apropos).
2. Continue to C.

 

C. If you have not done so, you should delete the Cloud Detector from your Enforce Server at this point. Please note that you will need to remove all Application Detection Configurations before deleting the Cloud Detector. It is also recommended to take a back of your current Application Detection configuration settings before deleting them as you will need to reconfigure them on the new Enforce. Support will need to confirm that the Detector is deleted from your old Enforce server (note that for “Scenario B”, any traffic still being sent to the Detector afterward will not create valid incidents).

1. Support will verify deletion if required and then “Unbind" the Detector.
2. After successful unbind (~2 minutes), Support will generate a new Enrollment Bundle.
3. Support should be able to assist with enrollment of the Detector on new Enforce system.
4. For best results, have change controls in place to allow the following if needed for troubleshooting:
   1. Recycle the DetectionServerController service on Enforce Server as needed
   2. Make changes to properties file for the DetectionServerController service if needed (see this KB for details)
   3. Re-enable traffic and update any rules as required (reverse steps if taken in B1 above).

D. Once the Detector is rebound and policy is synched to cloud, incidents will be generated and downloaded to Enforce. Depending on the size of the policies and the connection from your site, this could take a quite some time. Event Codes numbered “2705” will provide status when the initial sync has completed (see this KB for expected event codes).