Partilhar via

Guia de resolução de problemas do crédito ganho pelo parceiro

  • Artigo

Funções apropriadas: Administrador de gerenciamento de usuários | Agente administrativo | Administrador de faturação | Agente de vendas

Resolução de problemas de cenários comuns

Com a nova experiência de comércio do Azure, os parceiros podem receber descontos através do crédito ganho pelo parceiro (PEC) para serviços geridos. O PEC só é concedido a parceiros com permissões elegíveis. Descubra quem é elegível para o PEC, como é calculado e como é pago.

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

Pré-requisitos

Se você tiver problemas com a PEC, como acesso ou falta de informações, comece verificando os seguintes itens.

Nota

Apenas os provedores indiretos e os parceiros de faturação direta têm direito a ganhar PEC.

  • Certifique-se de que está a ver a fatura da nova experiência de comércio G e o ficheiro de reconciliação. O plano do Azure e o PEC não são apresentados na fatura D (Legado) ou no ficheiro de reconciliação.

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

  • Confirme se a sua oferta é elegível. (As ofertas herdadas do Azure, as Instâncias Reservadas do Azure, os Planos de Poupança do Azure, as VMs SPOT do Azure e os produtos de terceiros não são elegíveis.)

  • Confirme se você (ou o revendedor indireto definido como revendedor de registo no plano do Azure) tem uma função Administrar em Nome de Outros (AOBO) ou Controle de Acesso Baseado em Função do Azure (Azure RBAC) válida para a subscrição/grupo de recursos/recurso. Como alternativa:

    • Se estiver a utilizar o Azure Lighthouse, certifique-se de que o seu PartnerID foi associado a pelo menos uma conta de utilizador. Verifique também se ele tem acesso ao grupo de subscrição/recursos desse cliente.
    • Se estiver a usar uma associação do RBAC do Azure, verifique se o utilizador tem uma função elegível para PEC e RBAC do Azure definida em cada contexto de locatário.

  • Veja se o cliente removeu as suas permissões de 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 Provedor de Soluções de Nuvem (CSP) do Azure de um cliente.

  • Confirme que tem acesso de administrador durante todo o dia.

  • Confirme que está a rever as colunas corretas nos seus ficheiros de reconciliação. Mais informações, veja Cobrança do plano do Azure: Sobre o arquivo de reconciliação da fatura.

Cenários com vários parceiros

Para a 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 fornecedor, ou o revendedor, ou ambos.

Outro Parceiro que define permissões adicionais de AOBO ou outras permissões e definindo RBAC adicional do Azure para utilizadores com permissões de RBAC do Azure não afetará o PEC para o Parceiro que está a transacionar.

Consulte a seguinte tabela. A MPN1 é um fornecedor indireto, a MPN2 é o revendedor indireto vinculado à transação como revendedor de registro e a MPN3 é outro parceiro CSP (revendedor direto ou indireto):

Parceiro transacionador (BillTo) Azure RBAC (para utilizador ou Lighthouse com função elegível para PEC) AOBO (função elegível para PEC) PEC
MPN1 MPN1 N/A Sim
MPN1 N/A MPN1 Sim
MPN1 MPN2 N/A Sim
MPN1 N/A 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/A Não
MPN1 N/A MPN3 Não
MPN1 N/A N/A Não
MPN1 MPN3 MPN3 Não

Transferências de subscrição 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 o Azure RBAC, antes da transferência. Eles podem realizar isso com segurança sem afetar a PEC do antigo parceiro até a transferência.

Atualizações do PartnerID

O Partner Center permite que você altere o PartnerID associado à sua inscrição no CSP. A atualização do PartnerID para outro ID de local do Microsoft AI Cloud Partner Program dentro da mesma organização global do Microsoft AI Cloud Partner Program (outro ID de local do Microsoft AI Cloud Partner Program sob o mesmo ID global do Microsoft AI Cloud Partner Program) não afeta a PEC.

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

Como verificar as permissões AOBO

Quando um parceiro cria uma subscrição do Plano do Azure para um cliente, o AOBO é configurado na forma de uma "entidade estrangeira". O principal estrangeiro 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 de Administração) herdará essas permissões.

O principal estrangeiro, conforme visto no portal do Azure, não inclui detalhes sobre para qual grupo o mapeia no locatário parceiro específico.

Quando se exibe a entidade estrangeira no portal do Azure, é exibido um nome de parceiro, como, por exemplo, "Principal Estrangeiro para 'Contoso'...", mas "Contoso" é apenas o nome para exibição do locatário do Microsoft Entra do parceiro e não é exclusivo.

Nomes de exibição não exclusivos.

É necessário usar o PowerShell do AZ ou a CLI do Azure para verificar com absoluta certeza que o AOBO está corretamente configurado, apontando para o grupo correto no inquilino correto do CSP.

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

  • Através do portal do Azure: os parceiros podem iniciar sessão no portal do Azure no seu próprio locatário e procurar os respetivos grupos nos Grupos de Microsoft Entra ID. O ObjectID é exibido à direita do nome do grupo.

Obter ID de 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.

Nota

Os módulos Azure AD e MSOnline PowerShell foram preteridos a partir de 30 de março de 2024. Para saber mais, leia a notificação sobre descontinuação. Após essa data, o suporte para esses módulos é limitado à assistência de migração para o SDK do Microsoft Graph PowerShell e correções de segurança. Os módulos preteridos continuarão a funcionar até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (anteriormente Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas frequentes sobre migração. Nota: As versões 1.0.x do MSOnline podem 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 das 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 os objectIDs do grupo AdminAgents e HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Inicie sessão com as 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 dos grupos serão exibidos juntamente com os seus nomes:

Exemplo na linha de comandos de

Nota

Se não obtiver um resultado, certifique-se de que se ligou à sua conta do Partner Center.

Nota

Os revendedores indiretos não verão um grupo SalesAgents. Esta etapa precisa ser feita apenas uma vez, já que o AOBO em cada inquilino de cliente usará os mesmos IDs.

Etapa 2 - Comparar ObjectIDs com os usados pelo principal estrangeiro

É importante usar o TenantID como o valor para o parâmetro tenant (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 determinado cliente.

  • Através do portal do Azure: pode obter o TenantID facilmente a partir da lista de clientes no Partner Center. O tenantID é rotulado como "Microsoft ID":

    ID de Microsoft como tenantId.

  • Via 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 Azure Active Directory do cliente.

    Connect-AzAccount -Tenant $CustomerTenantID
    • Leia as atribuições de função para o Principal Estrangeiro das assinaturas do Azure do cliente:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}

    Atribuição de função exemplo no shell.

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

Resumo

Todos os aspetos precisam corresponder para receber PEC via AOBO:

  • A subscrição do Azure do cliente tem um principal estrangeiro com atribuição de função RBAC do Azure elegível.
  • O ObjectID do grupo utilizado pelo principal estrangeiro refere-se ao ObjectID do grupo AdminAgent ou HelpdeskAgent no inquilino parceiro.
  • "Locatário parceiro" significa o locatário parceiro de fatura direta. No modelo indireto, significa o cliente parceiro revendedor indireto ou o provedor indireto.

Exemplos de scripts

Esta seção contém scripts de exemplo que podem ajudar a reunir as informações em várias assinaturas e armazená-las em um arquivo . Arquivo CSV. Esses scripts são servidos como 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 exaustivamente 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 os módulos Microsoft Entra ID e 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 todos os principais estrangeiros e identifique se há uma incompatibilidade. Esse 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 estão acessíveis com as credenciais atuais.
    • Para revendedores indiretos, esse script também funciona. Mas todas as subscrições teriam a nota "não vendida", mesmo que sejam o parceiro de registo 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 deste script pode então ser formatada da seguinte forma:

    Exemplo de formato de saída.

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

Como o AOBO, o Azure Lighthouse permite que grupos de utilizadores no inquilino de gestão (parceiro) herdem permissões delegadas na subscrição 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 o 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 a 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 a quais grupos. Em seguida, você pode verificar se o usuário que tem a associação RBAC do Azure é um membro desses grupos.

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

Verifique se as delegações aplicáveis estão a usar os papéis do Azure RBAC elegíveis para PEC.

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

    Exemplo de serviços Azure do Lighthouse.

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

    Página das delegações.

  • Abra as delegações na coluna da direita em "Atribuições de função" para ver qual grupo de utilizadores no tenant de parceiro/gestão 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 de atribuições de função

Etapa 2 – Verificar a participação no grupo

Selecione o nome para exibição do grupo. Isso abre os detalhes do grupo. Selecione "Membros" para controlar qual usuário tem o Azure RBAC definido e é membro do respetivo grupo:

Participação em grupos.

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

Somente o usuário que definiu o Azure PAL pode verificar a atribuição do Azure PAL; nenhum outro usuário administrador pode fazê-lo. Consulte Como explicar o Partner Admin Link (PAL) ao 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 Azure PAL foi definido, via interface do usuário ou PowerShell.

Nota

A PAL do Azure deve utilizar um PartnerID que faça parte da mesma organização do programa Microsoft AI Cloud Partner que é o parceiro transacional para esta subscrição do Azure. No modelo indireto, pode ser o PartnerID do fornecedor ou o revendedor específico associado a esta venda.

Etapa 4 - Verificar se há atribuições de 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. Procure por "Acesso privilegiado" no lado esquerdo sob "Atividade" nas configurações do grupo. Se verdadeiro, verifique se o usuário tem uma atribuição ativa e o período de tempo para essa atribuição.

Nota

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

Grupo de acesso privilegiado.

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

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 entidades de serviço.

Ao usar contas de usuário individuais como um veículo para ganhar PEC, a verificação envolve apenas revisar 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 é utilizada, a verificação do RBAC do Azure deve ser realizada através do PowerShell.

Etapa 1 – Revisar 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.

  • Procure por "Subscrições" na barra de pesquisa para abrir os detalhes da subscrição:

    Página de detalhes da subscrição.

  • Vá para "Controle de acesso (IAM)" nos detalhes da assinatura. Em seguida, selecione "Atribuições de função" para verificar os utilizadores que têm acesso ao nível da assinatura e se a coluna "Função" mostra funções RBAC do Azure elegíveis 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.

Nota

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.

Controlo de acesso.

Etapa 2 – Verifique se as permissões são permanentes e se não há atribuições de negação aplicáveis

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

Usar a atribuição de função RBAC do Azure Privileged Identity Management (PIM) pode ter limite de 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 do 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 PIM e se o usuário está sujeito a quaisquer políticas.

A subscrição do Azure não é gerida através do PIM.

Além disso, a lista de permissões pode mostrar que o utilizador tem permissões na assinatura, mas pode haver atribuições "Negar" que ainda bloqueiam o utilizador de aceder a algo. Em "Controle de acesso (IAM)", selecione o separador de atribuições de Negar para ver se as atribuições de Negar se aplicam:

Negar atribuições.

Nota

Para completar, 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 o Azure PAL

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

Nota

A PAL do Azure deve usar um PartnerID que faça parte da mesma organização do Microsoft AI Cloud Partner Program que é o parceiro de transação para esta assinatura do Azure. No modelo indireto, pode ser o PartnerID do fornecedor ou o PartnerID do revendedor associado a esta venda.

Conteúdos relacionados