Supposedly, the 2nd time a USB Device is inserted, it can be fully identified w/o the drive fully initializing.  The initial insert for a usb device requires more initialization to get sufficient details used to determine if it should or should not be blocked.  

Clearly, ESET wants to grab the device and scan it w/o delay so it can ensure it is safe so it will be locking the files as fast as it programmatically can do so.  ZESM will be trying to do the same thing on the initial insert of the usb device on a given machine.  I'm not sure ZESM will always be able to win.  I know if there are open locks Windows will not allow the device to be disabled and most certainly ESET has protections against its processes locking the files from being terminated.

 I'm not sure if ESET has a setting to delay the scanning of an inserted device, which may help.  I'm not sure that is a setting they would want and even in your setup, that could open a hole on USB devices that are allowed.

--

How are you trying to limit the use of USB devices with ZESM?  Trying to block end-users from ALL Thumbdrives?  Permit Certain ones?  etc....

Depending on your goal, I may be able to think of some workarounds.  

USB devices are generally permitted in the ZESM policy.
The default device access is "Disabled".
Device Group Access Settings:
- HID: Enabled
- Mass Storage Class: Disabled
- Printing Class: Enabled
- Scanning/Imaging (PTP): Enabled

And a list of 60 devices enabled.

best regards

Andre

Based on the USB USB Connectivity policy to disable USB attached storage drives, I  would expect that ZESM to attempting to Disable the USB attached  storage drive and  for multi layer policy enforcement set the File system and DAC drivers to block all access.      With the File System and DAC drivers blocking all drive access the User should not be able to Read, Write or Execute any files from the USB drive.   

 A storage device control policy is the preferred way of controlling, Read/Write, Read Only and Disabled access control settings for USB Storage devices.

If a user is still able to access/launch programs while being scanned by AV, you may want to open an SR and we can have the issue examined.

Hi Criag,

that´s interesting situation with USB Connectivity policy vs. Storage Device Control policy. Are there more examples of choosing some policy instead of other ? Because I was in same position as Andre, customer asked for disabling access to USB flash drives and I used the USB Connectivity policy. 

Above I suggested using both because there can be cases where we are prevented from disabling a Device.  So if something is blocking our ability to quickly block the device, Also use a policy to block R/W access.  Thus even if the device is not yet disabled, the user cannot access files on the device.

Note: Development is constantly working on ways to try and win the battle to block devices even when competing security software is working hard to prevent a device from being blocked.  Thus there is a chance 20.2 could help, but regardless I would recommend layering both.

Than you suggest to apply both policies to be sure , that one of them will "work" ?

Actually what I suggested is that in the event a PC contains Malware that blocks the Operating System from being able to disable a USB device when the OS sends the commands to disable the USB device, ZCM can thwart that Malware by also block access on the File System Level.

If Malware (Any Software that caused the Operating System to Fail Core Functions), I would either remove the Malware if was introduced maliciously or if it was actually installed install intentionally, I would alert that vendor to the fact that their software is preventing the OS from disabling devices and such behavior introduces significant risk.

Thankfully, ZCM is able to overcome the risks of such Malware via the FileSystem Hooks.