Access official resources from Carbon Black experts
Advanced Search
IMPORTANT ANNOUNCEMENT: On May 6, 2024, Carbon Black User eXchange (UeX) and Case Management will move to a new platform!
The Community will be in read-only mode starting April 19th, 7:00 AM PDT. Check out the blog post!
You will still be able to use the case portal to create and interact with your support cases until the transition, view more information here!
Carbon Black Cloud: Multiple Cloned Linux VDI are Reporting under the same Device ID
Environment
Carbon Black Linux Sensor: All Supported Versions
Linux: All Supported Versions
Symptoms
Events produced by all cloned worker nodes will report under the Device ID for the machine that was cloned to make the template.
The template VM is inadvertently registered as as a clone when the template image is created
Resolution
To prevent this issue from happening, the template machine’s sensor can be manually de-registered by removing both of these fields from the cfg.ini before the snapshot is taken. This will cause each cloned machine to register as a distinct endpoint when the sensor comes up for the first time. (We do not advise modifying the data in these fields - only removing them completely.)
DeviceId
RegistrationId
Alternately, the cfg.in file could be stripped of all detail except these fields:
PemFile
PubKeyFile
CompanyCode
BackendServer
CBLR
Additional Notes
The Linux sensor keeps it’s primary configuration details along with some more ephemeral state in the /var/opt/carbonblack/psc/cfg.ini file.
The cfg.ini file is created when the sensor is installed, changes while the sensor is running, and is used to manage many longer term stateful processes such as software upgrades, communication configuration and state, and device registration information.
The sensor normally reads the cfg.ini file once on startup and writes it one or more times when the sensor needs to update this information. Therefore the cfg.ini file should only be edited while the sensor is stopped. Modifications done while the sensor is running are likely to be overwritten by the sensor’s next update of the file, and in any case will not be visible to the sensor until it’s next startup. However, it is advisable to plan what changes to make in order to reduce the time span of sensor downtime that occurs while editing the file.
