Compartilhar via

Guia de solução de problemas de problemas de crédito obtido por parceiro

  • Artigo

Funções apropriadas: Administrador de gerenciamento de usuários | Agente de administração | Administrador de cobrança | Agente de vendas

Solução de problemas de cenários comuns

Com a nova experiência de commerce do Azure, os parceiros podem receber descontos por meio do crédito obtido por parceiro (PEC) para serviços gerenciados. O PEC é concedido somente a parceiros com permissões elegíveis. Descubra quem é elegível ao PEC, como ele é calculado e como é pago.

Este artigo fornece diretrizes básicas de solução de problemas se o PEC não for concedido.

Pré-requisitos

Se você tiver problemas com o PEC, como acesso ou informações ausentes, comece verificando os itens a seguir.

Observação

Apenas provedores indiretos e parceiros de cobrança direta são elegíveis para ganhar PEC.

  • Verifique se você está examinando a fatura G (nova experiência de comércio) e o arquivo de reconhecimento. O plano do Azure e o PEC não são mostrados na fatura D (herdada) ou no arquivo de reconhecimento.

  • Confirme se o contrato do Microsoft AI Cloud Partner Program está ativo.

  • Confirme se a oferta é qualificada. (Ofertas herdadas do Azure, Instâncias Reservadas do Azure, Azure Savings Plans, VMs SPOT do Azure e produtos de terceiros não estão qualificados.)

  • Confirme se você (ou o revendedor indireto definido como revendedor de registro no plano do Azure) tem uma função válida de Administrar em Nome de (AOBO) ou RBAC (controle de acesso baseado em função) do Azure para a assinatura/grupo de recursos/recurso. Como alternativa:

    • Se você estiver usando o Azure Lighthouse, verifique se o PartnerID foi vinculado a pelo menos uma conta de usuário. Verifique também se ele tem acesso à assinatura/grupo de recursos desse cliente.
    • Se você estiver usando uma associação RBAC do Azure, verifique se o usuário tem uma função qualificada para PEC e RBAC do Azure definida em cada contexto de locatário do cliente.

  • Veja se o cliente removeu suas permissões AOBO. As permissões foram definidas por padrão quando o plano do Azure foi provisionado. Se eles tiverem sido removidos, consulte Restabelecer privilégios de administrador para as assinaturas do CSP (Provedor de Soluções na Nuvem) do Azure de um cliente.

  • Confirme se você tem acesso de administrador para o dia inteiro.

  • Confirme se você está revisando as colunas corretas em seus arquivos de reconciliação. Para obter mais informações, consulte Cobrança do plano do Azure: sobre o arquivo de reconciliação de fatura.

Cenários de vários parceiros

Para o PEC, é importante apenas que o parceiro de transação tenha definido qualquer uma das opções de permissão disponíveis. Para o modelo indireto, pode ser o provedor, o revendedor ou ambos.

Outro parceiro que define AOBO adicional ou outras permissões e define RBAC do Azure adicional para usuários com permissões RBAC do Azure não afetará o PEC para o parceiro de transação.

Confira a tabela a seguir. O MPN1 é um provedor indireto, o MPN2 é o revendedor indireto vinculado à transação como revendedor de registro e o MPN3 é outro parceiro CSP (revendedor direto ou outro revendedor indireto):

Parceiro de transação (BillTo) RBAC do Azure (para usuário ou Lighthouse com função qualificada para PEC) AOBO (função qualificada para PEC) PEC
MPN1 MPN1 N/D Sim
MPN1 N/D MPN1 Sim
MPN1 MPN2 N/D Sim
MPN1 N/D MPN2 Sim
MPN1 MPN3 MPN1 Sim
MPN1 MPN1 MPN3 Sim
MPN1 MPN1 MPN2 Sim
MPN1 MPN2 MPN1 Sim
MPN1 MPN2 MPN3 Sim
MPN1 MPN3 MPN2 Sim
MPN1 MPN3 N/D Não
MPN1 N/D MPN3 Não
MPN1 N/D N/D Não
MPN1 MPN3 MPN3 Não

Transferências de assinatura do Azure

Quando um parceiro transfere uma assinatura do Azure de ou para outro parceiro, nenhuma permissão é alterada para essa transferência.

Portanto, se AOBO ou outro modelo de permissão foi usado antes da transferência, com permissões definidas para o antigo "parceiro de transação", as permissões ainda apontarão para o parceiro antigo após a transferência. Mas agora, outro parceiro se torna o "parceiro de transação".

Para qualquer transferência de assinatura do Azure, é aconselhável que o novo parceiro de destino adicione permissões, como RBAC do Azure, antes da transferência. Eles podem fazer isso com segurança sem afetar o PEC do antigo parceiro até a transferência.

Atualizações de PartnerID

O Partner Center permite que você altere o PartnerID associado ao seu registro do CSP. Atualizar o PartnerID para outra ID de localização do Microsoft AI Cloud Partner Program dentro da mesma organização global do Microsoft AI Cloud Partner Program (outra ID de local do Microsoft AI Cloud Partner Program na mesma ID global do Microsoft AI Cloud Partner Program) não afeta o PEC.

No entanto, quando o PartnerID é alterado para uma ID de local em uma organização diferente do Microsoft AI Cloud Partner Program, o PEC pode ser afetado. Nesse caso, e quando o PEC estiver ausente, recomendamos entrar em contato com o suporte (mencione que você remapeou recentemente seu registro do CSP para uma organização diferente do Microsoft AI Cloud Partner Program).

Como verificar as permissões AOBO

Quando um parceiro cria uma assinatura do Plano do Azure para um cliente, o AOBO é definido na forma de uma "entidade de segurança estrangeira". A entidade de segurança estrangeira herda permissões de proprietário na assinatura do Azure. As permissões AOBO significam que um determinado grupo no locatário do CSP Partner Center (Agentes Administrativos) herdará essas permissões.

A entidade de segurança estrangeira, conforme visto no portal do Azure, não inclui detalhes sobre para qual grupo ela é mapeada no locatário do parceiro específico.

Quando você exibe a entidade de segurança estrangeira no portal do Azure, ela mostra um nome de parceiro, como "Entidade de Segurança Estrangeira para 'Contoso' ...", mas "Contoso" é apenas o nome de exibição do locatário do Microsoft Entra do parceiro e não é exclusivo.

Nomes de exibição não exclusivos.

O uso do AZ PowerShell ou da CLI do Azure é necessário para verificar com 100% de certeza se o AOBO está definido corretamente, apontando para o grupo correto no locatário CSP correto.

Etapa 1 - Identificar os objectIDs dos grupos de agentes do parceiro de transação

  • Por meio do portal do Azure: os parceiros podem entrar no portal do Azure em seu próprio locatário e pesquisar os respectivos grupos em Grupos de ID > do Microsoft Entra. O ObjectID é exibido à direita do nome do grupo.

Obtendo a ID do objeto da interface do portal do Azure.

Antes de usar o Azure Cloud Shell, você precisará configurar uma conta de armazenamento. Essa conta incorrerá em um pequeno custo mensal na assinatura do Azure disponível no contexto do locatário. Você pode excluir o compartilhamento após as etapas a seguir.

Observação

Os módulos Azure AD e MSOnline PowerShell estão preteridos desde 30 de março de 2024. Para saber mais, leia a atualização de preterição. Após essa data, o suporte a esses módulos se limitará à assistência à migração para o SDK do Microsoft Graph PowerShell e às correções de segurança. Os módulos preteridos continuarão funcionando até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (antigo Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas Frequentes sobre Migração. Observação: As versões 1.0.x do MSOnline poderão sofrer interrupções após 30 de junho de 2024.

Certifique-se de ter os seguintes módulos instalados e atualizados para a versão mais recente:

Se necessário, use o seguinte cmdlets nas janelas do PowerShell para instalar esses módulos:

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

Primeiro, conecte-se ao locatário do Partner Center com sua conta de usuário do Partner Center e obtenha as objectIDs do grupo AdminAgents e HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Entre com suas credenciais do Partner Center:

Exemplo de shell de conexão do Partner Center.

Consulte as informações sobre os Grupos de Agentes:

Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }

Os ObjectID grupos serão exibidos junto com seus nomes:

Exemplo de shell de ObjectID de grupos.

Observação

Se você não obtiver um resultado, verifique se você se conectou à sua conta do Partner Center.

Observação

Os revendedores indiretos não verão um grupo SalesAgents. Essa etapa só precisa ser feita uma vez, pois o AOBO em cada locatário do cliente usará as mesmas IDs.

Etapa 2 – Comparar ObjectIDs com os usados pela entidade de segurança estrangeira

É importante usar o TenantID como o valor do parâmetro de locatário (em vez do nome de domínio do locatário) com uma conta de usuário que: - tenha acesso a vários diretórios/locatários, como sua conta de usuário do Partner Center, ou - tenha sido adicionada como convidados a vários locatários.

Portanto, você precisa do TenantID para o cliente fornecido.

  • Por meio do portal do Azure: você pode obter o TenantID facilmente da lista de clientes no Partner Center. O tenantID é rotulado como "ID da Microsoft":

    ID da Microsoft como tenantId.

  • Por meio do PowerShell: conecte-se à assinatura do Azure do cliente com credenciais válidas. As credenciais devem ter permissão para ler a assinatura do Azure e o AzureAD do locatário do cliente:

    Connect-AzAccount -Tenant $CustomerTenantID
    • Atribuições de função de leitura para a entidade externa das assinaturas do Azure do cliente:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}

    Exemplo de atribuição de função do shell.

    • O ObjectID resultante deve corresponder ao ObjectID do grupo AdminAgent ou HelpDeskAgent identificado na Etapa 1.

Resumo

Todos os aspectos precisam corresponder para receber o PEC via AOBO:

  • A assinatura do Azure do cliente tem uma entidade de segurança estrangeira com atribuição de função RBAC do Azure qualificada.
  • O ObjectID do grupo usado pela entidade de segurança estrangeira refere-se ao ObjectID do grupo AdminAgent ou HelpdeskAgent no locatário do parceiro.
  • "Locatário parceiro" significa o locatário do parceiro de cobrança direta. No modelo indireto, significa o locatário do provedor indireto ou do parceiro revendedor indireto.

Scripts de exemplo

Esta seção contém scripts de exemplo que podem ajudar a coletar as informações em várias assinaturas e armazená-las em um . CSV. Esses scripts são considerados exemplos e fornecidos no estado em que se encontram, sem suporte. Embora os scripts não façam modificações na configuração, eles devem ser completamente testados e a personalização pode ser necessária para o cenário concreto de parceiro/cliente.

  • Listando detalhes do AOBO para um único cliente: este exemplo usa a ID do Microsoft Entra e os módulos do Azure PowerShell.
### Install-Module -Name AzureAD -Force ###
### Install-Module -Name Az -AllowClobber -Force ###
### Variables ####
$CSVname = "c:tempAOBOchecker.csv"
$CustomertenantId = ""
### Get Agent-Groups Object IDs and write to CSV - This step needs to be done with a Partner Center User ###
Connect-AzureAD -TenantDomain $PartnerTenantDomain
$Headers = "GroupName`tObjectID`tPartnerTenantName`tPartnerTenantID" >>$CSVname
$PartnerTenant = Get-AzureADTenantDetail
$groups = Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }
ForEach ($Group in $Groups)
{
$NewLine = $Group.DisplayName + "`t" + $Group.ObjectID + "`t" + $PartnerTenant.DisplayName + "`t" + $PartnerTenant.ObjectID
$NewLine >>$CSVname
}
### Get list of Azure Subscriptions for a customer, get list of Foreign Principals and add them to the same CSV ###
Clear-AzContext -Scope CurrentUser -Force
Connect-AzAccount -Tenant $CustomertenantId
$CustomerTenant = Get-AzureADTenantDetail
$CustomerTenantSubscriptions = Get-AzSubscription -TenantId $CustomertenantId
ForEach ($Subscription in $CustomerTenantSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$NewLine = $CustomerTenant.Domain + "`t" + $CustomerTenant.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName
$NewLine >>$CSVname
}
}
  • Listando detalhes AOBO para vários clientes: Este código é apenas para fins ilustrativos.
    • Obtenha uma lista de todas as assinaturas de clientes CSP e todas as entidades estrangeiras e identifique se há uma incompatibilidade. Este código também pode ser usado para coletar informações para suporte.
    • Verifique quais assinaturas do Azure (Direitos do Plano do Azure) foram vendidas e quais podem ser acessadas com as credenciais atuais.
    • Para revendedores indiretos, esse script também funciona. Mas todas as assinaturas teriam a nota "não vendido", mesmo que sejam o parceiro de registro para esta venda.
### Note - below examples use interactive login experience and aren't suitable for production use ###
### See https://learn.microsoft.com/partner-center/develop/enable-secure-app-model#powershell for info on how to authenticate to each customer tenant silently using secure app model ###
### Below examples use AzureAD, AZ and Partner Center PowerShell modules ###
### Install-Module -Name AzureAD -Force ###
### Install-Module -Name Az -AllowClobber -Force ###
### Install-Module -Name PartnerCenter -Force ###
### Variables ####
$PartnertenantDomain = "xyz.onmicrosoft.com"
$PartnerTenantID = ""
$CSVname = "c:tempAOBOchecker.csv"
### Get Agent-Groups Object IDs and write to CSV ###
Connect-AzureAD -TenantDomain $PartnerTenantDomain
$Headers = "GroupName`tObjectID`tPartnerTenantName`tPartnerTenantID" >>$CSVname
$PartnerTenant = Get-AzureADTenantDetail
$groups = Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }
ForEach ($Group in $Groups)
{
$NewLine = $Group.DisplayName + "`t" + $Group.ObjectID + "`t" + $PartnerTenant.DisplayName + "`t" + $PartnerTenant.ObjectID
$NewLine >>$CSVname
}
### Get list of CSP Customers, get List of Azure Subscriptions, get list of Foreign Principals and add them to the same CSV ###
Connect-PartnerCenter -TenantID $PartnertenantID
$Customers = Get-PartnerCustomer
$Headers = "`r`nCustomerTenantName`tCustomerTenantID`tSubscriptionId`tForeignPrincipalName`tObjectID`tAzureRBACRole`tTimeChecked`tNotes`tCredentialsUsedForAccessCheck" >>$CSVname
Foreach ($customer in $Customers)
{
$AzurePlanId = Get-PartnerCustomerSubscription -CustomerId $Customer.CustomerId | ? {$_.OfferName -eq "Azure Plan"}
if ($AzurePlanID -eq $null)
{
Write-Host "Customer $($Customer.Name) does not have Azure Plan"
}
else
{
$AzurePlanSubscriptionsSold = Get-PartnerCustomerAzurePlanEntitlement -CustomerId $Customer.CustomerId -SubscriptionId $AzurePlanId.SubscriptionId
}
Clear-AzContext -Scope CurrentUser -Force
Connect-AzAccount -Tenant $Customer.CustomerId
$CurrentUser = Get-azcontext
$CustomerTenantSubscriptionsAccessible = Get-AzSubscription -TenantId $Customer.CustomerId
$SoldAndAccessibleSubscriptions = $AzurePlanSubscriptionsSold | Where {$CustomerTenantSubscriptionsAccessible -Contains $_}
$SoldButNotAccessibleSubscriptions = $AzurePlanSubscriptionsSold | Where {$CustomerTenantSubscriptionsAccessible -notcontains $_}
$NotSoldButAccessibleSubscriptions = $CustomerTenantSubscriptionsAccessible | Where {$AzurePlanSubscriptionsSold -notcontains $_}
ForEach ($Subscription in $SoldAndAccessibleSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName + "`t" + $CurrentTime + "`t" + "Access with current credentials and sold as CSP Partner" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
}
ForEach ($Subscription in $SoldButNotAccessibleSubscriptions)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + "N/A" + "`t" + "N/A" + "`t" + "N/A" + "`t" + "N/A" + "`t" + $CurrentTime + "`t" + "Sold via CSP, but no access with current credentials" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
ForEach ($Subscription in $NotSoldButAccessibleSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName + "`t" + $CurrentTime + "`t" + "Access with current credentials, but not sold as CSP Partner" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
}
}

  • A saída desse script pode ser formatada assim:

    Exemplo de formato de saída.

Como verificar as permissões do Azure Lighthouse e a PAL do Azure

Assim como o AOBO, o Azure Lighthouse permite que grupos de usuários no locatário de gerenciamento (parceiro) herdem permissões delegadas na assinatura do Azure do cliente. A diferença é que ele permite uma definição mais granular de grupos e níveis de permissão do que AOBO.

Para esse modelo de permissão, é mais fácil verificar se ele foi definido corretamente usando a interface do usuário do portal do Azure. Somente o parceiro pode fornecer verificação completa de que a configuração do Azure Lighthouse está correta.

As etapas a seguir descrevem como identificar para quais clientes as permissões de função RBAC do Azure foram delegadas permanentemente e para quais grupos. Em seguida, você pode verificar se o usuário que tem a associação RBAC do Azure é membro desses grupos.

Passo 1 – Verifique as delegações do Lighthouse nos clientes

Verifique se as delegações aplicáveis estão usando funções RBAC do Azure qualificadas para PEC.

  • Abra o portal do Azure (com um usuário do locatário de gerenciamento do parceiro). Em seguida, procure por "Farol" e selecione Meus clientes.

    Exemplo do Lighthouse de serviços do Azure.

  • Na visão geral do cliente, escolha Delegações no lado esquerdo. Isso abre a lista de recursos (Assinaturas ou Grupos de recursos) em que o acesso delegado foi fornecido:

    Página de delegações.

  • Abra as delegações na coluna da direita em "Atribuições de Função" para ver qual grupo de usuários no locatário de parceiro/gerenciamento herda cada tipo de permissão (consulte a coluna "Função"). Você também pode ver se essas permissões são permanentes (consulte a coluna "Tipo de acesso"):

    Página Atribuições de função

Passo 2 – Verifique a associação ao grupo

Selecione o nome de exibição do grupo. Fazê-lo vai abrir os detalhes do grupo. Selecione "Membros" para controlar qual usuário tem o RBAC do Azure definido e é membro do respectivo grupo:

Associação de grupo.

Etapa 3 – Verificar se o usuário configurou a PAL do Azure

Somente o usuário que definiu o Azure PAL pode verificar a atribuição do Azure PAL; nenhum outro usuário administrador pode fazer isso. Consulte Como explicar o PAL (Link de Administração de Parceiro) para meu cliente? em Vincular uma conta do Azure a um PartnerID para obter mais informações sobre como o usuário pode verificar se o PAL do Azure foi definido, por meio da interface do usuário ou do PowerShell.

Observação

A PAL do Azure deve usar um PartnerID que faça parte da mesma organização do Programa de Parceiros de Nuvem do Microsoft AI que é o parceiro de transação para esta assinatura do Azure. No modelo indireto, pode ser o PartnerID do provedor ou do revendedor específico anexado a essa venda.

Etapa 4 - Verificar se há atribuições em grupo com limite de tempo

Como a associação ao grupo pode não ser permanente, verifique se o grupo foi habilitado para gerenciamento de acesso privilegiado. Veja onde "Acesso privilegiado" no lado esquerdo em "Atividade" nas configurações do grupo. Se for verdadeiro, verifique se o usuário tem uma atribuição ativa e o período de tempo para essa atribuição.

Observação

Como a "hora de término" da atribuição é quando um usuário é removido automaticamente do grupo, o PEC seria perdido para usuários que tinham o RBAC do Azure definido. Da mesma forma, o PEC só seria concedido após a "hora de início" da atribuição.

Grupo de acesso privilegiado.

Como verificar a atribuição de usuário individual e a PAL do Azure

Em alguns casos, pode ser mais adequado trabalhar com contas de usuário individuais com permissões em assinaturas do Azure. Essas contas podem ser contas de usuário convidado (de qualquer locatário) ou contas de usuário criadas no locatário do cliente ou nas entidades de serviço.

Ao usar contas de usuário individuais como um veículo para ganhar PEC, a verificação envolve apenas examinar as permissões atribuídas no gerenciamento de assinaturas do Azure para o usuário e verificar se o usuário definiu o RBAC do Azure corretamente. Quando uma entidade de serviço é usada, a verificação do RBAC do Azure precisa acontecer por meio do PowerShell.

Etapa 1 – Examinar permissões no gerenciamento de assinaturas do Azure

  • Abra o Portal do Azure. Verifique se você está conectado como um usuário que tem a função RBAC do Azure com pelo menos acesso de leitura à assinatura em questão.

  • Pesquise "Assinaturas" na barra de pesquisa para abrir os detalhes da assinatura:

    Página de detalhes da assinatura.

  • Vá para "Controle de acesso (IAM)" nos detalhes da assinatura. Em seguida, selecione "Atribuições de função" para examinar os usuários que têm acesso em um nível de assinatura e se a coluna "Função" mostra funções RBAC do Azure qualificadas para PEC. Se as permissões tiverem sido definidas em um nível de grupo de recursos, a mesma exibição "Controle de Acesso (IAM)" também estará disponível em um grupo de recursos.

Observação

As permissões também podem ser concedidas a um grupo de usuários em que a associação de grupo do usuário que tem o RBAC do Azure definido também precisaria ser verificada.

Controle de acesso.

Etapa 2 – Verifique se as permissões são permanentes e se nenhuma atribuição de negação se aplica

Embora possa parecer que os usuários têm acesso, suas permissões ainda podem ser temporárias ou bloqueadas por meio de atribuições negadas.

O uso da atribuição de função RBAC do Azure do PIM (Privileged Identity Management) pode ser limitado por tempo. Embora você possa ver usuários com permissão, eles podem existir apenas por um curto período de tempo. Para verificar se a atribuição de função RBAC do Azure é permanente, verifique a administração do PIM no portal do Azure. Especificamente, verifique onde os recursos do Azure na assinatura estão sendo gerenciados por políticas de PIM e se o usuário está sujeito a alguma política.

A assinatura do Azure não é gerenciada por meio do PIM.

Além disso, a lista de permissões pode mostrar que o usuário tem permissões na assinatura, mas pode haver atribuições de negação que ainda impedem o usuário de acessar algo. Em "Controle de acesso (IAM)", selecione a guia Negar atribuição para ver se as atribuições de negação se aplicam:

Negar atribuições.

Observação

Para fins de integridade, os parceiros também devem verificar se nos grupos de recursos não existem atribuições de negação na assinatura.

Etapa 3 – Verificar se o usuário configurou a PAL do Azure

Somente o usuário que configurou o Azure PAL pode verificar as atribuições do Azure PAL; nenhum outro usuário administrador pode fazer isso. Para obter mais informações sobre como o usuário pode verificar se a PAL do Azure foi definida, consulte Vincular uma conta do Azure a um PartnerID.

Observação

A PAL do Azure deve usar um PartnerID que faça parte da mesma organização do Programa de Parceiros de Nuvem do Microsoft AI que é o parceiro de transação para esta assinatura do Azure. No modelo indireto, pode ser o PartnerID do provedor ou o PartnerID do revendedor anexado a essa venda.

Conteúdo relacionado