Dela via


Felsökningsguide för partners intjänade kredit

Lämpliga roller: Global administratör | Administratör för användarhantering | Administratörsagent | Faktureringsadministratör | Försäljningsagent

Felsöka vanliga scenarier

Med den nya Azure-handelsupplevelsen kan partner få rabatter via intjänad partnerkredit (PEC) för tjänster som hanteras. PEC beviljas endast till partner med berättigade behörigheter. Ta reda på vem som är berättigad till PEC, hur den beräknas och hur den betalas ut.

Den här artikeln innehåller grundläggande felsökningsvägledning om PEC inte beviljas.

Förutsättningar

Om du har problem med PEC, till exempel åtkomst eller information som saknas, börjar du med att kontrollera följande objekt.

Kommentar

Endast indirekta leverantörer och direktfaktureringspartner är berättigade att tjäna PEC.

  • Kontrollera att du tittar på G-fakturan (ny handelsupplevelse) och rekonfigureringsfilen. Azure-plan och PEC visas inte på D-fakturan (äldre) eller recon-filen.

  • Bekräfta att ditt Microsoft AI Cloud Partner Program-avtal är aktivt.

  • Bekräfta att ditt erbjudande är berättigat. (Äldre Azure-erbjudanden, reserverade Azure-instanser, Azure-sparplaner, virtuella Azure SPOT-datorer och produkter från tredje part är inte berättigade.)

  • Bekräfta att du (eller den indirekta återförsäljare som angetts som återförsäljare av posten i Azure-planen) har en giltig administrering för (AOBO) eller rollbaserad åtkomstkontroll i Azure (Azure RBAC) för prenumerationen/resursgruppen/resursen. Du kan också:

    • Om du använder Azure Lighthouse kontrollerar du att ditt PartnerID har länkats till minst ett användarkonto. Kontrollera också att den har åtkomst till kundens prenumeration/resursgrupp.
    • Om du använder en Azure RBAC-association kontrollerar du att användaren har en berättigad roll för PEC och Azure RBAC som anges i varje kundklientkontext.
  • Se om kunden har tagit bort dina AOBO-behörigheter. Behörigheterna angavs som standard när Azure-planen etablerades. Om de har tagits bort kan du läsa Återställa administratörsbehörigheter för en kunds Azure Molnlösningsleverantör-prenumerationer (CSP).

  • Bekräfta att du har administratörsåtkomst för hela dagen.

  • Bekräfta att du granskar rätt kolumner i avstämningsfilerna. Mer information finns i Fakturering av Azure-plan: Om din fakturaavstämningsfil.

Scenarier för flera partner

För PEC är det bara viktigt att den transakterande partnern har angett något av de tillgängliga behörighetsalternativen. För den indirekta modellen kan det vara providern, återförsäljaren eller båda.

En annan partner som anger ytterligare AOBO- eller andra behörigheter och ställer in ytterligare Azure RBAC för användare med Azure RBAC-behörigheter påverkar inte PEC för den transakterande partnern.

Se följande tabell. MPN1 är en indirekt leverantör, MPN2 är den indirekta återförsäljare som är länkad till transaktionen som återförsäljare av posten och MPN3 är en annan CSP-partner (direkt eller en annan indirekt återförsäljare):

Transacting-partner (BillTo) Azure RBAC (för användare eller Lighthouse med PEC-berättigad roll) AOBO (PEC-berättigad roll) PEC
MPN1 MPN1 Ej tillämpligt Ja
MPN1 Ej tillämpligt MPN1 Ja
MPN1 MPN2 Ej tillämpligt Ja
MPN1 Ej tillämpligt MPN2 Ja
MPN1 MPN3 MPN1 Ja
MPN1 MPN1 MPN3 Ja
MPN1 MPN1 MPN2 Ja
MPN1 MPN2 MPN1 Ja
MPN1 MPN2 MPN3 Ja
MPN1 MPN3 MPN2 Ja
MPN1 MPN3 Ej tillämpligt Nej
MPN1 Ej tillämpligt MPN3 Nej
MPN1 Saknas Saknas Nej
MPN1 MPN3 MPN3 Nej

Azure-prenumerationsöverföringar

När en partner överför en Azure-prenumeration från eller till en annan partner ändras inga behörigheter för den här överföringen.

Om AOBO eller en annan behörighetsmodell användes före överföringen, med behörigheter som angetts för den gamla "transacting-partnern", pekar behörigheterna fortfarande på den gamla partnern efter överföringen. Men nu blir en annan partner den "transakterande partnern".

För alla Azure-prenumerationsöverföringar rekommenderar vi att den nya målpartnern lägger till behörigheter, till exempel Azure RBAC, före överföringen. De kan på ett säkert sätt göra det utan att påverka den gamla partnerns PEC fram till överföringen.

PartnerID-uppdateringar

Med Partnercenter kan du ändra det PartnerID som är associerat med din CSP-registrering. Att uppdatera PartnerID till ett annat plats-ID för Microsoft AI Cloud Partner Program inom samma globala Microsoft AI Cloud Partner Program-organisation (ett annat plats-ID för Microsoft AI Cloud Partner Program under samma globala ID för Microsoft AI Cloud Partner Program) påverkar inte PEC.

När PartnerID ändras till ett plats-ID i en annan Microsoft AI Cloud Partner Program-organisation kan PEC dock påverkas. I det här fallet, och när PEC visar sig saknas, rekommenderar vi att du kontaktar supporten (nämn att du nyligen har mappat om CSP-registreringen till en annan Microsoft AI Cloud Partner Program-organisation).

Så här verifierar du AOBO-behörigheter

När en partner skapar en Azure-planprenumeration för en kund anges AOBO i form av ett "sekundärt huvudnamn. Det utländska huvudkontot ärver ägarbehörigheter för Azure-prenumerationen. AOBO-behörigheterna innebär att en viss grupp i CSP Partner Center-klientorganisationen (administratörsagenter) ärver dessa behörigheter.

Det utländska huvudkontot, som visas i Azure-portalen, innehåller inte information om vilken grupp det mappar till i den specifika partnerklientorganisationen.

När du visar det externa huvudkontot i Azure-portalen visas ett partnernamn, till exempel "Sekundärt huvudnamn för "Contoso" ...", men "Contoso" är bara visningsnamnet för Partnerns Microsoft Entra-klientorganisation och det är inte unikt.

Icke-unika visningsnamn.

Att använda AZ PowerShell eller Azure CLI krävs för att kontrollera med 100 % säkerhet att AOBO är korrekt inställt och pekar på rätt grupp i rätt CSP-klientorganisation.

Steg 1 – Identifiera objekt-ID:n för agentgrupperna för den transakterande partnern

  • Via Azure-portalen: Partner kan logga in på Azure-portalen i sin egen klientorganisation och söka efter respektive grupper i Microsoft Entra-ID-grupper>. ObjectID visas till höger om gruppnamnet.

Hämta objekt-ID från Azure-portalens gränssnitt.

Innan du använder Azure Cloud Shell måste du konfigurera ett lagringskonto. Det här kontot medför en liten månadskostnad i Azure-prenumerationen som är tillgänglig i klientkontexten. Du kan ta bort resursen efter de steg som följer.

Kommentar

Azure AD- och MSOnline PowerShell-moduler är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med mars 30 2025.

Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra-ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Obs! Versioner 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.

Kontrollera att följande moduler är installerade och uppdaterade till den senaste versionen:

Om det behövs använder du följande cmdlets från PowerShell-windows för att installera dessa moduler:

Install-Module -Name AzureAD -Force
Install-Module -Name Az -AllowClobber -Force

Anslut först till Partnercenter-klientorganisationen med ditt Partnercenter-användarkonto och hämta objectID:n för gruppen AdminAgents och HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Logga in med dina autentiseringsuppgifter för Partnercenter:

Shell-exempel på Partnercenter-anslutning.

Fråga efter information om agentgrupperna:

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

Gruppernas ObjectID visas tillsammans med deras namn:

Shell-exempel på ObjectID för grupper.

Kommentar

Om du inte får något resultat kontrollerar du att du har anslutit till ditt Partnercenter-konto.

Kommentar

Indirekta återförsäljare ser ingen SalesAgents-grupp. Det här steget behöver bara utföras en gång, eftersom AOBO i varje kundklient använder samma ID:er.

Steg 2 – Jämför ObjectID:n med de som används av det utländska huvudkontot

Det är viktigt att använda TenantID som värde för klientparametern (i stället för klientdomännamnet) med ett användarkonto som antingen: – har åtkomst till flera kataloger/klientorganisationer, till exempel ditt Partnercenter-användarkonto eller – har lagts till som gäster i flera klientorganisationer.

Därför behöver du TenantID för den angivna kunden.

  • Via Azure-portalen: Du kan enkelt hämta TenantID från kundlistan i Partnercenter. TenantID är märkt "Microsoft ID":

    Microsoft ID som tenantId.

  • Via PowerShell: Anslut till kundens Azure-prenumeration med giltiga autentiseringsuppgifter. Autentiseringsuppgifterna bör ha behörighet att läsa Azure-prenumerationen och AzureAD för kundklientorganisationen:

    Connect-AzAccount -Tenant $CustomerTenantID
    
    • Läs rolltilldelningar för det utländska huvudkontot för kundens Azure-prenumerationer:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}
    

    Shell-exempelrolltilldelning.

    • Det resulterande ObjectID ska matcha ObjectID för gruppen AdminAgent eller HelpDeskAgent som identifieras i steg 1.

Sammanfattning

Varje aspekt måste matcha för att få PEC via AOBO:

  • Kundens Azure-prenumeration har ett sekundärt huvudnamn med berättigad Azure RBAC-rolltilldelning.
  • ObjectID för den grupp som används av det externa huvudkontot refererar till ObjectID för gruppen AdminAgent eller HelpdeskAgent i partnerklientorganisationen.
  • "Partnerklient" avser direktfaktureringspartnerns klientorganisation. I den indirekta modellen innebär det den indirekta providern eller den indirekta återförsäljarpartnerklientorganisationen.

Exempelskript

Det här avsnittet innehåller exempelskript som kan hjälpa dig att samla in informationen i flera prenumerationer och lagra dem i en . CSV-fil. Dessa skript är avsedda som exempel och tillhandahålls som de är utan stöd. Även om skripten inte gör ändringar i konfigurationen bör de testas noggrant och anpassning kan krävas för det konkreta partner-/kundscenariot.

  • Lista AOBO-information för en enskild kund: I det här exemplet används Microsoft Entra ID- och Azure PowerShell-moduler.
### 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
}
}
  • Lista AOBO-information för flera kunder: Den här koden är endast i illustrationssyfte.
    • Hämta en lista över alla prenumerationer på CSP-kunder och alla utländska huvudkonton och identifiera om det finns ett matchningsfel. Den här koden kan också användas för att samla in information för support.
    • Kontrollera vilka Azure-prenumerationer (Azure-planrättigheter) som har sålts och vilka som är tillgängliga med aktuella autentiseringsuppgifter.
    • För indirekta återförsäljare fungerar det här skriptet också. Men alla prenumerationer skulle ha anteckningen "inte såld" även om de är partner till posten för denna försäljning.
### 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
}
}
}
  • Utdata från det här skriptet kan sedan formateras så här:

    Exempel på utdataformat.

Så här verifierar du Azure Lighthouse-behörigheter och Azure PAL

Precis som AOBO tillåter Azure Lighthouse att grupper av användare i (partner)-hanteringsklientorganisationen ärver delegerade behörigheter i kundens Azure-prenumeration. Skillnaden är att det möjliggör mer detaljerad definition av grupper och behörighetsnivåer än AOBO.

För den här behörighetsmodellen är det enklare att kontrollera om den har angetts korrekt med hjälp av Användargränssnittet för Azure-portalen. Endast partnern kan tillhandahålla fullständig verifiering av att Azure Lighthouse-konfigurationen är korrekt.

Följande steg beskriver hur du identifierar för vilka kunder behörigheterna för Azure RBAC-rollen har delegerats permanent och till vilka grupper. Sedan kan du kontrollera om användaren som har Azure RBAC-associationen är medlem i dessa grupper.

Steg 1 – Kontrollera Lighthouse-delegeringar för kunder

Kontrollera att tillämpliga delegeringar använder PEC-berättigade Azure RBAC-roller.

  • Öppna Azure-portalen (med en användare från partnerns hanteringsklient). Sök sedan efter "Lighthouse" och välj Mina kunder.

    Exempel på Azure Services Lighthouse.

  • I kundöversikten väljer du Delegeringar till vänster. Om du gör det öppnas listan över resurser (prenumerationer eller resursgrupper) där delegerad åtkomst har angetts:

    Sidan Delegeringar.

  • Öppna delegeringarna i den högra kolumnen under "Rolltilldelningar" för att se vilken användargrupp i partner-/hanteringsklientorganisationen som ärver varje typ av behörigheter (se kolumnen Roll). Du kan också se om dessa behörigheter är permanenta (se kolumnen Åtkomsttyp):

    Sidan Rolltilldelningar

Steg 2 – Kontrollera gruppmedlemskap

Välj visningsnamnet för gruppen. Gör det öppnar gruppinformationen. Välj "Medlemmar" för att styra vilken användare som har Azure RBAC inställt och är medlem i respektive grupp:

Gruppmedlemskap.

Steg 3 – Kontrollera om användaren har konfigurerat Azure PAL

Endast den användare som har angett Azure PAL kan kontrollera Azure PAL-tilldelningen. ingen annan administratörsanvändare kan göra det. Se Hur gör jag för att förklara Partner admin Link (PAL) till min kund? i Länka ett Azure-konto till ett PartnerID för mer information om hur användaren kan kontrollera om Azure PAL har angetts, antingen via användargränssnittet eller PowerShell.

Kommentar

Azure PAL bör använda ett PartnerID som ingår i samma Microsoft AI Cloud Partner Program-organisation som är den transakterande partnern för den här Azure-prenumerationen. I den indirekta modellen kan det antingen vara partner-ID för leverantören eller den specifika återförsäljare som är kopplad till den här försäljningen.

Steg 4 – Sök efter tidsbundna grupptilldelningar

Eftersom gruppmedlemskapet kanske inte är permanent kontrollerar du om gruppen har aktiverats för privilegierad åtkomsthantering. Titta där "Privilegierad åtkomst" till vänster under "Aktivitet" i gruppinställningarna. Om sant kontrollerar du om användaren har en aktiv tilldelning och tidsramen för den här tilldelningen.

Kommentar

Eftersom tilldelningens "sluttid" är när en användare tas bort automatiskt från gruppen, skulle PEC gå förlorad för användare som hade Azure RBAC-uppsättning. På samma sätt skulle PEC endast beviljas efter tilldelningens "starttid".

Behörighetsåtkomstgrupp.

Så här verifierar du enskilda användartilldelningar och Azure PAL

I vissa fall kan det vara mer lämpligt att arbeta med enskilda användarkonton som har behörighet för Azure-prenumerationer. Dessa konton kan vara gästanvändarkonton (från valfri klientorganisation) eller användarkonton som skapats i kundens klientorganisation eller tjänstens huvudnamn.

När du använder enskilda användarkonton som ett fordon för att tjäna in PEC innebär kontrollen att bara granska de tilldelade behörigheterna i Azure-prenumerationshanteringen för användaren och kontrollera att användaren har angett Azure RBAC korrekt. När ett huvudnamn för tjänsten används måste kontrollen av Azure RBAC ske via PowerShell.

Steg 1 – Granska behörigheter i Azure-prenumerationshantering

  • Öppna Azure Portal. Kontrollera att du är inloggad som en användare som har Azure RBAC-roll med minst läsbehörighet till den aktuella prenumerationen.

  • Sök efter "Prenumerationer" i sökfältet för att öppna prenumerationsinformation:

    Sidan Prenumerationsinformation.

  • Gå till "Åtkomstkontroll (IAM)" i prenumerationsinformationen. Välj sedan "Rolltilldelningar" för att granska användare som har åtkomst på prenumerationsnivå och om kolumnen Roll visar PEC-berättigade Azure RBAC-roller. Om behörigheter har angetts på resursgruppsnivå är samma "Åtkomstkontroll (IAM)"-vy också tillgänglig i en resursgrupp.

Kommentar

Behörigheter kan också beviljas till en grupp användare där gruppmedlemskapet för den användare som har Azure RBAC-uppsättning också måste verifieras.

Åtkomstkontroll.

Steg 2 – Kontrollera att behörigheterna är permanenta och att inga nekandetilldelningar gäller

Även om det kan se ut som att användare har åtkomst kan deras behörigheter fortfarande vara tillfälliga eller blockerade via Neka tilldelningar.

Det kan vara tidsbundet att använda rolltilldelningen Privileged Identity Management (PIM). Även om du kan se användare med behörighet kanske de bara finns under en kort tid. Kontrollera att Azure RBAC-rolltilldelningen är permanent genom att kontrollera PIM-administrationen i Azure-portalen. Mer specifikt kontrollerar du var Azure-resurser i prenumerationen hanteras av PIM-principer och om användaren omfattas av några principer.

Azure-prenumerationen hanteras inte via PIM.

Listan över behörigheter kan också visa att användaren har behörigheter för prenumerationen, men det kan finnas Neka tilldelningar som fortfarande blockerar användaren från att komma åt något. I "Åtkomstkontroll (IAM)" väljer du fliken Neka tilldelning för att se om Neka tilldelningar gäller:

Neka tilldelningar.

Kommentar

För fullständighet bör partner också kontrollera att det inte finns några Neka-tilldelningar i prenumerationen på resursgrupper.

Steg 3 – Kontrollera om användaren har konfigurerat Azure PAL

Endast den användare som har konfigurerat Azure PAL kan kontrollera Azure PAL-tilldelningarna. ingen annan administratörsanvändare kan göra det. Mer information om hur användaren kan verifiera att Azure PAL har angetts finns i Länka ett Azure-konto till ett PartnerID.

Kommentar

Azure PAL bör använda ett PartnerID som ingår i samma Microsoft AI Cloud Partner Program-organisation som är den transakterande partnern för den här Azure-prenumerationen. I den indirekta modellen kan detta antingen vara PartnerID för providern eller PartnerID för den återförsäljare som är kopplad till den här försäljningen.

Nästa steg