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 provedores indiretos e parceiros de faturamento direto são elegíveis para ganhar PEC.

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

  • 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 registro no plano do Azure) tem uma função válida Administrar em Nome de (AOBO) ou Controle de Acesso Baseado em Função do Azure (Azure RBAC) válida para a assinatura/grupo de recursos/recurso. Em 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 assinaturas/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 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. Para saber mais, veja Cobrança do plano do Azure: Sobre o arquivo de reconciliação de 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.

Outra configuração de Parceiro AOBO adicional ou outras permissões e a configuração de RBAC do Azure adicional para usuários com permissões de RBAC do Azure não afetarão o PEC para o Parceiro de transação.

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 usuário ou Farol com função qualificada 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 fazer 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 assinatura do Plano do Azure para um cliente, o AOBO é definido na forma de uma "entidade 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 de Administração) herdará essas permissões.

A entidade estrangeira, conforme visto no portal do Azure, não inclui detalhes sobre para qual grupo ele mapeia no locatário parceiro específico.

Quando você exibe a entidade estrangeira no portal do Azure, ela mostra um nome de parceiro, como "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.

Usar o AZ PowerShell ou a 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

  • Através do portal do Azure: os parceiros podem iniciar sessão no portal do Azure no seu próprio inquilino e procurar os respetivos grupos nos Grupos de ID > do Microsoft Entra. 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 atualização de 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 grupos serão exibidos juntamente com seus nomes:

Exemplo de shell de ObjectID de grupos.

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 só precisa ser feita uma vez, já que o AOBO em cada locatário do 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 da 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 AzureAD do locatário 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 de exemplo de 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 assinatura do Azure do cliente tem uma entidade estrangeira com atribuição de função RBAC do Azure qualificada.
  • O ObjectID do grupo usado pela entidade estrangeira refere-se ao ObjectID do grupo AdminAgent ou HelpdeskAgent no locatário parceiro.
  • "Locatário parceiro" significa o locatário parceiro de fatura direta. No modelo indireto, significa o provedor indireto ou locatário parceiro revendedor indireto.

Scripts de amostra

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 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 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 Farol 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 de 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) 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 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 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 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 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. Veja onde "Acesso privilegiado" no lado esquerdo em "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 concedida após o "horário de início" da atribuição.

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 é usada, a verificação do RBAC do Azure precisa acontecer por meio 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 revisar os usuários que têm acesso em um nível de assinatura e se a coluna "Função" mostrar 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.

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 se aplicam atribuições Negar

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 usuário tem permissões na assinatura, mas pode haver atribuições Negar que ainda bloqueiam o acesso do usuário a algo. Em "Controle de acesso (IAM)", selecione a guia Negar atribuição para ver se Negar atribuições se aplica:

Negar atribuições.

Nota

Para completar, os parceiros também devem verificar se nos grupos de recursos não existem atribuições Negar 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