Deprecated Versions: Apps for ServiceNow - Troubleshooting
Troubleshooting
• Solution: The URL in the configuration must be the Carbon Black Cloud Hostname from
the Authentication Page or the URL when you
are logged in to the Carbon Black Cloud console.
For example, https://dashboard.confer.net
• Solution: If you experience any errors, check the application logs to get information about the error and how to resolve it.
• Requires ServiceNow System Administrator role.
• Navigate to System Logs > System Log > Application Logs or VMware Carbon Black Cloud > Application Logs.
• Problem: Unable to create a new user in the ServiceNow instance
• Problem: When you install the application on a fresh instance and try to configure a new profile, sometimes it saves the
configuration profile with empty values and does not allow you to enter values in Configuration.
Solution:
• Clear the Cache by going to: https://{{servicenow instance url}}/cache.do>
• Log Out from the Instance and Login again.
• Create a new configuration profile by providing empty values. It will give field validations and will not save the Configuration.
• Problem: When you start data collection for the Configuration Profile, sometimes you don’t get an alert in the Alerts table.
• Solution:
• Open the Configuration profile
• Go to the Alert Filtering section
• Check the Filter Condition in Custom Query. Sometimes it may happen that for specific filters (like Device OS=Other,
Type=Device Control, etc.) in a specific time range there may be no alerts.
• Either change the time range for data collection or remove that filter and perform the Data Collection.
• Problem: Incident Creation Criteria are set to escalate certain alerts to Security Incidents, but the Security Incident is not
created according to the criteria.
Solution:
• Open the Configuration profile.
• Go to the Incident Creation tab.
• Check the value of the Condition. If it is incorrect, change it to the correct value.
• Save the Configuration and start the Data Collection.
• Check whether the Security Incidents are created.
Solution:
• To view the list of alerts associated with an Incident:
• Scroll down on the Incident Page
• Under “Related Links,” click on “Show All Related Lists”
• A new set of tabs will appear underneath.
• Click on the “Alerts” tab to view the list of alerts associated to the Incident.
• Problem: While ingesting data from AWS S3 via an AWS SQS Queue, if the Carbon Black Cloud Data Source Import Queue Entry remains in the New state or if the exception mentioned below occurs.
• Exception: ‘Couldn't send the decompressed data to ServiceNow after 3 retries for the Queue with sys_id: ’
• Solutions:
If the Carbon Black Cloud Data Source Import Queue Entries remain in the new state:
• Go to “CBC Data Source Import Queue Entry” by typing “x_vmw_cb_connector_cbc_data_source_import_queue_entry.list” in the navigator on the left.
• Copy the sys_id of the Queue entry which is in the New state.
• Navigate to the ECC queue table by typing “ecc_queue.list” into the navigator.
• Apply the filter: 'Agent' is 'mid.server.' AND 'Payload' contains 'sys_id' AND 'state' is 'output'
• Open ECC Queue entry.
• Change the 'state' to 'ready'.
If the above exception occurred in the Mid Log file:
• Go to the Mid Server log.
• Find the exception message from above and copy the queue entry sys_id from it.
• Navigate to the ECC queue table by typing “ecc_queue.list” into the navigator.
• Apply the filter: 'Agent' is 'mid.server.' AND 'Payload' contains 'sys_id' AND 'state' is 'output'.
• Open ECC Queue entry.
• Change the 'state' to 'ready'.
• Problem: While configuring a MID server, the exception message below is observed:
Exception:
WARNING *** WARNING *** An active MID Server with a duplicate name detected.
java.lang.Exception: An active MID Server with a duplicate name detected.
• Solution:
• Change the name of your MID server or rename the existing MID server with the same name.
• If the problem continues, refer to the below ServiceNow Knowledge Base article.
• Problem: Alerts from the Data Forwarder are not ingested to ServiceNow from the AWS S3 bucket
• Solution: The application scope must be “VMware Carbon Black Cloud”. If the application scope is other than “VMware Carbon Black Cloud” then alerts will not be ingested from AWS S3 Bucket.
See Install the Apps for more information.
Known issues
ITSM and SecOps Apps
SOAR actions including Update Endpoint Policy, Quarantine/Unquarantine Endpoint, Delete File on Endpoint
sometimes show multiple “Flow Execution started for….action” Worknotes for a single action.
For Some Process GUIDs, you may not receive Process Metadata for those selected alerts.
When fetching process details using an alert’s process GUID, sometimes the API response does not include that
alert id. The results in this initiating alert not having a process record associated with it.
Enriched events: Page size is set as 1000 in API calls, so while fetching events in pages, there is a mismatch in counts.
Flow number is shown instead of flow name in Worknotes for SOAR action in ServiceNow Quebec version.
Resolved in version 2.1.0 of both apps: If Incident Creation Criteria are set and then you give a default value to Alert Aggregation, the condition given to
Incident Creation will either vanish (if performed for the first time) or show the previous value as the value is
not saved if you refresh the page using the “Apply Defaults” button.
Able to perform Quarantine Endpoint SOAR action even if the alert has already been quarantined.
Able to perform Unquarantine Endpoint SOAR action even if the alert has already been unquarantined.
Able to perform Ban Process Hash SOAR action even if the alert has already been banned.
Able to perform Unban Process Hash SOAR action even if the alert has already been unbanned.
Vulnerability Response
The application doesn’t support a sliding window mechanism to get timebound sets of vulnerabilities; that is, every
time it will fetch all the vulnerabilities from Carbon Black Cloud.
If the user changes the “Run” field from the “VMware CBC Vulnerabilities Integration” then it will not get reflected
on the record of “Configuration Profile” associated with the same Integration Instance.
The number of Vulnerable Items can be greater than the number of Vulnerabilities.
ServiceNow requires asset name to be unique, however this is not enforced in Carbon Black Cloud. If two devices that have different Device Ids and the same name in Carbon Black Cloud, one will be discarded during ingest to ServiceNow.
When the default Integration instance is not valid, the user can change the “Validation Status” from the list of Integration instances.
If any one of the integration is in the “Ready” state then all other integration runs will be discarded as only one integration can be in the “Ready” state at a given time.
When any integration is in a “running” or “Wait Complete” state and if the user stops the integration run then the state would be “Complete” and the substate would be “User Cancelled”. After a period of time the substate will transition to “Success”.
If the profile is inactive and the user runs the scheduler then it will not run and the “Substate” in Integration run would be “Failed” with a note “Encountered error running the integration. Error: Cannot run integration without VR configuration profile”.
There exists a log with the message “0” in system logs which are of the “Information” level.
Sometimes empty logs are found which are “Diagnostic Log” and contain a message in the form-view but shows empty in the list-view.
When a user runs a scheduler from the configuration profile and then manually changes the scheduler from Integration Instance then the scheduler will be set to the value set by the user in Integration Instance.
