Руководство по устранению неполадок с партнерскими баллами

Соответствующие роли: глобальный администратор | администратор управления пользователями | агент по администрированию | администратор выставления счетов | агент по продажам

Распространенные сценарии устранения неполадок

Благодаря новому коммерческому интерфейсу Azure партнеры могут получать скидки через партнерский заработанный кредит (PEC) для управляемых служб. PEC предоставляется только партнерам с соответствующими разрешениями. Узнайте, кто имеет право на получение PEC, как он вычисляется, и как он оплачивается.

В этой статье приведены основные рекомендации по устранению неполадок, если PEC не предоставлен.

Необходимые компоненты

Если у вас возникли проблемы с PEC, например доступ к данным или отсутствующие сведения, начните с проверка следующих элементов.

Примечание.

Только косвенные поставщики и партнеры с прямым выставлением счетов имеют право на получение PEC.

• Убедитесь, что вы просматриваете счет G (новый коммерческий интерфейс) и файл рекогносцировки. План Azure и PEC не отображаются в счете D (устаревшей версии) или файле рекогносцировки.

• Убедитесь, что ваше соглашение microsoft AI Cloud Partner Program активно.

• Убедитесь, что ваше предложение соответствует требованиям. (Устаревшие предложения Azure, зарезервированные экземпляры Azure, планы экономии Azure, виртуальные машины Azure SPOT и сторонние продукты не имеют права.)

• Убедитесь, что у вас (или косвенного торгового посредника, установленного в качестве торгового посредника записи в плане Azure), есть действительный Администратор ister от имени (AOBO) или роли управления доступом на основе ролей Azure (Azure RBAC) для подписки, группы ресурсов или ресурса. Еще один вариант:

  • Если вы используете Azure Lighthouse, убедитесь, что ваш PartnerID связан по крайней мере с одной учетной записью пользователя. Кроме того, проверка, что он имеет доступ к этой подписке или группе ресурсов клиента.
  • Если вы используете ассоциацию Azure RBAC, убедитесь, что пользователь имеет доступную роль для PEC и Azure RBAC в каждом контексте клиента.

• Проверьте, удалил ли клиент разрешения AOBO. Разрешения были заданы по умолчанию при подготовке плана Azure. Если они удалены, ознакомьтесь с правами администратора Повторного заполнения для подписок Azure поставщик облачных решений (CSP).

• Убедитесь, что у вас есть доступ администратора на весь день.

• Убедитесь, что вы просматриваете правильные столбцы в файлах сверки. Дополнительные сведения см. в статье о выставлении счетов в плане Azure: о файле выверки счетов.

Сценарии с несколькими частями

Для PEC важно только установить любой из доступных параметров разрешения для партнера по транзакциям. Для косвенной модели это может быть поставщик или торговый посредник или оба.

Другой партнер, задающий дополнительные разрешения AOBO или другие разрешения, а также дополнительные параметры Azure RBAC для пользователей с разрешениями Azure RBAC, не влияют на PEC для партнера по транзакциям.

См. следующую таблицу. MPN1 является косвенным поставщиком, MPN2 является косвенным торговым посредником, связанным с транзакцией в качестве торгового посредника записи, и MPN3 является другим партнером CSP (прямым или другим косвенным торговым посредником):

Партнер по транзакциям (BillTo)	Azure RBAC (для пользователя или Lighthouse с соответствующей ролью PEC)	AOBO (доступная роль 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	Н/П	No
MPN1	Н/П	MPN3	No
MPN1	Неприменимо	Неприменимо	No
MPN1	MPN3	MPN3	No

Передачи подписок Azure

Когда партнер передает подписку Azure или другому партнеру, разрешения на эту передачу не изменяются.

Таким образом, если перед передачей использовался AOBO или другая модель разрешений, то после передачи разрешения, заданные для старого "партнера по транзакциям", разрешения по-прежнему указывают на старого партнера после передачи. Но теперь другой партнер становится "трансактным партнером".

Для передачи подписок Azure рекомендуется добавить разрешения нового целевого партнера, например Azure RBAC, перед передачей. Они могут безопасно сделать это, не затрагивая PEC старого партнера до передачи.

Обновления PartnerID

Центр партнеров позволяет изменить Идентификатор партнера, связанный с регистрацией CSP. Обновление PartnerID до другого идентификатора расположения программы Microsoft AI Cloud Partner Program в той же глобальной организации Microsoft AI Cloud Partner Program (другая идентификатор расположения Microsoft AI Cloud Partner Program в соответствии с тем же глобальным идентификатором программы Microsoft AI Cloud Partner Program) не влияет на PEC.

При изменении Идентификатора партнера на идентификатор расположения в другой организации Microsoft AI Cloud Partner Program может повлиять на PEC. В этом экземпляре, а когда PEC отсутствует, рекомендуется обратиться в службу поддержки (упоминание недавно перенаправили регистрацию CSP на другую организацию Microsoft AI Cloud Partner Program).

Проверка разрешений AOBO

Когда партнер создает подписку плана Azure для клиента, AOBO устанавливается в виде "внешнего участника". Внешний субъект наследует разрешения владельца в подписке Azure. Разрешения AOBO означают, что определенная группа в клиенте Центра партнеров CSP (Администратор агенты) наследует эти разрешения.

Внешний субъект, как показано в портал Azure, не содержит подробные сведения о той группе, с которой она сопоставляется в конкретном клиенте партнера.

При просмотре внешнего участника в портал Azure отображается имя партнера, например "Внешний субъект для Contoso" ...", но "Contoso" — это только отображаемое имя клиента Microsoft Entra партнера, и это не уникально.

Использование AZ PowerShell или Azure CLI требуется для проверки правильности 100% того, что AOBO задан правильно, указывая на правильную группу в правильном клиенте CSP.

Шаг 1. Определение идентификаторов объектов групп агентов партнера по транзакциям

• Через портал Azure: партнеры могут войти в портал Azure в своем клиенте и найти соответствующие группы в группах идентификаторов > Microsoft Entra. Объектный идентификатор отображается справа от имени группы.

• С помощью PowerShell: запустите PowerShell (локальная среда PowerShell или Azure Cloud Shell).

Прежде чем использовать Azure Cloud Shell, необходимо настроить учетную запись хранения. Эта учетная запись будет нести небольшую ежемесячную стоимость в подписке Azure, доступной в контексте клиента. Вы можете удалить общую папку после описанных ниже действий.

Примечание.

Модули Azure AD и MSOnline PowerShell устарели с 30 марта 2024 г. Дополнительные сведения см. в обновлении об отмене. После этой даты поддержка этих модулей ограничена поддержкой миграции в пакет SDK Для Microsoft Graph PowerShell и исправления безопасности. Устаревшие модули будут продолжать функционировать до 30 марта 2025 года.

Рекомендуется перенести в Microsoft Graph PowerShell для взаимодействия с идентификатором Microsoft Entra (ранее — Azure AD). Часто задаваемые вопросы о миграции см. в разделе "Вопросы и ответы о миграции". Примечание. Версии 1.0.x MSOnline могут возникнуть сбоем после 30 июня 2024 г.

Убедитесь, что установлены и обновлены следующие модули до последней версии:

• Модуль AzureAD
• Модуль AZ PowerShell (не требуется для Cloud Shell)

При необходимости выполните следующие действия cmdlets из Windows PowerShell для установки этих модулей:

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

Сначала подключитесь к клиенту Центра партнеров с учетной записью пользователя Центра партнеров и получите идентификаторы объектов группы Администратор Agents и HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Войдите с помощью учетных данных Центра партнеров:

Запросите сведения о группах агентов:

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

Группы ObjectID будут отображаться вместе с именами:

Примечание.

Если вы не получите результат, убедитесь, что вы подключились к учетной записи Центра партнеров.

Примечание.

Непрямые торговые посредники не увидят группу SalesAgents. Этот шаг необходимо выполнить только один раз, так как AOBO в каждом клиенте будет использовать одни и те же идентификаторы.

Шаг 2. Сравнение идентификаторов objectID с теми, которые используются внешним субъектом

Важно использовать TenantID в качестве значения параметра клиента (а не имени домена клиента) с учетной записью пользователя, которая либо: имеет доступ к нескольким каталогам и клиентам, таким как учетная запись пользователя Центра партнеров, или добавлен в качестве гостей в несколько клиентов.

Таким образом, вам нужен идентификатор клиента для данного клиента.

• С помощью портал Azure: идентификатор клиента можно легко получить из списка клиентов в Центре партнеров. Идентификатор клиента помечен как Microsoft ID:

  

• С помощью PowerShell: Подключение в подписку Azure клиента с допустимыми учетными данными. Учетные данные должны иметь разрешение на чтение подписки Azure и AzureAD клиента:

  Connect-AzAccount -Tenant $CustomerTenantID
  

  • Чтение назначений ролей для внешнего участника подписок Azure клиента:

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

  

  • Результирующий объект должен соответствовать ОбъектИД группы Администратор Agent или HelpDeskAgent, определенной на шаге 1.

Итоги

Каждый аспект должен соответствовать до получения PEC через AOBO:

• Подписка Azure клиента имеет внешний субъект с соответствующим назначением ролей RBAC Azure.
• ObjectID группы, используемой внешним субъектом, относится к ObjectID группы Администратор Agent или HelpdeskAgent в клиенте партнера.
• "Клиент партнера" означает прямой клиент партнера по выставлению счетов. В косвенной модели это означает косвенный поставщик или косвенный клиент партнера торгового посредника.

Примеры сценариев

В этом разделе содержатся примеры скриптов, которые помогают собирать сведения в нескольких подписках и хранить их в . CSV-файл. Эти скрипты предназначены в качестве примеров и предоставляются как доступные без поддержки. Хотя скрипты не вносят изменения в настройку, их следует тщательно протестировать, а для конкретного сценария партнера или клиента может потребоваться настройка.

• Описание сведений AOBO для одного клиента: в этом примере используется идентификатор Microsoft Entra и модули 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) были проданы и которые доступны с текущими учетными данными.
  • Для косвенных торговых посредников этот сценарий также работает. Но все подписки будут иметь примечание "не продано", даже если они партнер записи для этой продажи.

### 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. Только партнер может предоставить полную проверку правильности настройки Azure Lighthouse.

В следующих шагах описывается, как определить, для каких клиентов разрешения роли Azure RBAC были окончательно делегированы и к каким группам. Затем вы можете проверка, если пользователь, имеющий связь Azure RBAC, является членом этих групп.

Шаг 1. Проверка делегирований Lighthouse на клиентах

Убедитесь, что применимые делегирования используют соответствующие роли Azure RBAC.

• Откройте портал Azure (с пользователем из клиента управления партнера). Затем найдите "Lighthouse" и выберите "Мои клиенты".

  

• В обзоре клиента выберите "Делегирования " слева. При этом открывается список ресурсов (подписок или групп ресурсов), в которых предоставлен делегированный доступ:

  

• Откройте делегирования в правом столбце в разделе "Назначения ролей", чтобы узнать, какая группа пользователей в клиенте партнера или управления наследует все виды разрешений (см. столбец Role). Вы также можете узнать, являются ли эти разрешения постоянными (см. столбец Access Type):

  

Шаг 2. Проверка членства в группах

Выберите отображаемое имя группы. Откроется сведения о группе. Выберите "Участники", чтобы контролировать, какой пользователь имеет набор RBAC Azure и входит в соответствующую группу:

Шаг 3. Проверка того, настроил ли пользователь Azure PAL

Только пользователь, который установил Azure PAL, может проверка назначение Azure PAL; ни один другой пользователь не может сделать это. Дополнительные сведения о том, Разделы справки Администратор как пользователь может проверить, настроен ли azure PAL, в разделе "Связать учетную запись Azure с PartnerID", чтобы получить дополнительные сведения о том, как пользователь может проверить, настроен ли azure PAL с помощью пользовательского интерфейса или PowerShell.

Примечание.

Azure PAL должен использовать PartnerID, который входит в ту же организацию Microsoft AI Cloud Partner Program, которая является партнером по транзакциям для этой подписки Azure. В косвенной модели, которая может быть PartnerID поставщика или конкретного торгового посредника, присоединенного к этой продаже.

Шаг 4. Проверка назначений групп с привязкой к времени

Так как членство в группах не может быть постоянным, проверка, если группа была включена для управления привилегированным доступом. Найдите расположение "Привилегированный доступ" в левой части в разделе "Действие" в параметрах группы. Если значение true, проверка, если у пользователя есть активное назначение и интервал времени для этого назначения.

Примечание.

Так как назначение "время окончания" происходит при автоматическом удалении пользователя из группы, PEC будет потерян для пользователей с набором RBAC Azure. Аналогичным образом PEC будет предоставлен только после назначения "время начала".

Как проверить назначение отдельных пользователей и Azure PAL

В некоторых случаях может оказаться более подходящим для работы с отдельными учетными записями пользователей с разрешениями на подписки Azure. Эти учетные записи могут быть гостевыми учетными записями пользователей (из любого клиента) или учетными записями пользователей, созданными в клиенте клиента или субъектах-службах.

При использовании отдельных учетных записей пользователей в качестве транспортного средства для получения PEC проверка включает только проверку назначенных разрешений в управлении подписками Azure для пользователя и проверку правильности установки Azure RBAC. При использовании субъекта-службы проверка azure RBAC необходимо выполнить через PowerShell.

Шаг 1. Проверка разрешений в службе управления подписками Azure

• Откройте портал Azure. Убедитесь, что вы вошли в систему как пользователь с ролью Azure RBAC с по крайней мере доступом на чтение к подписке.

• Найдите "Подписки" в строке поиска, чтобы открыть сведения о подписке:

  

• Перейдите в раздел "контроль доступа (IAM)" в сведениях о подписке. Затем выберите "Назначения ролей", чтобы просмотреть пользователей, имеющих доступ на уровне подписки, и если в столбце "Роль" отображаются соответствующие роли Azure RBAC. Если разрешения заданы на уровне группы ресурсов, то в группе ресурсов также доступно то же представление "контроль доступа (IAM)".

Примечание.

Разрешения также можно предоставить группе пользователей, где необходимо проверить членство в группе пользователя с набором RBAC Azure.

Шаг 2. Убедитесь, что разрешения являются постоянными и что не применяются назначения запрета

Хотя у пользователей может быть доступ, их разрешения по-прежнему могут быть временными или заблокированы с помощью назначений запрета.

Назначение роли Azure RBAC с помощью управление привилегированными пользователями (PIM) может быть привязано к времени. Хотя пользователи могут видеть разрешения, они могут существовать только в течение короткого времени. Чтобы убедиться, что назначение роли Azure RBAC является постоянным, проверка администрирование PIM в портал Azure. В частности, проверка, где ресурсы Azure в подписке управляются политиками PIM, и если пользователь подлежит любым политикам.

Кроме того, список разрешений может показать, что у пользователя есть разрешения на подписку, но могут быть запреты назначений, которые по-прежнему блокируют доступ пользователя к чему-то. В разделе "контроль доступа (IAM)" выберите вкладку "Запретить назначение", чтобы узнать, применяются ли назначения запрета:

Примечание.

Для полноты партнеры также должны убедиться, что в группах ресурсов в подписке отсутствуют назначения запретов.

Шаг 3. Проверка того, настроил ли пользователь Azure PAL

Только пользователь, настроивший Azure PAL, может проверка назначениям Azure PAL; ни один другой пользователь не может сделать это. Дополнительные сведения о том, как пользователь может проверить, настроен ли Azure PAL, см. в статье "Связывание учетной записи Azure с PartnerID".

Примечание.

Azure PAL должен использовать PartnerID, который входит в ту же организацию Microsoft AI Cloud Partner Program, которая является партнером по транзакциям для этой подписки Azure. В косвенной модели это может быть PartnerID поставщика или PartnerID торгового посредника, присоединенного к этой продаже.

Следующие шаги

• Общие сведения о партнерских баллах
• Роли и разрешения, доступные за партнерские баллы