How to Troubleshoot Azure Partner Solutions

This is the root cause of more Azure partner solution deployment errors than anything else, and it's invisible unless you know where to look. When you create a partner resource for the first time, say a Datadog monitor or an Elastic deployment, Azure needs the corresponding resource provider namespace registered on that subscription. If it isn't, the deployment fails with an error code like MissingSubscriptionRegistration or, more confusingly, just DeploymentFailed.

Navigate to Home > Subscriptions > [your subscription] > Settings > Resource providers. In the search box, type the partner name. Each ISV has its own namespace:

Datadog:    Microsoft.Datadog
Elastic:    Microsoft.Elastic
Confluent:  Microsoft.Confluent
NewRelic:   NewRelic.Observability
Palo Alto:  PaloAltoNetworks.Cloudngfw
NGINX:      NGINX.NginxPlus
Dynatrace:  Dynatrace.Observability

If status says NotRegistered, select it and click Register at the top of the blade. The status will cycle through Registering before settling on Registered, this takes between 90 seconds and 5 minutes depending on the provider. Don't try to redeploy before it's fully registered.

If you're managing multiple subscriptions or doing this in a pipeline, PowerShell is more reliable:

$providers = @("Microsoft.Datadog","Microsoft.Elastic","Microsoft.Confluent")
foreach ($p in $providers) {
    Register-AzResourceProvider -ProviderNamespace $p
    Write-Host "Registering $p..."
}
# Poll until all registered
do {
    Start-Sleep -Seconds 15
    $states = $providers | ForEach-Object {
        (Get-AzResourceProvider -ProviderNamespace $_).RegistrationState
    }
    Write-Host $states
} until ($states -notcontains "Registering")

Once registration completes, retry your partner solution deployment. If it succeeds, you're done. If it still fails, move to Step 2.

Here's a subtle issue that kills Azure partner solution integration silently: the partner resource deploys successfully, but logs and metrics never flow because the managed identity it uses doesn't have adequate permissions. You won't get an error, the integration just sits there looking healthy while delivering nothing.

Every Azure Partner Solution that ingests diagnostic data (logs, metrics, traces) uses a system-assigned or user-assigned managed identity under the hood. That identity needs specific role assignments on the resources it monitors. For most observability partners like Datadog or Elastic, the minimum required role is Monitoring Reader at the subscription scope. For partners that also write data back (like some security partners), Contributor at the resource group scope may be needed.

Check the current assignments in the portal: go to Subscriptions > [subscription] > Access control (IAM) > Role assignments. Filter by the partner resource's name. If you see nothing, that's your problem.

To fix it via PowerShell:

# Get the managed identity principal ID from the partner resource
$partnerResource = Get-AzResource -ResourceType "Microsoft.Datadog/monitors" -Name "your-datadog-resource"
$principalId = $partnerResource.Identity.PrincipalId

# Assign Monitoring Reader at subscription scope
New-AzRoleAssignment `
  -ObjectId $principalId `
  -RoleDefinitionName "Monitoring Reader" `
  -Scope "/subscriptions/$($(Get-AzContext).Subscription.Id)"

After assigning the role, give it 5–10 minutes to propagate across Azure's authorization caches. Then go into your partner solution's resource blade, click Monitored resources (or equivalent for your partner), and verify resources are now appearing with a Sending logs status. If you still see Not sending, check whether the specific resource types are enabled in the partner solution's Logs or Metrics configuration blade.

When you create an Azure partner solution linked to an existing ISV account, for example, connecting your Datadog organization or your Elastic Cloud deployment, Azure needs to perform an OAuth handshake between your Azure AD tenant and the partner's SaaS backend. This is the most common source of Azure partner solution integration issues in enterprise environments, because conditional access policies, SAML-based SSO, and tenant restrictions all love to silently block this handshake.

The symptoms are specific: you get to the partner solution creation wizard, fill in your existing account credentials, and hit either a blank white screen, an error saying "Unable to link account," or a redirect loop. In Event Viewer on a Windows client, you may see Event ID 1003 from source Microsoft-Windows-AAD indicating a token acquisition failure.

First, check your tenant's conditional access policies. Go to Azure Active Directory > Security > Conditional Access > Policies and look for any policy that blocks access to external applications or that enforces device compliance for all cloud apps. The partner's application ID needs to be either explicitly allowed or exempted from the blocking policy.

Second, check if your organization uses tenant restrictions (the Restrict-Access-To-Tenants HTTP header injected by a proxy). If so, the partner's tenant ID needs to be added to the allowed list on your proxy configuration.

Third, and this one surprises people, make sure the user performing the link has a valid email address that matches an account in the partner's system. If your Azure AD UPN is an internal format like jsmith@corp.local rather than a routable address, the partner's SSO system can't find the matching account. The fix is to set the user's Mail attribute in Azure AD to a routable address:

# Via MS Graph (requires User.ReadWrite.All)
Update-MgUser -UserId "jsmith@corp.local" -Mail "jsmith@yourdomain.com"

After making any of these changes, try the linking flow again in a fresh InPrivate/Incognito browser window to avoid cached credential state.

One of the most reported Azure partner solution diagnostic logs missing scenarios: you've got the integration working, resources are showing up, but the logs just aren't arriving in the partner's platform. This is infuriating because everything looks green on the Azure side.

The issue is almost always in the diagnostic settings pipeline. Azure partner solutions that receive logs use Azure Monitor's diagnostic settings mechanism, the same one that sends logs to Log Analytics or Event Hub. Each individual resource (VM, App Service, SQL Database, etc.) needs its own diagnostic setting pointing at the partner, or you need to use Azure Policy to deploy them at scale.

Check an individual resource first. Pick a resource that should be sending logs. Go to that resource's blade, then Monitoring > Diagnostic settings. You should see a diagnostic setting with a destination pointing to your partner solution. If none exists, that resource is not sending anything regardless of what the partner's portal says.

To create diagnostic settings at scale using Azure Policy, you can use the built-in initiative Configure Azure Monitor diagnostic settings for resources to send to a partner solution, find it in Policy > Definitions, search for your partner name. Assign it at the subscription or management group scope.

For a quick manual check via PowerShell on a specific resource:

# Check if diagnostic settings exist for a specific resource
$resourceId = "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vm-name}"
Get-AzDiagnosticSetting -ResourceId $resourceId

# If empty, create one pointing to your Datadog resource
$datadogResourceId = "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Datadog/monitors/{monitor-name}"
# Use the partner-specific cmdlets or ARM template for this step

If diagnostic settings exist but logs still aren't arriving, check the partner solution's own ingestion pipeline. In the Datadog Azure integration blade, look under Metrics and Logs, there are toggle switches per resource type and per log category. Make sure the categories you need (audit logs, performance counters, activity logs) are actually enabled on the partner's side.

Azure partner solution billing issues catch people off guard because the error messages during deployment are completely non-obvious. You'll see something like OfferNotAvailable, PlanNotFound, or InvalidOfferCode, and the portal won't tell you whether it's a region issue, a subscription type issue, or a plan configuration problem.

Here's the breakdown. Partner solutions on the Azure Marketplace come in different plan types: some are PAYG (pay-as-you-go) billed through Azure, some require a pre-existing SaaS subscription (BYOL, bring your own license), and some require your subscription to be on a specific Azure offer (like an Enterprise Agreement). Cloud Solution Provider (CSP) subscriptions have the most restrictions, many ISV Marketplace offers are simply not available to CSP customers without the partner explicitly enabling them.

To diagnose a plan availability error, run this PowerShell to check what plans are actually available for a given offer in your subscription:

# Check available Datadog plans (example)
Get-AzMarketplaceTerms -Publisher "datadog1414965929833" -Product "datadog_agent" -Name "datadog_agent"

# List available offers for a publisher
Get-AzVMImageOffer -Location "eastus" -PublisherName "datadog1414965929833"

If your region isn't returning results, the plan genuinely isn't available there. Your options are to deploy the partner solution resource in a supported region (most ISV partner solutions have a Home region concept, the resource lives in one region but can monitor resources globally) or to contact the ISV directly to request region enablement.

For CSP subscription issues, your CSP partner (the Microsoft partner who sold you the subscription) needs to enable the specific Marketplace offer for your tenant through Partner Center. This is a configuration change on their end, not something you can self-serve. Give them the publisher ID and offer ID from the Marketplace listing and ask them to enable it in Partner Center under Marketplace > Customer offers.

Once the plan is available, go back to the Marketplace listing, click Get It Now, and walk through the creation wizard again. Make sure you select the exact plan you confirmed is available, switching plans mid-wizard can silently revert to a plan that doesn't match.