> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/outpost-troubleshooting.md).

# Outpost troubleshooting

This document provides solutions for issues that might occur while deploying, configuring, and operating Cortex Cloud outposts. These troubleshooters can help identify symptoms, locate errors, and suggest how you can remediate.

## General troubleshooting

These general troubleshooters apply to all cloud service providers and outpost deployment modes.

**Terraform executes successfully but no outpost appears in Cortex**

After a successful Terraform run, your cloud environment sends a notification to Cortex to register the new outpost. If the outpost doesn't appear in the Cortex console, verify that outbound internet connectivity is available from the environment where Terraform was executed. The notification requires an active connection to reach Cortex. If connectivity is confirmed and the outpost still doesn't appear, contact customer support for a manual workaround.

**Terraform template execution fails on a non-approved tenant, such as after changing the target tenant mid-deployment**

If Terraform execution fails on a non-approved tenant, such as if you change an Azure target tenant after starting outpost creation. Terraform execution fails because the outpost is bound to the originally-approved tenant. Delete the partially-created outpost from the Cortex console, revert to the approved tenant, and re-run the Terraform template.

## Standard outpost troubleshooting

Standard outposts handle most of the infrastructure and identity provisioning automatically. Issues in this deployment mode might stem, for example, from broad permission gaps, restrictive policy definitions, or quota limits that prevent Cortex from deploying necessary resources.

## Bring your own app (BYOA) troubleshooting - Azure

This section details common deployment and runtime errors that occur when a Bring Your Own App (BYOA) Azure outpost is configured. These errors might appear, for example, if the app registration, service principal, and user-assigned managed identities (UAMIs) were created manually via the Azure portal instead of using the provided helper script.&#x20;

Use the following table to identify symptoms and apply the appropriate resolutions.

<table><thead><tr><th>Symptom / error message</th><th width="130.47265625">Terraform deployment phase</th><th>Resolution</th></tr></thead><tbody><tr><td><strong>Single-tenant app registration</strong><br><br><em>Error:</em> <code>... sign_in_audience must be 'AzureADMultipleOrgs' ...</code></td><td>Plan</td><td>Recreate the app registration as a multi-tenant application.<br><br>The Azure portal defaults to single-tenant ("this org only").<br><br>Run this command:<br><br><code>az ad app create --display-name &#x3C;name> --sign-in-audience AzureADMultipleOrgs</code></td></tr><tr><td><strong>Incorrect service principal ID</strong><br><br><em>Error:</em> <code>... customer_sp_object_id ... is the SP of a different AppReg ...</code></td><td>Plan</td><td>An incorrect service principal object ID was provided.<br><br>Retrieve the correct ID by running:<br><br><code>az ad sp show --id &#x3C;CUSTOMER_APP_CLIENT_ID> --query id -o tsv</code><br><br>Update the <code>customer_sp_object_id</code> variable in your <code>tfvars</code> file.</td></tr><tr><td><strong>Missing Terraform runner ownership</strong><br><br><em>Error:</em> <code>Warning: The Terraform runner ... is NOT listed as an owner of the BYO App Registration ...</code></td><td>Plan</td><td>The Terraform runner must be added as an owner of the app registration.<br><br>Without this, the deployment fails with an "Insufficient privileges" error when attempting to create the first federated identity credential (FIC).<br><br>Run:<br><br><code>az ad app owner add --id &#x3C;APP_ID> --owner-object-id &#x3C;TF_RUNNER_OBJ_ID></code></td></tr><tr><td><strong>Disabled service principal</strong><br><br><em>Error:</em> <code>... Customer SP ... is disabled in Entra ...</code></td><td>Plan</td><td>The service principal is disabled.<br><br>Re-enable it by running:<br><br><code>az ad sp update --id &#x3C;SP_OBJ_ID> --set accountEnabled=true</code><br><br>Alternatively, toggle it in the Azure portal under <strong>Enterprise applications</strong> > <strong>[Your SP]</strong> > <strong>Properties</strong>.</td></tr><tr><td><strong>Cross-subscription UAMI</strong><br><br><em>Error:</em> <code>... Customer UAMI ... lives in subscription &#x3C;X> but the outpost is being deployed to &#x3C;Y> ...</code></td><td>Plan</td><td>Cross-subscription UAMIs are not supported because the Azure Instance Metadata Service (IMDS) only returns tokens for local identities.<br><br>Recreate the UAMI in the outpost's subscription and update <code>customer_uami_*_id</code> in your <code>tfvars</code> file.</td></tr><tr><td><strong>Cross-tenant UAMI</strong><br><br><em>Error:</em> <code>... Customer UAMI ... lives in tenant &#x3C;X> but the outpost subscription is in tenant &#x3C;Y> ...</code></td><td>Plan</td><td>Cross-tenant UAMIs are not supported.<br><br>Recreate the UAMI in the correct Entra ID tenant to match the outpost subscription.</td></tr><tr><td><strong>Duplicate UAMI IDs</strong><br><br><em>Error:</em> <code>... All 5 customer UAMI IDs must be distinct ...</code></td><td>Plan</td><td>Duplicate UAMI IDs were provided.<br><br>The error message lists all 5 IDs.<br><br>Replace the duplicates with the correct, distinct UAMI IDs and rerun Terraform.</td></tr><tr><td><strong>Insufficient privileges for FIC</strong><br><br><em>Error:</em> <code>Error: creating Federated Identity Credential ... Insufficient privileges to complete the operation</code></td><td>Apply</td><td>App registration owner permissions are missing for the Terraform runner.<br><br>Verify ownership by running <code>az ad app owner list --id &#x3C;APP_ID></code>.<br><br>Add the owner by running:<br><br><code>az ad app owner add --id &#x3C;APP_ID> --owner-object-id &#x3C;TF_RUNNER></code></td></tr><tr><td><strong>Stale federated credential</strong><br><br><em>Error:</em> <code>Another object with the same value for property federatedIdentityCredentials/&#x3C;name> already exists</code></td><td>Apply</td><td>A stale FIC exists from a previous deployment attempt or manual portal entry.<br><br>List existing credentials using <code>az ad app federated-credential list --id &#x3C;APP_ID> -o table</code>.<br><br>Delete the conflicting one with <code>az ad app federated-credential delete --id &#x3C;APP_ID> --federated-credential-id &#x3C;NAME></code>.<br><br>Rerun the deployment.</td></tr><tr><td><strong>Subject does not exist (replication lag)</strong><br><br><em>Error:</em> <code>400 BadRequest: Subject does not exist in directory.</code></td><td>Apply</td><td>The UAMI was created very recently, and it has not yet replicated across Entra ID.<br><br>Wait 30 to 60 seconds and rerun <code>terraform apply</code>.<br><br>Verify the subject exists with <code>az ad sp show --id &#x3C;UAMI_PRINCIPAL_ID></code>.</td></tr><tr><td><strong>Accidental UAMI deletion</strong><br><br><em>Error:</em> <code>terraform destroy deleted my customer-created UAMIs!</code></td><td>Destroy</td><td>The UAMIs were incorrectly placed inside the outpost's Cortex-managed resource group.<br><br>Terraform deletes UAMIs placed inside the outpost's Cortex-managed resource group during a destroy operation.<br><br>Recreate the UAMIs in a customer-owned resource group outside of the outpost boundaries and re-onboard.</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/outpost-troubleshooting.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
