There are a number of possible scenarios where policy won’t be enforced on an endpoint. I would suggest first confirming that the DLP Agent has initialized. To do this, on the endpoint having the issues validate that the following processes are running: fcags.exe, (fcagswd.exe if you’ve enabled the watchdog feature), fcag.exe, fcagte.exe, and fcagt.exe. If the DLP agent fails to initialize you will generally be missing the fcagte.exe and fcagt.exe processes.
There are a number of reasons why the processes can fail to initialize and you should make sure to not confuse delay associated with the first starting these services with the services not starting up at all. (Generally, give them 30 or so minutes as a window to start-up – I've seen it takes a while.)
The most common reason I’ve come across for the services failing to start-up on an endpoint is because the Profile Single Process policy (Domain security settings -> Local Policies -> User Rights Assignment) is enabled for the user at the time of the DLP installation. I believe it’s because something fails to register during installation, so simply logging into an account that does not have this permission set does not actually resolve the issue because it creates other issues.
Possible Actions in above scenario:
- Action 1 in a lab environment: Log into a local admin account (the policy likely not to be applied) and run the fcag.exe process manually. I’ve always seen the processes start-up, but doing this causes another effect wherein they register with another account and the fcag.exe process does not start-up by default when you reboot the computer and log in as another user.
- Workaround: Remove the profile single process from the account that ePO framework agent uses (guess) or the user account you’re installing the DLP services with. Uninstall the DLP agent and create a new task to reinstall. You’ll find it comes up if this was the issue.