Microsoft.Insights is Registered, but diagnostic-setting creation returns HTTP 409 registration required

Mo 0 Reputation points
2026-10-23T21:53:48.9633333+00:00

I cannot create an Azure Container Apps environment diagnostic setting despite both required providers reporting Registered.

Environment:

  • Region: Germany West Central.

Source: Microsoft.App/managedEnvironments.

Destination: an existing Log Analytics workspace in the same subscription.

Microsoft.Insights and Microsoft.OperationalInsights both show Registered in CLI and Portal.

Workspace provisioning succeeded with 30-day retention.

Failing operation: PUT https://management.azure.com/subscriptions/<subscription>/resourceGroups/<group>/providers/Microsoft.App/managedEnvironments/<environment>/providers/Microsoft.Insights/diagnosticSettings/<setting>?api-version=2021-05-01-preview

Configuration:

logAnalyticsDestinationType: Dedicated.

Categories: ContainerAppConsoleLogs and ContainerAppSystemLogs.

No Storage Account destination or diagnostic-setting retention policy.

Observed:

Diagnostic-setting listing succeeds and returns zero settings.

Both requested log categories are recognized.

Creation failed through ARM deployment and direct REST.

After Azure CLI reauthentication and Management token acquisition, creation still returned HTTP 409.

Activity Log error: InvalidAuthenticationToken, “Please register the subscription '<redacted>' with Microsoft.Insights.”

Failure timestamp: 2026-10-23T21:11:56.9565986Z.

This targets Container Apps environment logs, not subscription Activity Log export. No further writes or registration changes are being attempted.

Could Microsoft help determine why registration is not recognized by this write operation, or identify another prerequisite? What escalation route is available with Basic support?I cannot create an Azure Container Apps environment diagnostic setting despite both required providers reporting Registered.

Environment:

Region: Germany West Central.

Source: Microsoft.App/managedEnvironments.

Destination: an existing Log Analytics workspace in the same subscription.

Microsoft.Insights and Microsoft.OperationalInsights both show Registered in CLI and Portal.

Workspace provisioning succeeded with 30-day retention.

Failing operation:
PUT https://management.azure.com/subscriptions/<subscription>/resourceGroups/<group>/providers/Microsoft.App/managedEnvironments/<environment>/providers/Microsoft.Insights/diagnosticSettings/<setting>?api-version=2021-05-01-preview

Configuration:

logAnalyticsDestinationType: Dedicated.

Categories: ContainerAppConsoleLogs and ContainerAppSystemLogs.

No Storage Account destination or diagnostic-setting retention policy.

Observed:

Diagnostic-setting listing succeeds and returns zero settings.

Both requested log categories are recognized.

Creation failed through ARM deployment and direct REST.

After Azure CLI reauthentication and Management token acquisition, creation still returned HTTP 409.

Activity Log error: InvalidAuthenticationToken, “Please register the subscription '<redacted>' with Microsoft.Insights.”

Failure timestamp: 2026-10-23T21:11:56.9565986Z.

This targets Container Apps environment logs, not subscription Activity Log export. No further writes or registration changes are being attempted.

Could Microsoft help determine why registration is not recognized by this write operation, or identify another prerequisite? What escalation route is available with Basic support?

Azure Container Apps
Azure Container Apps

An Azure service that provides a general-purpose, serverless container platform.

0 comments No comments

2 answers

Sort by: Most helpful
  1. kagiyama yutaka 5,740 Reputation points
    2026-10-24T02:28:13.7733333+00:00

    I think the missing check is the environment's actual log destination. Dedicated controls the Log Analytics table layout, not appLogsConfiguration.destination.

    bash az containerapp env show -g <RG> -n <ENV> --query properties.appLogsConfiguration.destination -o tsv

    azure-monitor is needed for diagnostic-settings log routing, but this 409 doesn't show that switching will fix the PUT. With writes still failing, leave the current routing unchanged.

    Basic doesn't include technical support. Add the sanitized 409 response, correlation ID, UTC timestamp, and current destination to this thread. An existing support entitlement can be used to open a technical case.

    Was this answer helpful?


  2. AI answer

    2026-10-23T21:55:11.62+00:00

    Set the Container Apps environment’s Logs Destination to Azure Monitor before creating the environment-level diagnostic setting; if it is already set, the contradictory Registered state and 409 response require Microsoft to investigate the subscription’s Microsoft.Insights control-plane registration.

    Required Container Apps configuration

    A diagnostic setting does not itself switch an environment from the legacy Log Analytics destination to Azure Monitor routing. The supported sequence is:

    1. Azure portal → Container Apps Environments → your environment.
    2. Select Monitoring → Logging options.
    3. Confirm Logs Destination is Azure Monitor.
    4. If it is not, select Azure Monitor, save, and wait for the environment update to complete.
    5. Select Monitoring → Diagnostic settings and create the setting.

    The equivalent CLI operation is:

    az containerapp env update \
      --name <ENVIRONMENT_NAME> \
      --resource-group <RESOURCE_GROUP_NAME> \
      --logs-destination azure-monitor
    

    Only after that update should the diagnostic setting route ContainerAppConsoleLogs and ContainerAppSystemLogs to the workspace. This two-step requirement is documented for Container Apps environments.^1^

    If the environment already reports azure-monitor, your request shape is supported: environment-scope settings, both named categories, Dedicated, and API version 2021-05-01-preview are valid.^2^^3^

    What the current evidence rules out

    Your tests already establish that:

    • Microsoft.Insights and Microsoft.OperationalInsights report Registered.
    • ARM and direct REST fail identically.
    • A fresh management token does not change the result.
    • The resource supports both requested categories.
    • The environment has capacity for another setting.
    • The destination already exists.

    Therefore, do not keep retrying authentication or changing the request between ARM and REST. If the logging destination is already azure-monitor, the next useful action is to preserve evidence for a service-side investigation rather than repeatedly unregistering or modifying providers.

    The supported provider-registration mechanism does allow re-registration when Azure adds locations after the original registration.^4^ However, because you are intentionally avoiding further registration writes, and no documentation establishes that Germany West Central requires re-registration in this case, this should not be presented as the fix.

    Permissions check only if needed

    Confirm the calling principal has:

    • Microsoft.Insights/diagnosticSettings/write on the managed environment.
    • Permission to read/use the destination workspace.
    • Permission to update the environment if its logging destination must be changed.

    These are explicit migration prerequisites.^1^ Azure Monitor’s RBAC documentation identifies Microsoft.Insights/diagnosticSettings/write as the resource-side permission needed to configure the setting.^5^

    A missing RBAC action would normally be investigated as authorization, but it does not explain why the returned message specifically says the subscription is unregistered while ARM reports Registered.

    Escalation with Basic support

    Basic does not include assisted technical support by email, phone, or chat. It provides self-help and community support; a Developer, Standard, Professional Direct, or eligible enterprise support entitlement is required for a technical case.^6^

    Available routes:

    1. Post or continue the case on Microsoft Q&A, including the correlation ID and UTC timestamp, but omit subscription IDs and tokens.
    2. If your organization has another support entitlement, link it under Help + Support → Support Plans → Link support benefits.
    3. Otherwise, purchase a technical support plan and open the request from the environment:
      • Container Apps environment → Support + Troubleshooting
      • Complete the diagnostics.
      • Select Create a support request
      • Issue type: Technical
      • Service: Azure Container Apps or Azure Monitor, selecting the closest diagnostic-settings/provider-registration subtype available.

    Creating a technical request requires Owner, Contributor, Support Request Contributor, or a custom subscription-level role containing Microsoft.Support/*.^7^

    Attach:

    • Full managed-environment resource ID and workspace resource ID.
    • Region: Germany West Central.
    • UTC failure time: 2026-10-23T21:11:56.9565986Z.
    • Activity Log correlation/request IDs.
    • Sanitized complete 409 response headers and body.
    • ARM deployment operation output.
    • Current environment logging destination.
    • Provider-state output captured at approximately the failure time.
    • Confirmation that GET/list and category discovery succeed while PUT fails.

    Ask support to verify the subscription’s effective Microsoft.Insights registration in the Azure Monitor diagnostic-settings backend and whether the registration is available to the Germany West Central write path.


    References

    1. Change Container Apps logging from Log Analytics to Azure Monitor
    2. Log storage and monitoring options in Azure Container Apps
    3. Diagnostic Settings - Create Or Update
    4. Azure resource providers and types
    5. Manage access to Log Analytics workspaces
    6. Compare support plans
    7. Create an Azure support request
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.