パートナー獲得クレジットに関するトラブルシューティング ガイド

対象ロール: グローバル管理者 | ユーザー管理の管理者 | 管理エージェント | 課金管理者 | 販売エージェント

一般的なシナリオのトラブルシューティング

Azure の新しいコマース エクスペリエンスを使用すると、パートナーは、管理されているサービスのパートナー獲得クレジット (PEC) を通じて割引を受けることができます。 PEC は、対象となるアクセス許可を持つパートナーにのみ付与されます。 PEC の対象者、計算方法、支払方法を確認します。

この記事では、PEC が付与されていない場合の基本的なトラブルシューティング ガイダンスを提供します。

前提条件

アクセスや情報の不足など、PEC に問題がある場合は、まず次の項目をチェックします。

Note

PEC を獲得できるのは、間接プロバイダーと直接請求パートナーだけです。

• G (新しいコマース エクスペリエンス) の請求書と偵察ファイルが表示されていることを確認します。 Azure プランと PEC は、D (レガシ) の請求書または偵察ファイルには表示されません。

• Microsoft AI クラウド パートナー プログラム契約がアクティブであることを確認します。

• オファーが対象であることを確認します (従来の Azure オファー、Azure 予約インスタンス、Azure Savings プラン、Azure SPOT VM、サード パーティ製品は対象外です)。

• サブスクリプション/リソース グループ/リソースに対する有効な 管理ister on Behalf of (AOBO) ロールまたは Azure ロールベースのアクセス制御 (Azure RBAC) ロールが、自分 (または Azure プランのレコードのリセラーとして設定されている間接リセラー) にあることを確認します。 あるいは:

  • Azure Lighthouse を使用している場合は、PartnerID が少なくとも 1 つのユーザー アカウントにリンクされていることを確認します。 また、その顧客のサブスクリプション/リソース グループにアクセスできるチェック。
  • Azure RBAC の関連付けを使用している場合は、各顧客テナント コンテキストで PEC と Azure RBAC の対象ロールが設定されていることを確認します。

• 顧客が AOBO アクセス許可を削除したかどうかを確認します。 アクセス許可は、Azure プランのプロビジョニング時に既定で設定されました。 削除された場合は、顧客の Azure クラウド ソリューション プロバイダー (CSP) サブスクリプションの管理者特権を復元する方法に関するページを参照してください。

• 全日分の管理アクセス権を持っていることを確認します。

• 調整ファイル内の正しい列を確認していることを確認します。 詳細については、「Azure プランの課金: 請求書調整ファイルについて」を参照してください。

マルチパートナー のシナリオ

PEC の場合、トランザクション パートナーが使用可能なアクセス許可オプションを設定していることだけが重要です。 間接モデルの場合は、プロバイダー、リセラー、またはその両方を指定できます。

別のパートナーが追加の AOBO またはその他のアクセス許可を設定し、Azure RBAC アクセス許可を持つユーザーに対して追加の Azure RBAC を設定しても、トランザクション パートナーの PEC には影響しません。

次のテーブルを参照してください。 MPN1 は間接プロバイダーであり、MPN2 はレコードのリセラーとしてトランザクションにリンクされている間接リセラーであり、MPN3 は別の CSP パートナー (直接または別の間接リセラー) です。

トランザクション パートナー (BillTo)	Azure RBAC (PEC 対象ロールを持つユーザーまたは Lighthouse の場合)	AOBO (PEC 資格のあるロール)	PEC
MPN1	MPN1	該当なし	はい
MPN1	該当なし	MPN1	はい
MPN1	MPN2	該当なし	はい
MPN1	該当なし	MPN2	はい
MPN1	MPN3	MPN1	はい
MPN1	MPN1	MPN3	はい
MPN1	MPN1	MPN2	はい
MPN1	MPN2	MPN1	はい
MPN1	MPN2	MPN3	はい
MPN1	MPN3	MPN2	はい
MPN1	MPN3	該当なし	いいえ
MPN1	該当なし	MPN3	いいえ
MPN1	該当なし	該当なし	いいえ
MPN1	MPN3	MPN3	いいえ

Azure サブスクリプションの譲渡

パートナーが Azure サブスクリプションを別のパートナー からまたは別のパートナーに譲渡する場合、この譲渡に対するアクセス許可は変更されません。

そのため、AOBO または別のアクセス許可モデルが転送前に使用され、古い "取引パートナー" に対してアクセス許可が設定されている場合、アクセス許可は転送後も古いパートナーを指し示します。 しかし、今では、別のパートナーが "取引パートナー" になります。

Azure サブスクリプションの転送の場合は、新しいターゲット パートナーが、転送の前に Azure RBAC などのアクセス許可を追加することをお勧めします。 彼らは転送まで古いパートナーのPECに影響を与えることなく、安全にこれを行うことができます。

PartnerID の更新

パートナー センターでは、CSP 登録に関連付けられている PartnerID を変更できます。 PartnerID を同じ Microsoft AI Cloud Partner Program グローバル組織内の別の Microsoft AI Cloud パートナー プログラムの場所 ID (同じ Microsoft AI Cloud パートナー プログラムグローバル ID の下にある別の Microsoft AI クラウド パートナー プログラムの場所 ID) に更新しても、PEC には影響しません。

ただし、PartnerID が別の Microsoft AI クラウド パートナー プログラム組織の場所 ID に変更されると、PEC が影響を受ける可能性があります。 この例では、PEC が見つからないことが判明した場合は、サポートに連絡することをお勧めします (最近 CSP 登録を別の Microsoft AI Cloud パートナー プログラム組織に再マップしたメンション)。

AOBO のアクセス許可を確認する方法

パートナーが顧客の Azure プラン サブスクリプションを作成すると、AOBO は "外部プリンシパル" の形式で設定されます。 外部プリンシパルは、Azure サブスクリプションに対する所有者アクセス許可を継承します。 AOBO アクセス許可は、CSP パートナー センター テナント (管理 エージェント) 内の特定のグループがそれらのアクセス許可を継承することを意味します。

Azure portal に示されているように、外部プリンシパルには、特定のパートナー テナント内でマップされるグループに関する詳細は含まれません。

Azure portal で外部プリンシパルを表示すると、"Contoso" の外部プリンシパルなどのパートナー名が表示されますが、"Contoso" はパートナーの Microsoft Entra テナントの表示名のみであり、一意ではありません。

AZ PowerShell または Azure CLI を使用して、AOBO が正しく設定されていることを 100% 確実に確認し、適切な CSP テナント内の正しいグループを指す必要があります。

手順 1 - 取引パートナーのエージェント グループの objectID を識別する

• Azure portal を使用: パートナーは、独自のテナントで Azure portal にサインインし、Microsoft Entra ID グループ内のそれぞれのグループを>検索できます。 ObjectID がグループ名の右側に表示されます。

• PowerShell を使用して: PowerShell ( ローカル PowerShell または Azure Cloud Shell) を起動します。

Azure Cloud Shell を使用する前に、ストレージ アカウントを設定する必要があります。 このアカウントでは、テナント コンテキストで使用できる Azure サブスクリプションで少額の月額コストが発生します。 次の手順の後で共有を削除できます。

Note

Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。 詳細については、非推奨の最新情報を参照してください。 この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。 非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。

Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 注: MSOnline のバージョン 1.0.x では、2024 年 6 月 30 日以降に中断が発生する可能性があります。

次のモジュールがインストールされ、最新バージョンに更新されていることを確認します。

• AzureAD モジュール
• AZ PowerShell モジュール (Cloud Shell では必要ありません)

必要に応じて、PowerShell ウィンドウから次 cmdlets のコマンドを使用して、これらのモジュールをインストールします。

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

まず、パートナー センター のユーザー アカウントを使用してパートナー センター テナントに接続し、管理Agents グループと HelpdeskAgents グループの objectID を取得します。

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

パートナー センターの資格情報でサインインします。

エージェント グループに関する情報を照会します。

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

ObjectIDグループの名前と共に表示されます。

Note

結果が得られない場合は、パートナー センター アカウントに接続していることを確認してください。

Note

間接リセラーには SalesAgents グループは表示されません。 各顧客テナントの AOBO は同じ ID を使用するため、この手順は 1 回だけ実行する必要があります。

手順 2 - ObjectID を外部プリンシパルで使用されるオブジェクト ID と比較する

テナント パラメーター (テナントの名前ではなくメイン名) の値として TenantID を使用することが重要です。これは、パートナー センターのユーザー アカウントなど、複数のディレクトリ/テナントへのアクセス権を持つユーザー アカウント、またはゲストとして複数のテナントに追加されたユーザー アカウントです。

そのため、特定の顧客の TenantID が必要です。

• Azure portal を使用する: パートナー センターの顧客リストから TenantID を簡単に取得できます。 tenantID には "Microsoft ID" というラベルが付けられます。

  

• PowerShell 経由: 有効な資格情報を使用して顧客の Azure サブスクリプションに接続します。 資格情報には、顧客テナントの Azure サブスクリプションと AzureAD を読み取るアクセス許可が必要です。

  Connect-AzAccount -Tenant $CustomerTenantID
  

  • 顧客の Azure サブスクリプションの外部プリンシパルのロールの割り当てを読み取ります。

  Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}
  

  

  • 結果の ObjectID は、手順 1 で識別された 管理Agent グループまたは HelpDeskAgent グループの ObjectID と一致する必要があります。

まとめ

AOBO 経由で PEC を受信するには、すべての側面が一致する必要があります。

• 顧客の Azure サブスクリプションには、適格な Azure RBAC ロールの割り当てを持つ外部プリンシパルがあります。
• 外部プリンシパルによって使用されるグループの ObjectID は、パートナー テナントの 管理Agent グループまたは HelpdeskAgent グループの ObjectID を参照します。
• "パートナー テナント" とは、直接請求パートナー テナントを意味します。 間接モデルでは、間接プロバイダーまたは間接リセラー パートナー テナントを意味します。

サンプルのスクリプト

このセクションには、複数のサブスクリプション間で情報を収集し、それらを 1 つのサブスクリプションに格納するのに役立つサンプル スクリプトが含まれています。CSV ファイル。 これらのスクリプトは例として意図されており、サポートなしでそのまま提供されます。 スクリプトはセットアップで変更を加えませんが、十分にテストする必要があります。具体的なパートナー/顧客シナリオにはカスタマイズが必要な場合があります。

• 1 人の顧客の AOBO の詳細を一覧表示する: この例では、Microsoft Entra ID と 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
}
}

• 複数の顧客の AOBO の詳細を一覧表示する: このコードは説明のみを目的としています。
  • CSP 顧客とすべての外部プリンシパルのすべてのサブスクリプションの一覧を取得し、不一致があるかどうかを特定します。 このコードを使用して、サポートの情報を収集することもできます。
  • 販売された Azure サブスクリプション (Azure プランエンタイトルメント) と、現在の資格情報でアクセス可能な Azure サブスクリプションを確認します。
  • 間接リセラーの場合、このスクリプトも機能します。 ただし、すべてのサブスクリプションは、この販売の記録パートナーである場合でも、"販売されていません" というメモを持ちます。

### 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
}
}
}

• このスクリプトの出力は、次のように書式設定できます。

  

Azure Lighthouse のアクセス許可と Azure PAL を確認する方法

AOBO と同様に、Azure Lighthouse では、(パートナー) 管理テナント内のユーザーのグループが、顧客の Azure サブスクリプションで委任されたアクセス許可を継承できます。 違いは、これを使用すると、AOBO よりもグループとアクセス許可レベルをより詳細に定義できることです。

このアクセス許可モデルでは、Azure portal UI を使用して正しく設定されているかどうかを簡単に確認できます。 Azure Lighthouse のセットアップが正しいことを完全に検証できるのは、パートナーだけです。

次の手順では、Azure RBAC ロールのアクセス許可が永続的に委任された顧客とグループを特定する方法について説明します。 その後、Azure RBAC 関連付けを持つユーザーがそれらのグループのメンバーであるかどうかをチェックできます。

手順 1 – 顧客に対する Lighthouse の委任を確認する

該当する委任が PEC の対象となる Azure RBAC ロールを使用していることを確認します。

• (パートナーの管理テナントのユーザーと共に) Azure portal を開きます。 次に、"Lighthouse" を検索し、[マイ カスタマー] を選択します。

  

• 顧客の概要で、左側にある [委任] を選択します。 これにより、委任されたアクセスが提供されているリソース (サブスクリプションまたはリソース グループ) の一覧が開きます。

  

• [ロールの割り当て] の下の右側の列で委任を開き、パートナー/管理テナントのどのユーザー グループが各種類のアクセス許可を継承するかを確認します (「ロール」列を参照)。 これらのアクセス許可が永続的かどうかを確認することもできます (「アクセスの種類」列を参照)。

  

手順 2 – グループ メンバーシップを確認する

グループの表示名を選択します。 そうすると、グループの詳細が開きます。 [メンバー] を選択して、Azure RBAC が設定され、それぞれのグループのメンバーであるユーザーを制御します。

手順 3 - ユーザーが Azure PAL を設定したかどうかを確認する

Azure PAL を設定したユーザーのみが Azure PAL 割り当てをチェックできます。他の管理者ユーザーは割り当てできません。 ユーザーが UI または PowerShell を使用して Azure PAL が設定されているかどうかを確認する方法の詳細については、「パートナー 管理 リンク (PAL) を顧客に説明する操作方法を参照してください。Azure アカウントを PartnerID にリンクする」を参照してください。

Note

Azure PAL では、この Azure サブスクリプションの取引パートナーと同じ Microsoft AI クラウド パートナー プログラム組織の一部である PartnerID を使用する必要があります。 間接モデルでは、プロバイダーの PartnerID か、この販売にアタッチされている特定のリセラーのいずれかになります。

手順 4 - 期限付きグループの割り当てを確認する

グループ メンバーシップは永続的ではない可能性があるため、グループが特権アクセス管理に対して有効になっている場合はチェックします。 グループ設定の [アクティビティ] の下の左側にある [特権アクセス] の場所を確認します。 true の場合は、ユーザーがアクティブな割り当てと、この割り当ての期間を持っている場合にチェックします。

Note

割り当ての "終了時刻" はユーザーがグループから自動的に削除されるときであるため、Azure RBAC が設定されているユーザーの PEC は失われます。 同様に、PEC は割り当ての "開始時刻" の後にのみ付与されます。

個々のユーザー割り当てと Azure PAL を確認する方法

場合によっては、Azure サブスクリプションに対するアクセス許可を持つ個々のユーザー アカウントを操作する方が適している場合があります。 これらのアカウントには、(任意のテナントからの) ゲスト ユーザー アカウント、または顧客テナントまたはサービス プリンシパルで作成されたユーザー アカウントを指定できます。

PEC を獲得するための手段として個々のユーザー アカウントを使用する場合、チェックでは、ユーザーの Azure サブスクリプション管理で割り当てられたアクセス許可を確認し、ユーザーが Azure RBAC を正しく設定したことを確認するだけです。 サービス プリンシパルを使用する場合は、PowerShell を使用して Azure RBAC のチェックを行う必要があります。

手順 1 - Azure サブスクリプション管理のアクセス許可を確認する

• Azure Portalを開きます。 少なくとも対象のサブスクリプションへの読み取りアクセス権を持つ Azure RBAC ロールを持つユーザーとしてサインインしていることを確認します。

• 検索バーで "サブスクリプション" を検索して、サブスクリプションの詳細を開きます。

  

• サブスクリプションの詳細で [アクセス制御 (IAM)]に移動します。 次に、[ロールの割り当て] を選択して、サブスクリプション レベルでアクセス権を持つユーザーを確認し、[ロール] 列に PEC の対象となる Azure RBAC ロールが表示されているかどうかを確認します。 リソース グループ レベルでアクセス許可が設定されている場合は、リソース グループ内でも同じ "アクセス制御 (IAM)" ビューを使用できます。

Note

アクセス許可は、Azure RBAC が設定されているユーザーのグループ メンバーシップも検証する必要があるユーザーのグループに付与することもできます。

手順 2 – アクセス許可が永続的であり、拒否割り当てが適用されていないことを確認する

ユーザーがアクセス権を持っているように見えるかもしれませんが、アクセス許可は引き続き一時的なものであるか、拒否割り当てによってブロックされる可能性があります。

Privileged Identity Management (PIM) Azure RBAC ロールの割り当てを使用すると、期限が設定される場合があります。 アクセス許可を持つユーザーが表示される場合がありますが、ユーザーは短時間しか存在しない可能性があります。 Azure RBAC ロールの割り当てが永続的であることを確認するには、Azure portal で PIM 管理をチェックします。 具体的には、サブスクリプション内の Azure リソースが PIM ポリシーによって管理されている場所と、ユーザーがポリシーの対象になっている場合をチェックします。

また、アクセス許可の一覧には、ユーザーがサブスクリプションに対するアクセス許可を持っていることを示している場合がありますが、ユーザーが何かにアクセスするのをブロックする拒否割り当てがある可能性があります。 [アクセス制御 (IAM)]で、[拒否割り当て] タブを選択して、拒否割り当てが適用されるかどうかを確認します。

Note

完全を期す場合、パートナーは、リソース グループに対して、サブスクリプション内に拒否割り当てが存在しないことを確認する必要もあります。

手順 3 - ユーザーが Azure PAL を設定したかどうかを確認する

Azure PAL を設定したユーザーのみが Azure PAL 割り当てをチェックできます。他の管理者ユーザーは割り当てできません。 ユーザーが Azure PAL が設定されていることを確認する方法の詳細については、「Azure アカウントを PartnerID にリンクする」を参照してください。

Note

Azure PAL では、この Azure サブスクリプションの取引パートナーと同じ Microsoft AI クラウド パートナー プログラム組織の一部である PartnerID を使用する必要があります。 間接モデルでは、プロバイダーの PartnerID またはこの販売にアタッチされているリセラーの PartnerID を指定できます。

次のステップ

• パートナー獲得クレジット - 概要
• パートナー獲得クレジットのためのロールとアクセス許可