Error Messages

The error messages Connect can show you, what each one means, and how to fix it. Search the page for the text in front of you. Angle brackets mark values that change, so <host> is your hostname and <status> an HTTP status code.

If you have a symptom rather than a message, start with Connector troubleshooting or Integration troubleshooting.

Where errors appear

If this failed	Look here
A Connector job	Settings > Connectors > Jobs. Hover the job's Status
A connection test	The alert under the form on Integrations > (your account) > Provision, with a line per step. An on-prem test also lands on the Jobs page as a Test Connection job
Discovery or export for an account	Integrations > (your account) > Provision, under Resource Errors
A change request export or withdrawal	The request's page under Change, on its Exports tab
A save	On the form, or in a red message at the top of the page
A REST or GraphQL call	The response body, with an HTTP status code. See API authentication
Connector startup or pairing	The appliance console, and the Connector log. See Where logs live

How to read a job error

Causes are chained with <-. The text on the left is Connect's description of what failed. Each <- takes you one step closer to the underlying reason.

Cannot reach Infoblox host 192.0.2.10 <- connect ECONNREFUSED 192.0.2.10:443

Connect couldn't reach the grid, and the reason was a refused connection.

Long messages are cut short. A long vendor error can lose its ending. The Connector log has the full text.

A job at In Progress is not stuck. Connect retries failures it expects to clear on their own, such as a host that was briefly unreachable, and marks the job Error only once the retries run out.

Connection tests

The Test button on an account's Provision page reports its steps in order: DNS lookup, TCP connection, TLS certificate, and Sign-in and read. The first one to fail stops the test, and the rest are marked as not run. The step's own text names the host and the reason; a certificate failure is worded as in Certificate errors below. A ServiceNow test that passes adds a fifth step, Export setup; see The Export setup step.

These appear instead of a step list, for a test that stopped before reaching the host or lost track of its result.

Message	What it means	What to do
This account has no saved credentials yet. Save the form, then Test.	The account exists and is awaiting its first provisioning	Fill in the Provision page and save, then test
Could not read the saved credentials for this account. Save the form again, then Test.	The stored credentials couldn't be decrypted	Re-enter them on the Provision page and save
Connection testing is not available for <Product>.	Connection testing isn't offered for this provider	AWS, Azure, and Security Manager are verified from their own pages instead
Select a connector and save this account before testing it.	Panorama, NSX, FMC and FortiManager reach your network only through a Connector	Pick one in the Connector field and save
Connector <id> is not registered. Register it under Settings, then test again.	The account names a Connector that no longer exists	Pair a Connector under Settings > Connectors and select it on the Provision page
The connector did not report a result in time. Confirm it is online under Settings > Connectors, then try again. A test still running reports there.	The Connector didn't pick the test up within two minutes	Confirm it shows green under Settings > Connectors. A test that did run appears on the Jobs page as a Test Connection job
Could not queue the test for the connector. Try again in a moment.	Connect couldn't queue the test	Transient. Test again
The saved credentials do not match this account's provider. Save the form, then Test.	The stored credentials don't belong to this account's provider	Save the Provision page again, then test
The saved configuration does not match anything <Product> can test. Save the form, then Test.	The saved configuration is incomplete	Complete the Provision page and save, then test
A connection test is already running for this account. Try again in a moment.	An earlier test hasn't finished	Wait for its result
That connection test could not be found. Run the test again.	The test is no longer on record	Test again
Waiting for connector <name>., Waiting for connector <name> to run the test., A test is already queued for connector <name>.	The test is queued for that Connector. The message adds It has not checked in yet, so it may be offline. or It last checked in <time> ago, so it may be offline. when the Connector hasn't polled recently	Confirm the Connector is running and shows green under Settings > Connectors
Lost contact with Connect while waiting for the result. The test may still have run. Check Settings > Connectors, or try again.	Your browser lost its connection to Connect while waiting for the result	Check the Jobs page for the result, or test again
Could not start the test. Check that you can reach Connect, then try again.	The request to start the test never reached Connect	Check your own connection, then test again
The test was accepted but returned no job to track. Try again.	The test started, but there was nothing to track	Test again

What a failing step says

A failed step names the system, the host, and the reason, in one of these forms. <Product> is the system's name. An on-prem test says the Connector where a cloud test says Connect.

Message	What it means
Authentication failed. Check the credentials for <Product> at <host>.	The host answered 401 or 403
<Product> returned 404 at <host>. Check the host or instance name, and any table or path in the configuration.	The host answered, but not at that path
NSX Manager answered 404 at <host>. Check the account's Manager Type, since a Local Manager and a Global Manager serve different API roots, and that the host is an NSX Manager.	NSX's reading of the row above: the host answered, but not under the configured Manager Type's API root
<Product> is rate limiting requests. Try again shortly.	The host answered 429
<Product> returned HTTP <status> at <host>.	Any other HTTP error
<Product> did not respond at <host> within <n> seconds.	No answer within the step's time limit
Could not resolve the address for <Product> at <host>. Check the hostname.	DNS lookup failed
Could not resolve the address for <Product> at <host>. The DNS lookup did not answer within <n> seconds.	The resolver didn't answer in time
<Product> at <host> did not accept a connection on port <port> within <n> seconds. A firewall that drops traffic rather than rejecting it looks like this.	The TCP connection timed out
<Product> at <host> did not complete a TLS handshake on port <port> within <n> seconds.	The connection opened, but TLS didn't finish in time
<Product> at <host> did not complete a TLS handshake on port <port>. The connection closed during the handshake, which usually means the port is not serving TLS.	The port answers, but not with TLS
Connection refused by <Product> at <host>. Check the port and any firewall between Connect and the host.	The host, or something in front of it, refused the connection
The connection to <Product> at <host> was reset.	The connection dropped mid-request
<Product> at <host> is unreachable from Connect.	No route to the host
Request to <Product> at <host> failed.	Anything else, with the underlying reason appended
No host is configured for <Product>.	The Provision page has no host to test
Plain HTTP is configured, so there is no certificate to check.	The TLS step was skipped because the URL isn't HTTPS
Not run.	An earlier step failed first

What a passing test says

The Sign-in and read step reports what the test managed to read, which is worth checking even on a pass.

Product	Message
Guardicore	Connected to Guardicore and read the asset list.
Panorama	Connected to Panorama at <host> and authenticated. Device group '<name>' has <n> of <m> firewalls connected. With none connected it adds Exports wait for a connected firewall.
NSX	Reached VMware NSX <Manager Type> at <host> and authenticated. <Manager Type> is the account's setting: Local Manager or Global Manager (Federation)
Cisco FMC	Connected to Cisco Firewall Management Center <version> at <host> and authenticated. Domain '<domain>' found. The domain is the account's Domain setting, Global when blank
Fortinet FortiManager	Connected to Fortinet FortiManager <version> at <host> and authenticated. ADOM '<adom>' (FortiOS <version>, workspace mode <on or off>) found. The ADOM (administrative domain) is the account's ADOM setting, root when blank. A version the administrator is not allowed to read is left out
ServiceNow	Connected to ServiceNow and read table "<table>" and the table registry. The IP field "<field>" is present. With no rows in the table: Connected to ServiceNow and read table "<table>" and the table registry. It has no rows, so the IP Field Name was not checked. An import account whose user cannot read the registry still passes, with but not the table registry (sys_db_object), so exports from this account need a role that reads it in place of and the table registry. An account saved without Import Settings: Connected to ServiceNow and read the table registry.
Illumio	Connected to Illumio (organization <id>).
SentinelOne	Connected to SentinelOne.
Infoblox	Connected to Infoblox (WAPI v<version>) at <host>. Answered by <member>. The grid accepts bulk requests. The version shown is the one the test negotiated. The middle sentence names the grid member that owns the address, adding a Grid Master Candidate with read-only API access on (or off) when it is one, and through a node address rather than its VIP <address> when an HA member was reached on a node's own address. The last sentence reports what the grid said to a bulk read; the other endings, which still pass the test but stop the first discovery run, are under Infoblox below

The Export setup step

A ServiceNow test that passes adds an Export setup step, which checks what the exports need inside your instance. It never fails the test: rows reach the staging tables either way, and an account may only import. A warning lists every problem it found, one after another. A Not checked result is shown like a step that didn't run.

Message	What it means	What to do
Every staging table has a transform map: "<map>" into <table>.	Each staging table has at least one active map, and every map's target table exists. Each map is listed, separated by commas	Nothing
Not created yet: <table>. Saving the form creates the staging tables.	A staging table doesn't exist. Several are listed separated by commas	Save the Provision page. If the table still doesn't appear, the application user lacks personalize_dictionary
No active transform map reads <table>, so exported rows stay in staging.	Exports load rows into the table, but nothing moves them to a target. Several tables are listed separated by or	Create the transform maps for the exports you use
The application user sees no transform maps at all: none exist, or it cannot read sys_transform_map. Until an active map reads a staging table, exported rows stay there.	Either the instance has no transform maps, or the application user can't read them	Under System Import Sets > Administration > Transform Maps, look for maps whose Source table is a staging table. If there are none, create them. If they exist, don't add more: give the application user import_admin so Test can read them
Transform map "<map>" targets <table>, which does not exist. or Transform map "<map>" has no target table.	The map would fail on every row	Set the map's Target table to a table that exists
Not checked: the application user cannot read <table>.	The application user has no read access to sys_transform_map, or to sys_db_object	For sys_transform_map, exports work without it; for Test to check the maps, give the user import_admin. For sys_db_object, which the exports need, give the user a role that reads it, such as itil, asset or sn_change_read
Not checked: ServiceNow answered the <table> read with HTTP <status>. or Not checked: <table> could not be read.	The step's own read failed	Test again
Not checked: ServiceNow did not answer in time. or Not checked: the test ran out of time.	The instance answered slowly, and the test stopped waiting before the step's reads finished. The second means no time was left for them at all	Test again. The connection itself passed
Not checked without the table registry.	The application user can't read sys_db_object, which the exports need as well	See the Sign-in and read message about the table registry

Failures from the read itself

These come from the Sign-in and read step, where the host answered and the response wasn't what the integration expects.

Message	What it means	What to do
<host> answered HTTP <status>, redirecting to <target>. Something other than the WAPI answered: a Grid Master Candidate with read-only API access off, a non-master member, or a proxy in front of the grid.	The host is up, but the address is not serving the Infoblox WAPI. A redirect to another Infoblox hostname is a member sending the request to the Grid Master's GUI	Set Host Address to the Grid Master. In Grid Manager, Grid > Grid Manager > Members shows which member the address belongs to and whether it is the master
<host> answered HTTP <status> with a page titled "<title>". Something other than the WAPI answered: ...	The same, where the host served a web page instead of redirecting. The title says whose page: Grid Manager's own, or a proxy or sign-in portal in front of it	As above. A title from something other than Infoblox means a proxy is in the path between the Connector and the grid
No access token was returned. Check that the hostname is the management API.	Something other than the Guardicore API answered the sign-in, such as a proxy or SSO page	Hostname should be the management center's hostname, such as customer-12345.saas.guardicore.com. A pasted https:// or path is dropped, so check the host itself
The response was not an asset list. Check that the hostname is the management API.	Guardicore signed Connect in, then something other than its API answered the asset read	As above
The response was not a workload list. Check the API endpoint.	Illumio answered with something other than workloads	API URL must end in /api/v2/
The response was not an asset list. Check the API base URL.	SentinelOne answered with something other than assets	API Base URL should be the console URL with no path
ServiceNow did not answer as the Table API. Check the instance name.	Something other than the Table API answered	Instance Name is the subdomain, such as acme. A pasted https://acme.service-now.com is reduced to it; any other domain is not an instance name
ServiceNow answered, but the table registry (sys_db_object) could not be read. Check the instance name and that the application user can read tables.	An export-only account whose application user can't read sys_db_object. An import account reports the same gap inside its passing message instead	Give it a role that reads sys_db_object, such as itil, asset or sn_change_read; personalize_dictionary writes that table but does not read it
Connected to ServiceNow and read table "<table>", but it has no field named "<field>". Set IP Field Name to the field's internal name.	The table was read, but ServiceNow left the field out of the row because no column has that name. Discovery would run and produce items with no IPs	Set IP Field Name to the column's internal name (ip_address, not IP Address), shown under System Definition > Tables
ServiceNow at <host> did not issue an access token (HTTP <status>: <reason>). Check the Client ID and Client Secret, the OAuth client's grant type and application user, and that the instance allows the client credentials grant.	The token endpoint refused the sign-in. A wrong secret and a grant type that is not enabled get the same access_denied answer. With HTTP 403 the advice reads An access control on the instance refused the request instead	Re-enter Client ID and Client Secret, then check the client's grant type, its application user and the grant-type property under Create the OAuth client. For a 403, check the instance's IP access controls
ServiceNow at <host> did not answer as the OAuth token endpoint. Check the instance name.	Something other than ServiceNow answered the token request, such as a proxy or sign-in page	Check Instance Name, as for the Table API message above
ServiceNow at <host> issued an access token but rejected it on the API (HTTP 401). A REST API Access Policy on the instance may not allow OAuth for this API.	A token was issued, but the instance's access policy for that API does not include OAuth	Add an OAuth inbound authentication profile to the REST API Access Policies covering the Table, Import Set and Batch APIs
ServiceNow at <host> issued a token, but its OAuth client is securely scoped and cannot reach the platform APIs (HTTP 403). Set the client's Scope Restriction to Broadly Scoped, or add a REST API auth scope covering the Table, Import Set and Batch APIs.	The OAuth client was left at its default Scope Restriction of Securely Scoped	Set the client's Scope Restriction to Broadly Scoped under System OAuth > Application Registry
ServiceNow at <host> issued a token but refused the request (HTTP 403: <reason>). The application user lacks a role: snc_platform_rest_api_access where the instance enforces it, or read access to the table.	A token was issued, but the application user is missing a role the API needs. ServiceNow's own reason is quoted	Give the user the missing role from the table under Create the OAuth client
Device group '<name>' not found on Panorama. Available: <names>	The sign-in worked, but no device group on Panorama has that name	Set Device Group under Provision to one of the names listed, exactly as shown. The same message fails a job if the device group is renamed later
Signed in to Panorama at <host>, but this administrator role cannot read its device groups or managed devices. Grant it the privileges the Connector needs. (<cause>)	Panorama accepted the credentials and issued an API key, then refused the reads that follow, so the administrator role lacks XML API privileges the Connector uses	Give the role the privileges listed under Before you start
Reached NSX Manager at <host>, but it answers as a <type> and the account's Manager Type is <type>. Set Manager Type to <type> under Advanced and save.	The host is an NSX Manager of the other type. The configured Manager Type failed, so the test tried the other one, which answered	Set Manager Type under Advanced on the Provision page to the type named, save, and test again
Cisco Firewall Management Center at <host> is version <version>. Group export uses dynamic objects, which need FMC 7.0 or later.	The sign-in worked, but the release has no dynamic object API	Upgrade FMC, or point the account at an FMC on 7.0 or later
Domain '<name>' was not found on Cisco Firewall Management Center at <host>. Set Domain under Advanced to one of the domains this user can see, written as FMC prints it: <names>.	The sign-in worked, but the account's Domain is not one the user can see	Set Domain under Advanced to one of the names listed, exactly as shown, or leave it blank for Global
Signed in to Cisco Firewall Management Center at <host>, but this user cannot manage dynamic objects in domain '<domain>'. Give it the Object Manager > Modify Object Manager permission. (<cause>)	FMC accepted the credentials and then refused the read of the domain's dynamic objects	Give the user's role the Object Manager > Modify Object Manager permission in that domain. See Before you start
ADOM '<name>' was not found on Fortinet FortiManager at <host>. Set ADOM under Advanced to one of the ADOMs this administrator can see: <names>.	The sign-in worked, but the account's ADOM is not one the administrator can see	Set ADOM under Advanced to one of the names listed, exactly as shown, or leave it blank for root
Signed in to Fortinet FortiManager at <host>, but this administrator cannot work in ADOM '<adom>'. Give its Admin Profile read-write access to the ADOM's policy objects and set its JSON API Access to Read-Write. (<cause>)	FortiManager accepted the credentials and then refused the read of the ADOM's address objects	Give the administrator's profile read-write access to policy objects in that ADOM, and set its JSON API Access to Read-Write

A test proves the host is reachable, the credentials are accepted, for Panorama that the role can read device groups and devices and that the Device Group you named exists, for FMC that the release is 7.0 or later, the Domain exists and the user can read its dynamic objects, and for FortiManager that the ADOM exists and the administrator can read its address objects. The first real job proves the rest, such as that an NSX user can create Groups or an FMC user can change them.

Certificate errors

Connection tests, Infoblox discovery, and the Panorama, NSX, FMC and FortiManager exports word an untrusted certificate the same way. <Product> is the system's name: Panorama, NSX Manager, Cisco Firewall Management Center, Fortinet FortiManager, Infoblox, Illumio, and so on.

Message	What it means	What to do
<Product>'s TLS certificate at <host> is not trusted. Enable "Allow Self-Signed Certificate" on the account, or install a certificate from a publicly trusted CA on <Product>. (<reason>)	The certificate is self-signed, expired, issued by a private CA, or names a different hostname. <reason> gives the specific fault	For a self-signed certificate, turn on Allow Self-Signed Certificate under Advanced on the account's Provision page. For an expired certificate or a hostname mismatch, replace the certificate on the system itself. The job fails straight away rather than retrying, so it stays until you replace the certificate or change the setting
<Product>'s TLS certificate at <host> is not trusted. Install a certificate from a publicly trusted CA on <Product>. (<reason>)	The same fault, on an integration with no self-signed option: the cloud integrations other than Infoblox	Replace the certificate on the system itself. Connect reaches these systems over the internet and always requires a publicly trusted certificate

Any Connector job

Message	What it means	What to do
This connector build (v<version>) does not handle job type "<type>" for provider "<provider>". Upgrade the connector to claim this job.	The account uses an integration this Connector build doesn't support	Update the Connector. See Updates
Account <id> is not assigned to this connector	The Connector's account list doesn't include this account yet, or the account's Connector was changed after the job was queued	Usually nothing: the job stays In Progress and runs once the account reaches the Connector. Infoblox discovery fails the job instead. If it persists, check the account's Connector on its Provision page
The connector could not refresh its account list from Connect, so it could not confirm that account <id> is assigned to it. Try again.	The Connector couldn't reach Connect to refresh its accounts	The job stays In Progress and is retried. If it persists, run firemon-connector --check-connectivity
Exceeded maximum claim attempts (5)	The job was retried until Connect gave up, with no more specific reason recorded	Check that the target system is reachable from the Connector, and that the Connector wasn't restarted while the job was running
Failed to fetch credentials for account <id>: <status>	The Connector couldn't retrieve the account's credentials	Re-enter the credentials on the account's Provision page and save
Failed to fetch connector accounts: <status>	The Connector couldn't retrieve its list of accounts	Run firemon-connector --check-connectivity. See Network Requirements
Infoblox credentials are missing required fields (hostAddress, username, password)	The account was saved without a value the integration needs. Panorama, NSX, FMC and FortiManager report this the same way, as Panorama credentials ..., NSX Manager credentials ..., Cisco Firewall Management Center credentials ... and Fortinet FortiManager credentials ..., without naming the fields	Complete the account's Provision page and save
Failed to parse Infoblox credentials JSON	The stored credentials can't be read. Panorama, NSX, FMC and FortiManager report this the same way, with their own names	Re-enter the credentials on the Provision page and save. Contact FireMon Support if it happens again
Network error: <reason>	A call from the Connector to Connect failed	Retried automatically. If it persists, see Network Requirements
Connector shut down mid-job; re-enqueued for retry.	The Connector stopped for a restart or a self-update while running the job	Retried as soon as the Connector is back

Palo Alto Panorama

A job that could not reach Panorama at all uses the sentences under What a failing step says, with Panorama as the product and the Connector's own reason in parentheses, as in Connection refused by Panorama at <host>. Check the port and any firewall between the Connector and the host. (<cause>). The rest are below.

Message	What it means	What to do
Panorama request timed out after 30000ms	Panorama accepted the connection but didn't answer in time. On the sign-in it reads Panorama did not respond at <host> in time. (Panorama request timed out after 30000ms)	Retried automatically. Repeated timeouts usually mean Panorama is under heavy load
Panorama network error: <reason>	The connection dropped part-way through a request	Retried automatically. <reason> gives the network fault
Panorama API returned HTTP <status>: <reason>	Panorama rejected the request	A 403 reading Invalid Credential means the Username or Password is wrong. A 403 later in a run is an API key Panorama invalidated, which the Connector renews once on its own, so one that persists means the administrator account is missing a permission. See Before you start
Panorama keygen failed: <reason>	Panorama refused to issue an API key	Almost always the wrong credentials, or an administrator account without XML API access. Re-enter them under Provision
API key not found in keygen response	Panorama answered the key request without a key	Confirm the administrator account has XML API access
Panorama request failed: <reason> (PAN-OS code <n>: <name>)	Panorama accepted the request and reported a failure. <reason> is Panorama's own message, and the code and name are from Palo Alto's error code table when Panorama sent one	Code 22, a timed-out session, and conditions that clear on their own, such as a commit already running or a locked device group, are retried. Code 16 means the administrator's role lacks the right to that operation; code 10 means a rule still references the object. Anything else needs fixing in Panorama
Device group '<name>' not found on Panorama. Available: <names>	The name has to match a device group that already exists in Panorama, exactly and case-sensitively. Test on the Provision page reports this before any job runs	Correct Device Group under Provision, using a name from the Available list
No connected firewalls in the device group, so nothing was pushed to Panorama. Check that the device group has at least one connected firewall.	No firewall in the device group was connected to Panorama when the job ran	Retried automatically while a firewall reconnects; after the last attempt the job fails with this message. Check Panorama > Managed Devices > Summary. The job runs again when the Group next changes or the Connector restarts
Job <id> finished with result '<result>': <details>	A commit or push finished unsuccessfully. <details> is Panorama's explanation	Open the job in Panorama under Tasks for the full text
Job <id> did not complete within <ms>ms (status: <status>, progress: <n>%)	A commit or push was still running when Connect stopped waiting	Retried automatically. A large device group under load can need more than one attempt
commit failed: <reason>	Panorama refused the commit	A commit lock held by another administrator is the usual cause, and clears on its own
commit job failed: <reason>	The commit started and then failed or timed out	The Group's addresses are registered but not yet active on the firewalls. Retried on the next job
push failed: <reason>	Panorama refused to push the device group to its firewalls	Check the device group still has connected firewalls under Panorama > Managed Devices
push job failed: <reason>	The push started and then failed or timed out	Retried on the next job
Register failed on firewall <serial>: <reason>	Registering the Group's addresses failed on one firewall	Confirm the firewall is connected and the administrator role allows User-ID. Other firewalls are unaffected
Panorama User-ID request failed for <n> of <m> reported entries: <detail>	Panorama accepted the request and rejected some of the IP-to-tag entries in it	<detail> names the entries it rejected. The rest of the Group registered normally
Unregister failed on firewall <serial>: <reason>	Removing addresses that left the Group failed on one firewall	As above. Until a later run succeeds, the DAG keeps addresses that should have gone
This group's addresses are in place on the firewalls. The commit or push that failed was for other groups in this account.	A note on a Complete job: another Group's DAG change in the same account failed to commit or push. This Group's addresses were registered on the firewalls, which takes effect without a commit	Nothing for this Group. See the failed job for the other Group
DAG: <reason>	Creating or updating the Dynamic Address Group failed	<reason> gives the cause, usually a missing permission on the device group

VMware NSX

A job error leads with what to check and quotes the failing call in parentheses: the operation, the HTTP status NSX returned, and the start of its error body, as in (NSX PATCH /infra/domains/default/groups/firemon-<id>: HTTP 403 - {"error_code":...}). The lead sentences are those under What a failing step says, with NSX Manager as the product, plus the ones below.

Message	What it means	What to do
Authentication failed. Check the credentials for NSX Manager at <host>. (NSX POST /api/session/create: HTTP 401 (check NSX username/password) - <body>)	NSX rejected the login	Re-enter Username and Password under Provision. NSX locks an account for 15 minutes after five failed logins, and any attempt during the lockout restarts it, so correct the credentials before saving again
Authentication failed. Check the credentials for NSX Manager at <host>. (<operation>: HTTP 403 - <body>)	The account signed in but isn't allowed to perform the operation	Give the account permission to create and update Groups in the default domain
Reached NSX Manager at <host>, but it answers as a <type> and the account's Manager Type is <type>. Set Manager Type to <type> under Advanced and save.	Every Group in the job failed under the configured API root, and the other root answered: the account's Manager Type is wrong	Set Manager Type under Advanced on the Provision page to the type named, save, and press Test. Saving the account does not re-run the job: the export resumes when the Group next changes or the Connector restarts
NSX Manager answered 404 at <host>. Check the account's Manager Type, since a Local Manager and a Global Manager serve different API roots, and that the host is an NSX Manager. (<operation>: HTTP 404 - <body>)	The path is absent on this Manager and the other Manager Type's root did not answer either	Check NSX Manager Host, then press Test on the Provision page. See NSX
NSX Manager is rate limiting requests. Try again shortly. (<operation>: HTTP 429 - <body>)	NSX's per-client API limit was reached	Retried automatically
NSX Manager returned HTTP <status> at <host>. (<operation>: HTTP <status> - <body>)	NSX rejected the request. <body> is NSX's own error	Read <body>. A 5xx is retried automatically; a 400 names what NSX would not accept
NSX Manager returned HTTP <status> at <host>. (<operation>: HTTP <status> (redirects to <url>) - <body>)	The host redirected the request instead of answering it	The account usually points at a load balancer or reverse proxy. Point NSX Manager Host at NSX Manager
NSX Manager did not respond at <host> in time. (<operation>: timed out after 30000ms)	The Manager accepted the connection and didn't answer in time	Retried automatically. A Manager that is consistently slow is worth checking
<operation>: HTTP <status> - session expired, re-authenticating	The reused NSX session had expired	Retried automatically with a fresh login. Worth a look only if it repeats
<operation>: NSX Manager Host "<host>" is not a valid hostname	The saved host cannot be dialed at all	Correct NSX Manager Host under Provision: a hostname or IP address, with a port as host:port if needed
<operation>: response missing JSESSIONID cookie or X-XSRF-TOKEN header	The sign-in succeeded but returned no usable session	Something between the Connector and NSX is stripping cookies or headers. Point the account at NSX Manager directly
<operation>: invalid JSON response: <reason>	The host returned something other than JSON	Usually a proxy or captive portal answering in NSX's place
NSX accepted <path> but could not apply it (realization status ERROR). Check its Status under Inventory > Groups in NSX Manager; the environment's limit on group members is the usual cause.	NSX took the update and then failed to realize the group. <path> ending in -ipv4 or -ipv6 names a member group of a mixed Group; the group that nests it was not touched	Open the group under Inventory > Groups and read its status. Split the Connect Group into narrower Groups if it is over your environment's member limit
NSX accepted <the group, or its IPv4 or IPv6 member group> but had not applied it within 30 seconds (status <status>). Check its Status under Inventory > Groups in NSX Manager.	A warning on a Complete job: NSX was still applying the group, or one member group of a mixed Group, when the Connector stopped waiting. <status> is NSX's own state: IN_PROGRESS or UNINITIALIZED is normal; SANDBOXED_REALIZATION_PENDING on a Global Manager means the group conflicts with a site's local configuration and waits for an administrator	Check the group's Status column after a minute. It usually finishes on its own; a sandboxed group needs the conflict resolved on the Global Manager
NSX accepted <the group, or its IPv4 or IPv6 member group>, but its status could not be read afterwards. Check its Status under Inventory > Groups in NSX Manager.	A warning on a Complete job: the update went through, but the status request after it failed	Check the group's Status column. Worth a look only if it repeats
NSX group would have <n> members; the API allows at most 25000 per group - split the Connect Group across multiple NSX groups	The Group holds more addresses than a single NSX group accepts, both families counted together	Narrow the Group's filters, or split it into several Groups and export each. See Group size limits
No CIDRs fetched for list <id>	Connect couldn't read the Group's addresses before the sync	Retried automatically

Cisco Firewall Management Center

A job error leads with what to check and quotes the failing call in parentheses: the operation, the HTTP status FMC returned, and FMC's own message, as in (FMC POST object/dynamicobjectmappings: HTTP 403 - Invalid domain. Object belongs to another domain.). The lead sentences are those under What a failing step says, with Cisco Firewall Management Center as the product, plus the ones below. The job's Summary names the host and domain, then what changed: Objects Created, Descriptions Updated, Mappings Added, Mappings Removed, or No changes (<n> groups in sync).

Message	What it means	What to do
Authentication failed. Check the credentials for Cisco Firewall Management Center at <host>. (FMC POST auth/generatetoken: HTTP 401 (check FMC username/password) - User authentication failed.)	FMC rejected the sign-in	Re-enter Username and Password under Provision
Domain '<name>' was not found on Cisco Firewall Management Center at <host>. Set Domain under Advanced to one of the domains this user can see, written as FMC prints it: <names>.	The account's Domain is not one the user can see. Every Group of the account fails with it	Set Domain under Advanced to one of the names listed and save. Saving does not re-run the job: the export resumes when the Group next changes or the Connector restarts
Cisco Firewall Management Center at <host> is version <version>. Group export uses dynamic objects, which need FMC 7.0 or later.	The FMC is older than 7.0, so it has no dynamic object API. Every Group of the account fails with it	Upgrade FMC, or point the account at an FMC on 7.0 or later
Signed in to Cisco Firewall Management Center at <host>, but this user cannot manage dynamic objects in domain '<domain>'. Give it the Object Manager > Modify Object Manager permission. (<operation>: HTTP 403 - <body>)	The user signed in but may not create or change dynamic objects there	Give the user's role that permission in the domain
Domain '<domain>' on Cisco Firewall Management Center at <host> cannot change this dynamic object, which belongs to another domain. Point the account at the domain that owns it, or delete the object there. (<operation>: HTTP 403 - Invalid domain. ...)	The object exists in an ancestor domain, so the account's domain can see it but not change it	Set Domain to the domain that owns the object, or delete the object there once no rule references it
Cisco Firewall Management Center already has a dynamic object named "<name>" that domain '<domain>' cannot see or change, since names are unique across all domains. Delete it in the domain that owns it, or point the account at that domain. (<operation>: HTTP 500 - The object name <name> already exists.)	The Group's object exists in a domain the account cannot see, usually after the account's Domain was changed	Delete the old object in its domain, after removing it from any rule, or set Domain back
Cisco Firewall Management Center at <host> no longer has the dynamic object this update was for, so it was deleted by hand. The job is retried and the retry recreates it. (<operation>: HTTP 404 - Cannot find Dynamic object...)	An object in the mapping request was deleted in FMC between the Connector's read and its write	Retried automatically; the retry recreates the object
Cisco Firewall Management Center at <host> refused the mapping values the Connector sent. Contact FireMon Support with this job's details. (<operation>: HTTP 404 - Invalid mapping values: ...)	FMC rejected a value in the request, which the Connector should never send	Contact FireMon Support with the job's details; the job fails the same way on every run until it is fixed
Cisco Firewall Management Center is rate limiting requests. Try again shortly. (<operation>: HTTP 429 - <body>)	FMC's per-address request limit was reached, or another client was writing at the same time	Retried automatically
Cisco Firewall Management Center returned HTTP <status> at <host>. (<operation>: HTTP <status> - <body>)	FMC rejected the request. <body> is FMC's own message	Read <body>. A 5xx is retried automatically; a 400 or 422 names what FMC would not accept
Cisco Firewall Management Center did not respond at <host> in time. (<operation>: timed out after 30000ms)	FMC accepted the connection and didn't answer in time	Retried automatically. An FMC that is consistently slow is worth checking
Another client signed in to Cisco Firewall Management Center at <host> as this user: FMC allows one API session per user. Give the Connector its own user. (<operation>: HTTP 401 - FMC rejected the session token)	Something else signed in to FMC as the Connector's user. FMC keeps one API session per user, so that sign-in invalidated the Connector's token, and a fresh sign-in was rejected the same way within the attempt	A job is retried automatically; test again by hand. If it repeats, another Connector or a script is using the same user: give the Connector a user of its own
<operation>: FMC Host "<host>" is not a valid hostname	The saved host cannot be dialed at all	Correct FMC Host under Provision: a hostname or IP address, with a port as host:port if needed
<operation>: response missing the X-auth-access-token or DOMAINS header	The sign-in succeeded but returned no usable session	Something between the Connector and FMC is stripping headers. Point the account at FMC directly
<operation>: invalid JSON response: <reason>	The host returned something other than JSON	Usually a proxy or captive portal answering in FMC's place
This group was deleted in Connect. Its FMC dynamic object was left in place. ...	A note on a Complete job: the Group is gone and its object was retained	Delete the object in FMC once no rule references it
No access control rule references this group's new FMC dynamic object, so it has no effect on any firewall yet. ...	A note on the Complete job that created the object: its mappings are in place, but nothing uses it yet	Add the object to an access control rule and deploy that policy once. See Use the object in your policy. Later jobs do not repeat the note
<n> addresses were left out of this group's FMC dynamic object because FMC cannot map them: <addresses>. The other members are in sync.	A note on a Complete job: those addresses of the Group are not a bare IP, a CIDR or a range whose start is not above its end	Correct or remove those addresses in the Group. The rest of the Group is exported

Fortinet FortiManager

A job error leads with what to check and quotes the failing call in parentheses: the method and URL, FortiManager's own status code and message, as in (FortiManager set /pm/config/adom/root/obj/firewall/addrgrp/firemon-...: 1 of 1 operations failed - ...: -9001 value too long). FortiManager reports a failure as a negative status code and a short message, so the code is the part to read. The lead sentences are those under What a failing step says, with Fortinet FortiManager as the product. The job's Summary names the host and ADOM, then what changed: Address Groups Written, Address Objects Written, or No changes (<n> groups in sync), followed by any install lines. The Install:, Installed:, Install skipped: and Install failed: lines describe every Group of the account synced in the same batch, so a job can show a line about another Group's install.

Message	What it means	What to do
Authentication failed. Check the credentials for Fortinet FortiManager at <host>. (FortiManager exec /sys/login/user: ... Login fail)	FortiManager rejected the sign-in. The same lead sentence with an HTTP 401 or HTTP 403 in the parentheses is a later call FortiManager refused: a session it dropped, which is retried with a fresh sign-in, or an administrator without JSON API access	Re-enter Username and Password under Provision, and check the administrator's JSON API Access in FortiManager
ADOM '<name>' was not found on Fortinet FortiManager at <host>. Set ADOM under Advanced to one of the ADOMs this administrator can see: <names>.	The account's ADOM is not one the administrator can see. Every Group of the account fails with it. A shorter form without the list of names appears when the ADOM disappears during a job	Set ADOM under Advanced to one of the names listed and save. Saving does not re-run the job: the export resumes when the Group next changes or the Connector restarts
ADOM "<name>" cannot be used: a FortiManager ADOM name has no slash or control character. Set ADOM under Advanced to the name FortiManager lists under System Settings > All ADOMs, or leave it blank for root.	The account's ADOM holds a character FortiManager cannot take in a name, so nothing was sent. Every Group of the account fails with it, and Test reports it the same way	Correct ADOM under Advanced and save
Signed in to Fortinet FortiManager at <host>, but this administrator cannot work in ADOM '<adom>'. Give its Admin Profile read-write access to the ADOM's policy objects and set its JSON API Access to Read-Write. (<operation>: ... -11 No permission for the resource)	The administrator signed in but may not read or change objects there	Give the profile read-write access to the ADOM's policy objects, and JSON API Access Read-Write
Another session holds the workspace lock on ADOM '<adom>' of Fortinet FortiManager at <host>, so nothing was written. The job is retried. (<operation>: ... locked by <admin>)	The ADOM runs in workspace mode and another session holds its lock	Retried for a while. If the lock is still held, the job fails with this message and runs again when the Group next changes or the Connector restarts. For an account with installing on, a restart syncs the Group again, and the failed job is closed once the Connector's background install check finds the Group in sync with no install left to retry; the job's summary then says whether it installed. A lock left behind by a closed session can be released under System Settings > All ADOMs
The Connector's session on Fortinet FortiManager at <host> ended while it held the workspace lock on ADOM '<adom>', so FortiManager discarded the batch and nothing was written. The job is retried. (<operation>: session rejected ...)	FortiManager dropped the Connector's session while the ADOM was locked, which discards the lock and every change not yet committed: a FortiManager restart or HA failover during the job, or an administrator disconnecting the session	Retried; the retry writes the batch again. If it keeps happening, check FortiManager for restarts or disconnected sessions
The Connector's session on Fortinet FortiManager at <host> ended while the batch was being committed to ADOM '<adom>', so whether it was written is unknown. The job is retried. (<operation>: ... may already have been applied; ...)	FortiManager dropped the Connector's session as the batch was committed, before the Connector could read back whether the commit applied	Retried; the retry reads the ADOM and writes only what is missing
The install of <package> to <device> (<vdom>) did not complete: Another session holds the workspace lock on ADOM '<adom>' of Fortinet FortiManager at <host>, so the install was not attempted. The objects are in the ADOM; only the install remains.	Another session held the ADOM's workspace lock when the install was due: taken after this sync committed its objects, or already held when the sync started, in which case nothing was written either	Retried for a while; the retry installs the package once the lock is free. If the lock is still held, the job fails with this message, and the next sync of the Group installs the package while it still shows Modified
The install of <package> to <device> (<vdom>) did not complete: The Connector's session on Fortinet FortiManager at <host> ended while it held the workspace lock on ADOM '<adom>', so the install stopped. The objects are in the ADOM; only the install remains.	FortiManager dropped the Connector's session while it was installing, which discards the lock and any staged install with it. The objects were committed before the install began	Retried; the retry installs the package if it still shows as anything other than Installed
The install of <package> to <device> (<vdom>) did not complete: <reason>. The objects are in the ADOM; only the install remains.	The install hit a problem that may pass: the task did not finish within 15 minutes, the device did not answer, FortiManager was busy, or another of the Connector's jobs was working in the same ADOM. When the reason begins Connect could not confirm that installing is still turned on, the read of the account's settings from Connect failed instead; check the Connector's connection to Connect	Retried for a while; the retry installs the package. If it keeps failing, the job fails with this message: read <reason>, fix the cause, and install the package yourself or change the Group
The policy packages to install could not be resolved: <reason>. The objects are in the ADOM; only the install remains.	FortiManager did not answer the package status, the where-used search or the package listing in time	Retried for a while; the retry resolves and installs. A FortiManager that is consistently slow is worth checking
FortiManager address group <name> would have <n> members; FortiOS allows at most 5,000 per group. Split the Connect Group across narrower Groups.	One address family of the Group exceeds the group size FortiOS accepts	Narrow the Group's filters, or split it into several Groups and export each. See Group size limits
Fortinet FortiManager did not respond at <host> in time. (<operation>: timed out after 30000ms)	FortiManager accepted the connection and didn't answer in time	Retried automatically. A FortiManager that is consistently slow is worth checking
<operation>: <n> of <m> operations failed - <url>: <code> <message>	FortiManager refused the request with a code the Connector has no specific reading for. -9001 is a value FortiOS cannot hold, such as a name over 79 characters; -10015 an object something still references; -3 an object or path that does not exist	Read FortiManager's own message. A code that means FortiManager was busy is retried; the rest fail the Group until the cause is fixed
FortiManager task <id> (<title>) failed in state <state> with <n> error(s): <device>(<vdom>): <detail>	An install the Connector ran failed on FortiManager or on the device. For a reason that will not pass on its own, the Group's job completes with the failure in its summary as Install failed: ...; for one that may, such as a device that did not answer, the job is retried with the message above	Read <detail>, which is FortiManager's own task line. Fix the cause and install the package yourself, or change the Group to trigger another sync
<n> addresses were left out of this group's FortiManager address groups because FortiOS cannot hold them as an address object: <addresses>. The other members are in sync.	A note on a Complete job: those addresses of the Group are not a bare IP, a CIDR or a range whose start is not above its end, or are IPv6 ranges whose object name would pass FortiOS's 79-character limit	Correct or remove those addresses in the Group. The rest of the Group is exported
This group was deleted in Connect. Its FortiManager address groups and their member objects were left in place. ...	A note on a Complete job: the Group is gone and its objects were retained	Delete them in FortiManager once no policy references them
No policy references this group's new FortiManager address group yet, so it has no effect on any FortiGate. ...	A note on the Complete job that created the group: it is in the ADOM, but nothing uses it yet	Reference the group from a policy and install that package once. See Use the group in your policy
Install skipped: <package> to <device> (<vdom>): preview carries changes this sync did not make: <entries>	A line in a Complete job's summary: the account installs after a sync, but the package also holds changes Connect did not make, so the Connector left the install to you	Install the package yourself once those changes are meant to go out. See Installing policy packages
Install: no policy package references the synced groups	A line in a Complete job's summary: the account installs after a sync, but no policy uses the groups this sync checked, directly or through a group that contains them, so there was nothing to install	Nothing, unless a policy was meant to reference the group
Install: no device is assigned the referencing packages (<packages>)	The packages that use the changed groups are not assigned to any device, and have never been installed to one	Assign the package to its device in FortiManager and install it once yourself
Install: nothing changed, so no package was installed	The account installs after a sync, but this sync changed no group's members or addresses, and no Group was checked for a pending install: the jobs are not retries, or the Groups have no address group in FortiManager yet. On a job the Connector closed after a restart, its background install check found no policy referencing the account's groups	Nothing
Install: nothing changed, and no package holds changes awaiting installation	A line in a job's summary, covering every Group of the account synced in the same batch: no group's members or addresses changed (a rename may still have rewritten a comment), at least one Group was checked for a pending install because its job is a retry, the Connector had just started, or an earlier sync left it a pending install to check, and no package in the ADOM holds changes awaiting installation	Nothing
Install: the referencing packages (<packages>) hold no changes awaiting installation	A line in a job's summary, covering every Group of the account synced in the same batch: no referenced group's members or addresses changed, and the packages that use those Groups' groups show Installed on every device they have been installed to. A device a package is assigned to but has never been installed to is left for you to install the first time	Nothing, or install the package once to a device it has never been installed to
Install: the referencing packages were installed while this sync waited, so none was installed again	A line in a job's summary: the packages that awaited an install for the account's groups were installed by another job, or by someone in FortiManager, while this sync waited for its turn. Seen mostly on a job the Connector's background install check closed after a restart	Nothing
Install: could not resolve the packages to install: <reason>	The Connector could not read where the Group's groups are used or where their packages are installed. The groups are correct in the ADOM. When the reason may pass, such as a FortiManager that did not answer in time, the Group's own job is retried with the error above; sibling jobs of the account complete with this line	Read <reason>; it is one of the messages above. Install the package yourself, or change the Group to trigger another sync
Install skipped: <package> to <device> (<vdom>): preview carries none of this sync's objects	FortiManager rendered nothing for that device, so there was nothing to install there	Nothing. The package's pending changes reach only its other devices, or the package does not use these groups on that device
Install skipped: <package> to <device> (<vdom>): Another session holds the workspace lock on ADOM '<adom>' ... so the install was not attempted.	A line in a job's summary: the objects are committed, and another session held the ADOM lock when the install was due. The Group's own job retries the install when the package had been installed to that device before; for a device it was never installed to, the job completes, since the first install there is yours. Sibling jobs of the same account show the line too	Nothing while a job retries. Otherwise install the package yourself once
Install skipped: <package> to <device> (<vdom>): Another of the Connector's jobs is working in ADOM '<adom>' of Fortinet FortiManager at <host>, so this install was not attempted.	A line in a job's summary: another job of the Connector's was installing in the same ADOM, or, with workspace mode on while the Connector's background install check runs after a restart, reading and writing there. The Group's own job is retried when the package had been installed to that device before, with the error The install of ... did not complete: Another of the Connector's jobs is working ...; for a device it was never installed to, the job completes, since the first install there is yours. Sibling jobs of the same account show the line too	Nothing while a job retries. Otherwise install the package yourself once
Install skipped: <package> to <device> (<vdom>): installing was turned off for this account	Install policy packages after a sync was turned off while the sync was installing, so the Connector previewed and installed nothing more	Nothing. Install the package yourself when the change should go out
Install skipped: <package> to <device> (<vdom>): Connect could not confirm that installing is still turned on for this account, so the install was not attempted (<reason>)	A line in a job's summary: before each preview the Connector reads the account's settings back from Connect, and that read failed. The Group's own job is retried when the failure may pass and the package had been installed to that device before; for a device it was never installed to, the job completes. Sibling jobs of the same account show the line too	Usually nothing; a retry reads it again. If it persists, check the Connector's connection to Connect
FortiManager task <id> (<title>) is waiting for an operator (state <state>); continue or cancel it in FortiManager	An install the Connector ran stopped on a prompt only a person can answer in FortiManager's task monitor	Continue or cancel the task there

Infoblox

Message	What it means	What to do
Cannot reach Infoblox host <host>	The grid didn't answer at all	Check Host Address on the Provision page, and that the Connector can reach the grid on TCP 443. Retried automatically
Failed to auto-negotiate Infoblox WAPI version: <reason>	The host answered, but not as a WAPI version Connect can use. The host is reachable, so this isn't a network problem. <reason> is the host's own answer: a <host> answered HTTP <status> ... sentence is the address not serving the WAPI at all, worded as in Failures from the read itself	For a <host> answered HTTP <status> ... reason, set Host Address to the Grid Master; a Grid Master Candidate or other member answers this way. Otherwise check the grid's WAPI version. Wrong credentials report an authentication failure instead, not this message. Pressing Test on the Provision page reports the same reason without waiting for a run
Infoblox discovery incomplete: <n> items uploaded, <m> networks could not be fetched. The next attempt continues where this one stopped.	The run couldn't read every network, so its results are partial. The last sentence appears only when something was uploaded	Retried rather than failed. What was read stays, cleanup waits, and the retry carries on from where the run stopped. If it repeats with nothing uploaded, the grid is refusing some reads
Infoblox at <host> is refusing requests from the API user with HTTP <status>; <n> items were uploaded before the run stopped.	The grid is up and rejecting this user's reads. The message ends with what to check: the API user's permissions on a 403, otherwise the host	On 403, check the API user's permissions. Otherwise confirm the host is the Grid Master and that its WAPI serves this user
Infoblox at <host> refused the bulk request handler with HTTP <status>, and the host did not report read-only API access; <n> items were uploaded before the run stopped. Point the account at the Grid Master, or check the API user's request handler and Grid Member permissions.	The grid rejected the request handler discovery reads through, and the member that answered didn't say it has read-only API access, which is the one case discovery works around by reading networks one at a time	Set Host Address to the Grid Master, or check the API user's permission to use the WAPI request handler and to read Grid Member objects. A Grid Master Candidate with read-only API access is read one network at a time once the API user can read Grid Member objects
Infoblox at <host> answered for no network: <n> networks were uploaded as their CIDR only. Check the API user's permissions.	Every network came back as a CIDR alone, the shape an API user without address permissions sees	Check the API user's permissions. Retried rather than failed
Infoblox at <host> paused at the 12-hour run budget: <n> of <m> networks fetched this cycle. The next attempt continues where this one stopped.	The attempt reached its 12-hour limit while the grid was not returning addresses for the networks it was asked about. What was read earlier stays	The job retries on its own and carries on from where it stopped. If it repeats, look at what the grid is refusing to read; the Test button on the Provision page says what it answers
Infoblox at <host> fetched nothing more within 12 hours: <n> of <m> networks fetched this cycle, <k> were not fetched in time.	A whole 12-hour attempt passed without reading one more network. Networks read earlier in the cycle stay, and the next scheduled run carries on from there	Check that the grid answers reads at all; the Test button on the Provision page says. Repeated failures are worth raising with FireMon Support

A network whose addresses couldn't be read during a run that otherwise finished is kept as its CIDR and counted in the job Summary as with errors, not reported as a job error. A Summary ending in cleanup skipped means stale networks were deliberately left in Inventory. Both are covered in Infoblox: Details and edge cases.

What the Infoblox test says about bulk reads

After signing in, the test asks the grid which member owns the address, then sends one bulk read, the kind discovery depends on, and ends its Sign-in and read message with the answer. The member sentence reads Could not tell which member answered. (<reason>) when the API user can't read Grid Member objects, which is informational and never fails the test. A refused bulk read doesn't fail the test either, since the sign-in worked. What the first discovery run does with it depends on the member sentence, and the ending says which: when the sentence names a Grid Master Candidate with read-only API access on, the message ends so discovery fetches networks one at a time. and the run reads the grid that way, which takes hours on a large grid; otherwise it ends so discovery cannot use bulk requests on this host. and a run through the Connector stops at its first bulk read with the refused the bulk request handler error above. Fixing that before the run saves the wait. An account with no Connector is tested from the cloud, and its test ends so discovery fetches networks one at a time. after any refusal.

Ending	What it means	What to do
The grid accepts bulk requests.	The host is serving the full WAPI	Nothing. Discovery will run as described
The grid refused the bulk request handler with HTTP <status>, so discovery fetches networks one at a time.	The member sentence already named a Grid Master Candidate with read-only API access on, which refuses every bulk read by design, so discovery reads this member one network at a time. (Allow: <methods>) follows the status when the grid sends that header	Expect a long run on a large grid; the job pauses and retries on its own until the grid has been read in full
The grid answered the bulk request handler with HTTP 405 (Allow: GET): POST is not accepted, as on a member with read-only API access, so discovery cannot use bulk requests on this host.	The host takes reads but not the bulk read, but didn't say so on the member read, which is how a Grid Master Candidate with Read Only API access answers when the API user can't read Grid Member objects. Allow: GET is the host's own statement of what it accepts	Set Host Address to the Grid Master, or give the API user read access to Grid Member objects so discovery can read this member one network at a time
The grid refused the bulk request handler with HTTP 403: the API user may not use it, or the host is a member with read-only API access, so discovery cannot use bulk requests on this host.	Either the API user lacks permission to use the WAPI request handler, or the host is a read-only member that the member read didn't identify	Check the API user's permissions in Grid Manager, and that Host Address is the Grid Master
The grid answered the bulk request handler with HTTP 404: no /request handler is served at this address, so discovery cannot use bulk requests on this host.	The host has no bulk handler at the negotiated version, and the member read didn't identify it as a read-only candidate	Confirm Host Address is the Grid Master and that nothing in front of it rewrites paths
WAPI v<version> has no bulk request handler, so networks are fetched one at a time.	The grid's WAPI predates 2.5. Discovery still works, one network at a time	Nothing, unless the grid is large; then expect a long run
Could not tell whether the grid accepts bulk requests. (<reason>)	The bulk read didn't get a clear answer, for the reason quoted, usually a timeout	Test again. If it repeats, the first run will report what the grid does

Cloud integrations

These integrations run from the cloud rather than through the Connector. Discovery errors appear under Resource Errors on the account's Provision page, one per resource type and region. Most of the text comes from the vendor's own API. The messages below are Connect's own.

Exports behave differently. A decommission export records its error, and hovering the tag in History shows it. A change request export or withdrawal records its outcome on the request's Exports tab, with the error when it fails and, for the messages below that Connect recognizes, what to do; the request's state is the same either way.

Message in Exports	What it means	What to do
the credentials could not be read: <reason>	Connect couldn't read the target account's saved credentials	Re-enter them on the account's Provision page and save the request again
the account has no saved credentials	The target account has nothing saved	Provision the account, then save the request again
the rule addresses could not be resolved: <reason>	Looking up the members of a Group or inventory item failed	Save the request again. If it repeats, contact FireMon Support
provider <provider> has no change request export	A Boundary targets an account whose integration doesn't take change requests	Remove the account from the Boundary's Target(s), then save the request again
the export threw: <reason> or the withdrawal threw: <reason>	The target refused the write, for the reason quoted	See the target's section below

Infoblox without a Connector

An Infoblox account with no Connector selected is discovered from the cloud. Besides the Infoblox messages that apply to any run, its Resource Errors can show these. Each one stops discovery for the run and holds cleanup, so nothing is removed from Inventory.

Message	What it means	What to do
Infoblox listed no networks; check the host and the API user's permissions and network views. Inventory cleanup is held.	The grid returned no networks at all, which is how a user who can't see them, or a host that isn't the grid, answers	Check Host Address, and the API user's permissions and network views
Infoblox grid stopped answering; <n> of <m> networks on this page were not fetched: <reason>	The grid stopped responding partway through	Check that the grid is up and reachable from the internet. The next daily run tries again
Infoblox is refusing requests from the API user with HTTP <status>; ... or Infoblox is refusing the bulk request handler with HTTP <status>; ...	The grid is up and rejecting this user's reads, or the bulk read discovery uses	On 403, check the API user's permissions. Otherwise confirm Host Address is the Grid Master

Azure

Message	What it means	What to do
No matching federated identity record found for presented assertion (an AADSTS70021 or AADSTS700213 message)	Azure found no federated credential matching the token Connect presented	Tenant ID or Client ID on the Provision page doesn't match the identity the provisioning command created, or the CloudDefense federated credential was removed. Correct the IDs, or run the provisioning command again. See Azure
The client '<id>' with object id '<id>' does not have authorization to perform action '<action>' over scope '<scope>' or the scope is invalid. (AuthorizationFailed)	The identity signed in but holds no role for that action	Run the provisioning command again, which restores the role assignment. For Group export, the account must have been created with Read & Write
Failed to get encrypted account credentials	The account's stored credentials couldn't be read. Any cloud export can report this	Re-enter them on the Provision page and save

The first two appear under Resource Errors on the account's Provision page. For an export, the same problems leave the IP Group missing in Azure. Connect stops exporting a Group that has grown past 5,000 entries, and its IP Group keeps its previous contents. An IP Group a firewall rule still references stays in Azure when its Group is deleted. See Integration troubleshooting.

Guardicore

These come from checking a change request before export. Any one of them cancels the export, so none of the request's rules reach Guardicore. Rules an earlier export left there are withdrawn: each is disabled, or deleted when Guardicore can no longer express it or the request no longer has that rule. The request's Exports tab shows the message after the export threw:, followed by the reason when the withdrawal failed too. The credentials message is the exception: Connect can't sign in, so Guardicore is left as it is.

Message	What it means	What to do
Rule <id>: negated sources/destinations are not supported by Guardicore policy rules. Guardicore only supports negation on label-based exclusions, not CIDRs.	A rule uses NOT on a source or destination	Rewrite the rule without negation, then evaluate it again
Rule <id>: its sources resolve to no addresses, which Guardicore would read as any address. Check the rule's Groups and inventory items.	The rule's sources name no CIDR and no Any, and every Group or inventory item among them holds no addresses, or the rule names no sources. Destinations report the same way	Add members to the Group, or name a CIDR, then evaluate it again
Rule <id>: custom protocol (<protocol>) is not supported by Guardicore. Guardicore only supports TCP, UDP, and ICMP.	A rule names an IP protocol by number	Express the rule in TCP, UDP or ICMP terms, then evaluate it again
Rule <id>: PortRangeSize is a Connect-side boundary concept and has no Guardicore equivalent.	A rule uses a Max Ports service, which belongs in a Boundary rather than a request	Replace it with specific ports
Rule <id>: no services defined. At least one protocol/port is required.	A rule has no services	Add at least one service to the rule
Rule <id>: ICMPv6 cannot be expressed in Guardicore, whose ICMP matching is IPv4 only.	A rule uses an ICMPv6 or All ICMPv6 service	Leave ICMPv6 out of requests bound for Guardicore
Rule <id>: port 0 is not accepted by Guardicore. Ports run from 1 to 65535.	A TCP or UDP service starts or ends at port 0	Start the port or range at 1
CR <id> has no rules to export	The change request has no rules	Add rules to the request
CR <id> has a rule without an id. Save the request again to assign one.	The request was saved before Connect gave each rule an id	Open the request and save it
Guardicore credentials for CR <id> are missing a hostname, username or password	The target account's saved credentials are incomplete	Correct the credentials on the account's Provision page, then save the request again

ServiceNow

These come from saving the Provision page or from an export; both create the staging tables when they're missing and add any columns an existing table lacks. A failure while saving still lets the save succeed, so the first sign is usually a missing staging table, or rows that fail to arrive. A decommission export shows its message under Decommission > History; a change request export shows it on the request's Exports tab.

Message	What it means	What to do
Could not resolve sys_import_set_row sys_id.	Connect couldn't read the table that staging tables are built from	The application user can't read sys_db_object. Give it a role that reads it, such as itil, asset or sn_change_read, then save the Provision page again
Staging table creation did not return a sys_id.	ServiceNow didn't confirm the new staging table	Check for u_connect_change_requests_staging and u_connect_decommissioned_assets_staging under System Definition > Tables. See ServiceNow
ServiceNow rejected a dictionary change for <table> (status <status>): <body>	The staging table exists, but a column couldn't be added or widened	Usually the application user lacking personalize_dictionary. Correct its roles, then save the Provision page again
ServiceNow Batch API left <n> of <m> import rows unserviced for <table>, having hit its size or time limit. The others were processed. and the same for dictionary changes	ServiceNow stopped part-way through a batch of rows or columns	Try again. Rows it did load are in the staging table, so for an export coalesce in the transform map first
Staging table setup did not finish within 20 seconds. The next save or export finishes it.	The instance was slow while the Provision page was saved	Nothing, unless it repeats. Columns still missing are added by the next save or export
ServiceNow rejected an import row for <table> (status <status>): <body>	The Import Set API refused a row. A 403 is an application user without import_admin or import_transformer; a 400 names a staging table that doesn't exist	Fix the account's roles, or save the Provision page again to recreate the table
ServiceNow did not answer as the Batch API when sent <n> import rows for <table>. Check the instance name. and the same for dictionary changes	Something other than the Batch API answered, such as a proxy or sign-in page. Nothing was loaded	Instance Name is the subdomain, such as acme. A pasted https://acme.service-now.com is reduced to it; any other domain is not an instance name
ServiceNow answered <n> of <m> import rows for <table> and did not account for the rest. and the same for dictionary changes	The Batch API answered for some of the rows or columns and said nothing about the others, which it does not do on its own	Try again. Rows it did load are in the staging table, so for an export coalesce in the transform map first
ServiceNow answered an import row for <table> with status <status> but not with an Import Set result: <body>	Something other than the Import Set API answered a row, such as a proxy or sign-in page	Check Instance Name, as for the Batch API message above
ServiceNow loaded <n> row(s) into <table>, but no active transform map has that table as its source, so the rows stay there.	The rows are in the staging table, and ServiceNow ran no map on them	Create the map as the ServiceNow page says, with the staging table as its Source table. For a change request, save it again. A retry loads the rows again, so coalesce first. An earlier version of Connect reported this as a transform error with the message Invalid table
ServiceNow loaded <n> row(s) into <table> but reported <m> transform error(s): <message>	The rows are in the staging table, but a transform map failed on them. ServiceNow's message names the cause, such as Invalid table <name> for a map whose target table doesn't exist	Fix the map's target table, field maps or script. For a change request, save it again. A retry loads the rows again, so coalesce first
ServiceNow credentials for CR <id> are missing an instance name, client id or client secret	The target account's saved credentials are incomplete	Correct the credentials on the account's Provision page, then save the request again

Illumio

Message	What it means	What to do
GET <path> returned <value> (<type>) for X-Total-Count header, GET <path> returned invalid total <value> for X-Total-Count header	The PCE's response was missing the item count Connect needs to page through results	Confirm API URL ends in /api/v2/. Without the path, something other than the PCE answers
response-async response is missing the Location header	A large read (more than 500 workloads) didn't start properly	Let the next discovery run. Contact FireMon Support if it persists

Security Manager

Message	What it means	What to do
SIP registration not found for client <id>	Security Manager isn't registered with FireMon Insights, so Connect has no route to it	Complete Connect Your SIP Instance. Discovery resumes on its own

Pairing and starting the Connector

Message	What it means	What to do
Missing registration code	Pairing was attempted with no code	Enter the code from Settings > Connectors
Invalid or expired registration code	The code doesn't exist, has been used already, or is more than 24 hours old	Generate a new code under Settings > Connectors and pair again
Too many attempts. Try again later.	Too many pairing attempts came from one IP address	Wait, then try again with a code you have confirmed
Failed to register: <message>	Connect rejected the pairing request. <message> is the reason	A bad or already-used code needs a new one. During first boot, a server error is retried on its own while the appliance finishes getting an address
Registration failed. Check the code and try again, or press Ctrl+C to restart the wizard.	The console wizard's version of the same failure	Re-enter the code, or generate a new one
Registration response missing apiKey or connectorId	Pairing was accepted but the response was incomplete	Pair again. Contact FireMon Support if it happens twice
Credentials file <path> is missing; pair the connector via the console wizard.	The Connector started as a service without being paired	Pair it. On the appliance, use the console menu
Credentials file <path> is invalid (<reason>); quarantined — re-pair via the console wizard.	The credentials file can't be read as credentials, and has been set aside	Pair again with a new registration code
Credentials file <path> is unreadable (<reason>); fix its ownership/permissions so the firemon-connector user can read it, or re-pair via the console wizard.	The file is there, but the account running the Connector can't open it	Correct the file's owner and permissions, or pair again
Cannot write credentials to <dir>: <reason>. Run as root, or set FIREMON_CONFIG_DIR to a directory you can write. The registration code was not used.	The account running the Connector can't write the directory it stores credentials in. The Connector checks this before it sends the code, so the code is still good	Run it with sudo, or point FIREMON_CONFIG_DIR at a directory you can write, then pair with the same code
Cannot create credentials directory <dir>: <reason>	The Connector couldn't create the directory it stores credentials in	Give the account running the Connector write access to the parent directory
Another connector instance is running (<path>). Stop it, then start the connector again.	A second Connector is already running from this installation	Stop the other one. Two Connectors sharing an identity make jobs stall and restart. See Run one Connector per identity
Another connector instance is running (<path>). Waiting for it to exit.	The same, but this Connector is waiting rather than exiting	As above. It starts as soon as the other one stops
Another connector instance is running. Waiting up to <n>s for it to exit..., Another connector instance is running. Waiting for it to exit...	Expected while the Connector updates itself and the new version waits for the old one	Nothing, unless the message keeps repeating

Connectivity check

firemon-connector --check-connectivity tests DNS and TCP 443 against every endpoint the Connector uses.

Message	What it means	What to do
DNS resolution failed	The hostname didn't resolve	Your resolver is unreachable, or *.firemon.cloud isn't permitted. See Network Requirements
timeout after 5000ms	The name resolved, but the connection never completed	An egress firewall is dropping the traffic rather than refusing it
One or more checks failed.	The summary line, shown whenever any endpoint failed	Read the per-endpoint lines above it. If the API passes and the WebSocket fails, WSS is blocked on its own

Connector updates

These appear in the Connector log. A failed update is discarded, and the Connector carries on running its current version.

Message	What it means	What to do
Release signature verification failed — update rejected	The download isn't a genuine release	Contact FireMon Support. Repeated failures suggest the download is being intercepted
Checksum mismatch: expected <a>, got <b>	The download doesn't match its published checksum, usually because a proxy altered or truncated it	Retried at the next update check
Download failed: <status> <text>	The release couldn't be downloaded	Confirm the Connector can reach the updater endpoint. See Network Requirements
Download stalled: no data for 60000ms	The download started and then stopped sending data, usually a proxy holding the connection open	Retried at the next update check

Saving a Boundary or change request

Validation failures arrive together, in one message:

This request is invalid and contains the following errors:
* Name is required
* Invalid Source CIDR or IP: 10.0.0.300

Message	What it means	What to do
Name is required	The Boundary or change request has no name	Enter one
A score (0-100) is required	The Boundary's action is Score, but the score is missing or outside 0-100	Enter a score in range
Invalid Source CIDR or IP: <value>	A source is neither a valid IP address nor a valid CIDR. Destinations report the same way	Correct the value
Source cannot be The Internet. Use specific CIDRs, groups or inventory items in a change request.	The Internet belongs in a Boundary, which judges addresses, not in a request, which states them. Destinations report the same way	Replace it with specific CIDRs, Groups or inventory items
Source mixes negated and plain objects. Negate all of them or none.	Some of the rule's sources use NOT and others don't, which an export cannot state as one list. Destinations report the same way	Negate every object on that side, or none of them
Invalid custom protocol: <value>	The IP protocol number is outside 0-254	Correct it
Invalid TCP port start: <value>	The port is outside 0-65535. UDP, and the end of a range, report the same way	Correct it
Invalid TCP port range: <start> to <end>	The first port is higher than the last	Swap them
Invalid ICMPv4 type: <value>	The ICMP type is outside 0-254. ICMPv6, and ICMP codes, report the same way	Correct it
sourcesMaxHosts should be undefined or greater than zero.	One of the statement's host or port limits is zero or negative. The other five limits report the same way, each naming its own field	Clear the field, or enter 1 or more
Invalid IP or CIDR: <values> on the form, or Invalid internal CIDR or IP: <values> from the API	An entry in your internal address space under Settings > Boundaries is not a valid IP or CIDR	Correct the entries listed and save again

A source, destination or service missing the field its type needs, such as a Cidr with no cidr or a TCP service with no ports, is answered with Internal Server Error. ID: <id> over GraphQL, or an empty 500 over REST, rather than a validation message. Send every field the schema lists for the type. The Connect app can't produce these.

Permissions and availability

Message	What it means	What to do
Connect is not enabled for client <id>	Your organization doesn't have Connect enabled	Contact FireMon Support
Resource lists are not enabled for client <id>	Your organization doesn't have Groups enabled. Some messages call a Group a resource list	Contact FireMon Support
Decommission workflows are not enabled for client <id>	Your organization doesn't have Decommission enabled	Contact FireMon Support
Change requests can only be updated by an admin, the original creator, or the last updater.	You didn't create or last change this request, and you aren't an administrator	Ask its creator, or an administrator, to make the change
Change requests can only be deleted by an admin, the original creator, or the last updater.	The same rule, applied to deleting	As above
The update type and project of a decommission workflow cannot be changed.	Update and Project are fixed when a workflow is created	Create a replacement workflow with the values you want, then delete the original
Unauthorized	Your roles don't cover this action in this project	See Users and roles
Permission denied	Approving or rejecting a Decommission candidate without the role to do it in that project	See Users and roles
Credentials are only accessible by administrators.	Group Credentials can be viewed only by an administrator	Ask an administrator
Credentials can only be modified by administrators.	The same, applied to changing them	As above
Error getting permissions: <message>	The app couldn't load your permissions	Reload the page. If it persists, sign out and back in
Missing ID token	Your session has expired	Sign in again

Not found

These mean the item is gone, or was never there. A browser tab left open while someone else deleted the item is the usual cause. Reload the page, then check whether the item still exists.

Message	Shown when
Boundary not found	Opening or deleting a Boundary
Change Request not found	Opening, evaluating or deleting a change request
Resource list not found, List not found	Opening, saving or deleting a Group
Nested resource list not found	Removing a nested Group that has already gone
Resource list member change candidate not found	Applying a pending membership change that has already been applied
Resource list member change candidate action of <a> does not match the specified action of <b>	Applying a pending change that has changed since the page loaded
Workflow not found, Decommission Workflow <id> not found	Opening, saving or deleting a decommission workflow
Match not found	Acting on a decommission candidate that has already gone
Client settings not found	Reading settings your organization has never saved

Dynamic list URL

Errors returned by the URL that serves a Group's addresses to a firewall. See Dynamic lists.

Message	What it means	What to do
Not Found	The URL isn't in the expected form	Copy it again from the Group's page
List not found	The URL is well-formed, but names a Group that no longer exists	Copy the current URL from the Group's page
Missing Authorization header	The request carried no credentials	Send HTTP basic authentication
Missing password or API Key in Authorization header	A username was sent with no password	Send both
Missing username in Authorization header	A password was sent with no username, and it isn't a valid API key	Send both
Invalid API Key	The API key belongs to a different organization	Use a key from the organization that owns the Group
Invalid credentials	Neither the API key nor the username and password matched	Check the credentials under Settings > Group Credentials, or use an API key as the password with the username shown on the Group's page

In the Connect app

Form validation names the field it applies to.

Message	What it means
<Field> is required	A required field is empty, named by its own label: Password is required, Connector is required, Tenant ID is required, and so on
Name must be less than 128 characters	The account name is too long
Provider is required, Project is required	Both are set when the account is created, under Integrations
<Label> Required, such as AWS Account ID Required	The system's own identifier is missing on New Account
AWS Account ID must be 12-digit number, such as 123456789012.	The AWS account ID isn't 12 digits
Azure Subscription ID must be a valid UUID/GUID that is 36 characters long, including hyphens.	The subscription ID isn't a GUID
Already added as "<name>". Provisioning it again would deprovision that account.	Another account already has this AWS Account ID or Azure Subscription ID. Each can be added only once; open the existing account instead
Use the region's short name, such as westus2 or eastus, not its display name., Invalid Default Region '<region>'. Use the region's short name, such as westus2.	Default Region on an Azure Provision page is a display name such as West US 2
Select Import, Export or both.	Both checkboxes on a ServiceNow or Guardicore Provision page are clear
Enter a valid email address	The Email on Invite User isn't an address

Password, secret and token fields are never shown back to you, so they're empty each time the Provision page opens. Leave one blank to keep its saved value. Password is required only appears while the account has no saved credentials yet. Once something has been saved, the field's hint reads Not shown after saving. Leave blank to keep it.

Messages shown at the top of the page:

Message	What it means	What to do
Error saving	The account couldn't be saved, and no reason was returned	Check the form for a validation message, then try again
There was an error deleting the account	The account couldn't be deleted	Reload the page and try again
Error deleting <name>: <detail>	A delete failed. <detail> is the reason	Act on the reason given
Error updating decommission candidate.	A decision on a candidate wasn't saved	Reload the page and try again
Decommission candidate updated, but some details failed to refresh. Reload the page to see the latest status.	The decision was saved. Only the display failed to update	Reload the page. Nothing was lost
Failed to save <n> nested group changes	Some nested Group changes weren't saved. The rest of the Group was	Reopen the Group and check its nested Groups
Error(s) encountered while applying changes: <n>	Some pending membership changes couldn't be applied	Reload the page and apply the ones still listed
Error loading more members., Error loading more matches., Error loading more changes.	The next page of a table didn't load. What's already shown is still accurate	Scroll again, or reload the page
Could not read the selected file as a boundaries JSON export.	The file isn't a Boundaries export	Use a file produced by Export on the Boundaries page
Please select one or more pre-defined filters or enter your own search term before saving.	A saved search can't be empty	Add a filter or a search term
Choose a project for each role before saving.	A role was assigned without a project	Choose a project for each role
Failed to save search. Please try again., Failed to delete saved search. Please try again., Failed to set default saved search. Please try again.	A change to your saved searches wasn't stored	Try again
There was an error loading settings: <detail>	The Boundaries settings page couldn't load	Reload the page
There was an error saving settings: <detail>, There was an error resetting settings: <detail>	The Boundaries settings couldn't be saved or reset	Act on the reason given
Error updating decommission candidates.	A bulk decision on candidates wasn't saved	Reload the page and try again
Decommission candidates updated, but the list failed to refresh. Reload the page to see the latest status.	The decisions were saved. Only the list failed to update	Reload the page. Nothing was lost
There was a problem updating this account, please retry the instructions above or contact support.	The Provision page couldn't save	Check the form for a message, then save again
Configuration not saved. with The configuration is incomplete, so nothing was saved. Fill in every required field and try again.	The Provision page sent a configuration with a required value missing or blank. Connect stored nothing, and the fields keep what you typed	Fill in every required field, then save again
Configuration not saved. with The save went through, but the configuration was not stored. Check that every required field has a value and try again. If it keeps happening, contact support.	Connect accepted the save but stored no configuration, so the account is still unprovisioned	Check every required field and save again. If it keeps happening, contact FireMon Support
There was a problem verifying access to this account, please retry the instructions above or contact support., Unable to verify access to this account. Please review the instructions and try again. If you're still experiencing issues, please contact support.	Verify Account Access on an AWS account failed	Confirm the stack finished, then verify again. See AWS
Missing account provisioning info. Contact FireMon support.	Connect couldn't build the provisioning template for this AWS account	Contact FireMon Support
Account not found or unavailable.	The Provision page was opened for an account that no longer exists, or one outside your projects	Return to Integrations
CSPM Lite clients cannot create new accounts with the 'events only' policy code.	Events Only isn't available to your organization	Choose another access level
There are already <n> accounts, which matches your current limit of <n> accounts., Cannot add another account, max reached: <n>. Please contact your sales representative for more information.	Your organization is at its account limit	Delete an account, or contact your sales representative
Could not read the saved credentials for this account. Enter them again.	A save left a secret blank and the stored one couldn't be read	Enter the secret and save again
<Role> on <project> is already assigned.	The role row duplicates one the user already has	Remove the duplicate row
Error removing role: <detail>, Error deleting user	A change on the Users page wasn't saved	Act on the reason, or reload and try again
Unable to create user. A user with that username already exists., An account already exists with the username: <username>	The username is taken	Choose another username

When importing a CSV on the Integrations page, each row that can't be used lists its reasons:

Message	What it means	What to do
No ID	The row has no identifier	Choose the right Unique ID Column, or fill the value in on the row
No IPs	The row has no addresses	Choose the right IP Column. Several addresses in one cell can be separated by spaces, semicolons or pipes
No Region	The row has no region	Set a fixed Location / Region, or choose a column that has a value on every row
<n> of the rows below could not be uploaded.	Rows passed the checks above but were rejected on upload. Each one shows its reason under Details	Correct those rows and import the file again. Rows that uploaded aren't affected

Still stuck

Note the exact message, the job or account it came from, and roughly when it happened, then contact FireMon Support. Connector logs are forwarded to FireMon Support, so they can usually see the full error without you collecting files. See Security & Data Protection.