For the integrations on this page, a problem shows up as a Resource Errors alert on the account's Provision page (with the message under Error Details), as a warning badge on the account under Integrations, or on the target system for an export. The tables below map what you find to a fix.
Start with the Test button on the account's Provision page. It signs in with the saved credentials and reports DNS, TCP, TLS, and sign-in as separate steps, so it names the layer that is broken ahead of the next discovery. Guardicore, Illumio, SentinelOne, ServiceNow, and Infoblox accounts offer it; AWS, Azure, and Security Manager are verified from their own pages.
For Panorama, NSX, Cisco FMC, and FortiManager, whose work runs through the Connector, see the Connector troubleshooting page instead. Its Infoblox table covers every Infoblox account; one without a Connector runs from the cloud, so its Test results and Resource Errors appear as they do for the integrations above.
To look up the exact text of a message instead, see Error Messages.
Any integration
| Symptom | Likely cause / fix |
|---|
| The password, secret, or token field is empty when the Provision page opens | Expected. Those fields are write-only, so they open blank. Leave the field blank to keep the saved value, or type a new one to replace it. "… is required" appears only until the account has been provisioned once. |
| The account saved, but nothing appears in Inventory | Saving validates the form rather than the connection, and the first discovery takes a little while. Press Test: a pass means the credentials are good and the run is still in progress. Otherwise wait a few minutes, refresh the Integrations page, and check the Provision page for Resource Errors. Discovery re-runs daily, so a fix to credentials is picked up by the next daily run. |
| Test is greyed out | Either the form has unsaved changes, so save first, or a ServiceNow or Guardicore account has neither Import nor Export checked. |
| Test fails at DNS lookup or TCP connection | Connect couldn't reach the host at all. Confirm the hostname or URL is right and that the system accepts HTTPS from the internet. A system reachable only from inside your network needs a different route in; contact FireMon Support. |
| Test fails at TLS certificate | The host presents a certificate Connect doesn't trust. The step's detail names the issuer and the names on the certificate. See Certificate errors. |
| Test fails at Sign-in and read | The host answered and the credentials didn't work. Re-enter them on the Provision page and confirm the account has what that integration's page lists under Before you start. |
| Resource Errors shows an authentication or authorization error | The credentials are wrong, expired, or under-privileged. Re-enter them on the Provision page, press Test, and confirm the account has what that integration's page lists under Before you start. |
| Resource Errors shows a connection or timeout error | Connect couldn't reach the system from the cloud. Confirm the hostname or URL is right and that the system accepts HTTPS from the internet. A system reachable only from inside your network needs a different route in; contact FireMon Support. |
| An error that was fixed still shows | Errors clear when a later discovery reads the same region without hitting them. Wait for the next run. |
| Items that were removed from the source are still in Inventory | The run that would have removed them hit an error, so Inventory was left as it was. Fix the error; a clean run removes them. |
Illumio (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|
| Authentication error | The Username must be the API key's authentication username (api_…), not your login name, and the Secret its secret. Create a new key in the PCE if the old one was revoked or expired. |
| "Not found" or an HTML page in the error | The API URL is missing the API path. It must end in /api/v2/, for example https://example.illum.io/api/v2/. |
| Discovery is slow, or the first run takes a long time | A PCE with more than 500 workloads takes longer to read. Let the run finish. |
| A workload is missing its IPs | Illumio reports no public IP or interface addresses for it. Check the workload's Interfaces in the PCE. |
SentinelOne (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|
| Authentication error | The API Token has expired or was revoked. Generate a new one and re-enter it. Tokens on a service user can be given a longer expiry than a personal token. |
| "Not found" or an HTML page in the error | The API Base URL should be the console URL with no path, for example https://example.sentinelone.net. |
| Discovery is slow | A large fleet takes proportionally longer. Let the run finish. |
| An asset has no IP | SentinelOne reported none for it. Check the asset in the console. |
Guardicore
| Symptom | Likely cause / fix |
|---|
| Discovery: authentication error | Wrong username or password, the user can't read assets, or Guardicore is making the user set a new password. Test reports the same failure. Fix the user in Guardicore, or re-enter the credentials on the Provision page. |
| Discovery: connection error | The host didn't answer. A pasted https:// or path is fine, so check the hostname itself, such as customer-12345.saas.guardicore.com, and that the management center accepts HTTPS from the internet. |
| Export: no rules appear in Guardicore after a change request passed | Check, in order: the Boundary's Target(s) includes the Guardicore account; the Boundary's result was Pass or Review (only those two export); the Guardicore user can read, create, edit, delete, and publish policy rules; and every rule is one Guardicore can express, which rules out a negated source or destination, a custom IP protocol, a Max Ports service, an ICMPv6 service, a port of 0, and a rule with no services, since any of those cancels the whole export. |
| Export: rules appear but are disabled | Expected when the change request's overall state is Review or Fail. Enable them in Guardicore once someone has approved them. |
| Export: a second copy of a rule appeared | Its comments were edited in Guardicore, so Connect couldn't match it on re-export. Delete the older copy and leave the comments alone. |
Export: unpublished draft rules are sitting in the connect-change-requests ruleset | An export failed partway through. Drafts sit inert. Discard them in Guardicore, then re-evaluate the change request. |
| Deleted the change request, but its rules are still in Guardicore | Expected. Connect leaves the rules in place when a change request is deleted. Remove them by hand. |
| The request no longer passes, or the Boundary no longer targets the account, but its rules are still enabled in Guardicore | Expected. Connect only writes to Guardicore when a Pass or Review Boundary exports the request. Disable or remove the rules by hand. |
ServiceNow
| Symptom | Likely cause / fix |
|---|
| Discovery: authentication error | ServiceNow would not issue a token, or the application user can't read the table. Press Test on the Provision page: the verdict names a refused token or a missing role. The token request below this table shows ServiceNow's own answer. |
| Discovery: "Invalid table" or no items | Table Name doesn't match a table in your instance. Use the table's internal name (cmdb_ci_server), not its label. |
| Discovery: items appear but have no IPs | IP Field Name isn't the field's internal name, or the field is empty or a reference on those records. Test fails when the table has no field by that name. |
| Discovery: fewer items than rows in the table | Row-level access rules hide rows from the application user. Check the table's read ACLs. |
| Export: rows never reach the staging table | The staging table may not exist: a failure creating it at save time, usually a missing personalize_dictionary role, still lets the save succeed. Confirm both tables exist under System Definition > Tables; if not, fix the application user's roles and save the Provision page again. |
| Export: rows arrive in the staging table but the target table stays empty | No active transform map has the staging table as its Source table. ServiceNow reports it per row: Error in Decommission History, or Connect's logs for a change request. |
Export: a JSON column ends with +1234 more | The list outgrew the column's 100,000 characters; what fits is present and parses. Map each rule's own addresses from u_raw. |
| Export: duplicate records in the target table | Every evaluation or match exports again. Coalesce in the transform map: u_id and u_rule_id for change requests, u_workflow_id and u_id for decommissioned assets. |
| Export: a change request row lists more addresses than its rule | Expected with several rules: u_sources and u_destinations cover the whole request. Map each rule's own addresses from u_raw. |
| Decommission History shows Error | Hover the tag for the message: credentials, a missing staging table, or a transform map error. See ServiceNow export messages. |
| Change request export: no way to tell if it worked | Nothing in Connect records it. Check the staging table in ServiceNow. |
Check the OAuth client from outside Connect. This returns an access_token when the client is set up. A 401 with access_denied means the grant-type property, the client's grant type or its application user needs attention; see Create the OAuth client in ServiceNow.
curl -s -X POST https://acme.service-now.com/oauth_token.do \
--data-urlencode grant_type=client_credentials \
--data-urlencode "client_id=<Client ID>" \
--data-urlencode "client_secret=<Client Secret>"
Security Manager (Inventory Discovery)
| Symptom | Likely cause / fix |
|---|
| Security Manager is missing from the Provider list | It's hidden until FireMon Support enables it for your organization. Ask them to enable it, then refresh the page, or sign out and back in. |
| Discovery error mentioning registration not found | Security Manager isn't registered with FireMon Insights yet. Complete Connect Your SIP Instance; discovery resumes on its own afterward. |
| No items after the first run | Confirm the Insights connection is active (Security Manager's Administration > Settings > Insights shows Registration Details), that the application server can reach ws.insights.prod.firemon.cloud on TCP 443, and that devices exist in the default domain. Only the default domain is discovered. |
| Discovery stopped after Security Manager moved to a new server | Insights rejects the new host by default. Ask FireMon Support to allow the new hostname. |
| Items disappeared and reappeared under new names | Objects are identified by device and name, so a rename in Security Manager is a new item. Expected. |
Asset Manager
Nothing runs on the Connect side for this provider, so its account never shows Resource Errors and has no Test button. Start with the integration's status in Asset Manager.
| Symptom | Likely cause / fix |
|---|
| The Assets count on Integrations stays at zero | The push hasn't run, or failed in Asset Manager. Check the integration's status and schedule there. |
| Asset Manager reports a sign-in failure | The Connect user's password changed, or the user was disabled or lost the Administrators role. Fix the user under Settings > Users, then re-enter the credentials in Asset Manager. |
The push fails with Resource lists are not enabled | Groups aren't enabled for your organization. Some messages call a Group a resource list. Contact FireMon Support. |
The push fails with This operation is supported for only "UserDefined/Other" accounts | The account it's pushing to isn't an Asset Manager account. Create one under Integrations and point Asset Manager at it. |
The push fails with Cannot find account | The account was deleted in Connect. Create a new one and reconfigure Asset Manager. |
| Assets removed in Asset Manager are still in Inventory | Connect removes them only when Asset Manager deletes them. Deleting the account removes all of its items. |
| An asset shows old IPs or tags | Connect holds what the last push sent. Check when the push last ran in Asset Manager. |
| The account shows Not provisioned | Expected. There is nothing to provision in Connect for this provider. |
AWS
| Symptom | Likely cause / fix |
|---|
| Verify Account Access fails | The stack hasn't finished, or its registration step failed. In the AWS console, check the stack's Events for the RegisterAccount resource; its status reason is the cause. Account attempting to register with wrong cloud account means the AWS Account ID entered in Connect is not the account the stack was created in. Failed to assume role means Connect could not assume the new role; an SCP or a changed trust policy is the usual cause. Maximum number of accounts means the organization is at its account limit. Once the stack shows CREATE_COMPLETE, verify again. |
| The stack fails on the StackSet | A region in EventRegions is not enabled in your account. Remove it from the parameter and create the stack again. |
| Accounts from an AWS Organizations rollout never appear | us-east-1 was removed from EventRegions. The StackSet registers each account from that region, so add it back and update the stack. |
| Resource Errors with Access Denied or not authorized | The role is behind the current template. Run the update command shown on the CloudFormation tab of the Provision page, or update the Organizations stack for accounts from that rollout. |
| Changes take a day to appear in Inventory | The account is running on the daily discovery alone, or the region is an opt-in region missing from EventRegions. Confirm the stack created the event StackSet in the regions you use, and add any opt-in regions. Some plans run this way by design. |
| Deleted the stack | Connect deregisters the account and shows it as Not provisioned. Create the stack again to provision it again, or delete the account in Connect too. |
Azure
| Symptom | Likely cause / fix |
|---|
| The provisioning command fails on the role definition or role assignment | Your user lacks permission to create custom roles or role assignments in the subscription. Owner, or User Access Administrator plus Contributor, is required. |
| Resource Errors mentioning the federated identity credential, subject, audience, or issuer | The Tenant ID or Client ID on the Provision page doesn't match the identity the command created. Copy the Client ID from the FireMonCloudDefenseIdentity identity in the FireMonCloudDefense resource group, confirm the tenant, and re-save. The corrected IDs are used from the next daily discovery, so the banner clears then. |
| Resource Errors saying the identity does not have authorization to perform action | The identity exists but its role assignment is missing, usually because the deployment stack was changed or deleted in Azure. Re-run the provisioning command. |
| Group export: the Azure account is not offered under Export To | The account was created with Read Only, or has no Default Region. The Groups form names the accounts it left out beneath the field. Set a missing region on the Provision page. To add export to a Read Only account, delete it, add the subscription again with Read & Write, and run the new provisioning command. |
| Group export: no IP Group appears in Azure | Check that the Azure account is under the Group's Export To, and that the Group has fewer than 5,000 IPv4 entries, the most an IP Group holds. |
| Deleted the Azure account, but its IP Groups are still in Azure | Expected. Deleting the account ends Connect's access to the subscription, so the IP Groups stay. Delete them in Azure; the tag managedBy : connect finds them. |
| Group export: the IP Group is missing addresses | The export carries IPv4 only. Otherwise the Group's filters currently match fewer items than expected; check the preview under Group Candidates. |
| Group export: the IP Group stopped updating | The Group has grown past the 5,000 entries an IP Group holds, so its exports stop and the IP Group keeps its last contents. Split the Group into narrower Groups and export each. |
| Renamed the Group, and now there are two IP Groups | Expected. The IP Group follows the Group's name, so a rename creates a new one and leaves the old one for any rules still referencing it. Repoint those rules at the new IP Group, then delete the old one in Azure. |
| Deleted the Group, but the IP Group is still in Azure | A firewall or policy rule still references the IP Group, and Azure keeps a referenced IP Group. Remove the reference, then delete the IP Group in Azure. |
| Group export: the IP Group's Provisioning state in the portal is Failed | Azure accepted the write and then could not apply it, usually because a firewall that references the IP Group is unhealthy. Check the firewall's status, then save the Group again to resend the export. |