Carbon Black Cloud Sensor: How To Troubleshoot Communication Issues

Carbon Black Cloud Sensor: How To Troubleshoot Communication Issues


  • Carbon Black Cloud Windows Sensor:  All versions
  • Carbon Black Cloud MacOS Sensor:  All versions
  • Carbon Black Cloud Linux Sensor:  All versions


General troubleshooting guide for sensor communication issues with the Carbon Black Cloud services


  1. Do the sensors you are seeing as offline all show the last check-in time as the same day/hour?  That points to an infrastructure change. Usually networking related, like a firewall ACL change, GPO change, new proxy, proxy password change, etc, or possibly a newly implemented zero trust solution like zScaler that pipes traffic through a VPN type solution.
    1. Test network connection to our services by following these docs:
      1. Windows Connectivity Guide:
      2. Mac/Unix Connectivity Guide:
    2. Do all the problem systems belong to the same subnet?  That points to a likely networking change
  1. Ensure that all firewall and proxy settings are correct.  Make sure that the certificate revocation (CRL) checks to GoDaddy can go through, unless you have disabled CRL checks.  Make sure the target can be resolved in DNS.  Have there been any changes to the system hostfile?
  1. If the above look good, what do the logs say?
    1. The c:\program files\confer\confer.log shows current attempts to connect to our cloud services.  It will iterate through several attempts to connect in a particular order.  Look for log entries around the same time as a “cloud hello” log entry
    2. Check the install logs, which detail the sensor registration process, including DNS issues, etc.  Note that if the sensor(s) have previously registered and appear in the console, this is probably not going to get you much.  But worth to know about.
  2. Is there an in-line SSL inspection device being used, for instance BlueCoat?  We use certificate pinning, so you cannot use a SSL decryption device on our traffic, or the connection will be rejected
  3. Are the GoDaddy root certs installed?
    1. and
  4. Is it possible that these are old records from a re-registered, reimaged, VDI or decomissoined device?
    1. If a system is re-registered (repcli reregister) it will get a new unique Device ID, and a new record will be generated for the sensor.  The old record will not be deleted.  This can lead to multiple records in the back-end database.
    2. A VDI system needs special setup or you will get duplicate records
    3. Devices that are decommissioned need to be removed from the console, unless the sensor is uninstalled and can communicate with our cloud services – upon uninstall, the sensor will attempt to contact our back-end services and de-register itself
      1. Sensors will show as “Active” for 30 days from last communication to our cloud services.  Then they will show as “inactive”
    4. Same with machines that are re-imaged – they will get a unique Device ID at reimage
      1. Export all your sensors data from the console to a csv, and make a pivot table in Excel to locate any duplicate records
  5. Auto-Delete enabled?
    1. You may not have the Auto Delete setting enabled  

This should help with 90% of communication issues.  If this does not help, please open a case and gather a sensor diagnostic and send the resulting file in to CB Support. and


Related Content

Carbon Black Cloud: How to Test Client Connectivity to CBC Backend (Windows)
Carbon Black Cloud: How to Test Client Connectivity to CBC Backend (Mac/Linux)
Carbon Black Cloud: What Ports must be opened on the Firewall and Proxy Servers?

Was this article helpful? Yes No
No ratings
Article Information
Creation Date: