Issue activating mailbox using service principal in Azure Automation

[sanjeev40084]

Trying to achieve:
I am trying to setup Azure Automation account with script to be able to activate user's mailbox account. I am trying to use Service Principal which gets created as 'Run As' account to connect to CRM and activate the mailbox. At the end, i am trying to invoke this Azure Automation runbook from Power Automate with the parameters of 'CRM Instance URL' and 'User Email Address'. Whenever we need to activate user's mailbox, we will then execute Power Automate, pass in CRM instance url and user email address, which will invoke Azure Automation, use service principal to authenticate against crm and activate the email address.

Issue:
The issue i am running into is, i am unable to activate the mailbox using the client secret connection. It executes but even though it fails to activate mailbox (verified by going to crm and checking user's mailbox), it doesn't throw any error message. I can replicate this behavior both in Azure Automation and locally using the client-secret.

Steps To replicate:

1. Create new Azure Automation, keep the option to create run as account (this will create service principal which we can use later to connect to CRM)
2. In Module gallery, import Microsoft.Xrm.Data.Powershell
3. Go to app registration , search for service principal that was auto created and add client-secret. (Copy the value of client-secret)
4. In Api permission, add permission for Dynamics CRM
5. In CRM, add the new application user, with the same application id as Service Principal application Id. Grant it service administrator security role.
6. In Azure portal, go to Active Directory and assign Exchange administrator role to Service principal application id.
7. Go back to Azure Automation and add new runbook with this script:

$url = "crm instance url"
$emailAddress = "email address"
$timoutInSeconds = 1000

try 
{
   $conn = Connect-CrmOnline -ServerUrl $url -ConnectionTimeoutInSeconds $timoutInSeconds -OAuthClientId '<service- 
   principal- application-id>' -ClientSecret '<client-secret>'   

  if($conn.IsReady)
  {
      $CRMuser = Get-CrmRecords -EntityLogicalName systemuser -FilterAttribute domainname -FilterOperator "eq" -FilterValue 
                           $emailAddress -Fields * -WarningAction Continue -ErrorAction Stop
      $userId = $CRMuser.CrmRecords.systemuserid
      Set-CrmUserMailbox -conn $conn -UserId $userId -StateCode Active -StatusCode Active -ScheduleTest - MarkedAsPrimaryForExchangeSync -ApproveEmail    
  
      Write-Output 'Mailbox activated'
  }
}
catch
{
   Write-Output 'Error'
}

6. Run the runbook, the script runs successfully, but when you go to crm and verify the user mailbox, you will see it has not be activated successfully.

If you run the same script locally, you will see the same behavior.

Any suggestion what i am doing wrong here?
Sanjeev

[seanmcne]

To approve a mailbox I we have historically required an account have the Global Admin role to approve. I would suggest taking a look at any feedback that is currently out there around this topic and if not, please create a feedback item. I think other customers have expressed the desire to automate this function or enable users who are not necessarily global admins to approve and this is another good example.

[seanmcne]

Also check this out: https://docs.microsoft.com/en-us/power-platform/admin/connect-exchange-online#add-approve-email-addresses-for-users-or-queues-privilege

[sanjeev40084]

Also check this out: https://docs.microsoft.com/en-us/power-platform/admin/connect-exchange-online#add-approve-email-addresses-for-users-or-queues-privilege

Thanks Sean. Based on the doc, looks like Exchange admin with System admin role can approve email address but you might be right, it does require Global admin rights to activate the mailbox.

On side note, as i mentioned in my original post, the script to activate mailbox when used with client secret, doesn't return any error message even though when it fails to activate mailbox. When the same script is ran where user is prompted to login, if the user don't have right role, it throws valid error message.

[seanmcne]

Unfortunately I'm not sure why the API doesn't return an error, I don't recall an error being thrown if a user who is not a global admin tries to activate a mailbox using powershell. In the webUI it shows the result of the activation attempt, but I think when scheduling a test/enable with powershell you also need to query the mailbox again to see if anything happened (success or failure).

[sanjeev40084]

thanks to this article, found the missing step for my issue. basically, i needed to assign additional Exchange.ManageAsApp API permission in my service principal and apparently you can't do that through UI and can only be done from powershell :(

$AppID = "Enter your Application (Client) ID here"
$ExchangeOnlineObjectID = (Get-AzureADServicePrincipal -Filter " AppId eq '00000002-0000-0ff1-ce00-000000000000'").ObjectID
$ExchangeRightsID = "dc50a0fb-09a3-484d-be87-e023b12c6440"
$ServicePrincipalID = (Get-AzureADServicePrincipal -Filter "AppId eq '$AppID'").ObjectId 
New-AzureAdServiceAppRoleAssignment -ObjectId $ServicePrincipalID -PrincipalId $ServicePrincipalID -ResourceId $ExchangeOnlineObjectID -Id $ExchangeRightsID

[seanmcne]

Excellent! I didn't even realize that was an option - this is super helpful/valuable!