shadow

Access Is Denied Error With Orchestrator Exchange Admin Integration Pack


While implementing System Center 2012 R2  Orchestrator for a client, I encountered this error when trying to setup/test connectivity into their Exchange environment.

So, as all good consultants do, we go to our lab and try to mimic the environment/scenario. So in my lab, I am running System Center 2012 R2 Orchestrator (with no Update Rollups), and Exchange 2013 (even though the client was running 2010).

Even to perform a simple “test” connection, I was following this TechNet article: http://blogs.technet.com/b/privatecloud/archive/2013/06/12/automation-orchestrator-and-the-exchange-powershell-activity.aspx; hence the simple “Get-User” command. And I triple checked to ensure that I followed the configuration steps correctly, as detailed here: http://technet.microsoft.com/en-us/library/jj614529.aspx.

So, when attempting to test a Runbook that involved User AD objects, it also included an Activity for retrieving the User’s mailbox (using the Get Mailbox Activity from the Exchange Admin Integration Pack). However, when running the Runbook with the Runbook Tester, the Get Mailbox activity failed, with the following Error Summary Text:

Error(s) executing PowerShell command: System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server failed with the following error message : [ClientAccessServer=EXCHANGE,BackEndServer=,RequestId=0c197f44-6055-4210-993d-b1593149e876,TimeStamp=2014-05-05 6:13:19 PM] Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.. Inner exception: . Command info: Command name: New-PSSession. Parameters: [ConfigurationName:Microsoft.Exchange],[ConnectionUri:https://exchange.sc.lab/powershell],[Credential:System.Management.Automation.PSCredential],[Authentication:Basic],[SessionOption:System.Management.Automation.Remoting.PSSessionOption]..

Exception: ExchangeGatewayException Target site: ExchangeGatewayBase.CheckErrors

Stack trace: at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.ExchangeGatewayBase.CheckErrors(String commandText, ICollection`1 errors) at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.ExchangeGatewayBase.Execute(ExchangeRequest request) at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.LocalExchangeGateway.CreateRemoteSession(PSObject sessionOptions) at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.LocalExchangeGateway.ImportRemoteSession() at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.LocalExchangeGateway.OpenRunspace() at SystemCenter.IntegrationPack.ExchangeAdmin.Domain.ExchangeGatewayFactory.CreateLocal(ExchangeConfiguration configuration, IActivityLogger logger, Boolean importRemoteSession) at SystemCenter.IntegrationPack.ExchangeAdmin.Activity.RunPowerShellCommandActivity.Execute(IActivityRequest request, IActivityResponse response)

 

Runbook Tester Error2

 

So I searched online using multiple search terms like: “Orchestrator Exchange Admin Integration Pack Issues”, “Error opening remote PowerShell runspace to Exchange”, “ExchangeGatewayException” and “Exchange Admin integration pack access denied”, to name a few. I searched the web for hours and hours, finding information about ExchangeGatewayException, but nothing that specifically referenced the “CheckErrors” element.

Then I came across this across this blog article: http://dynamicdatacenter.wordpress.com/2014/01/15/orchestrator-automate-exchange-actions/.

However, you will notice in that reference article, that the error they were getting was different from mine. BUT, something stood out to me. Take a second look at the second last screenshot. The one showing the Connection Configuration settings. I noticed that in their screenshot, that the Exchange User Name included the DOMAINUsername. That was interesting, since my connection configuration did not. So, I added it.

Exchange Connection Configuration

 

After adding the DOMAINUsername format to the Exchange User Name field, I then re-tested the simple connection Runbook.

I still encountered an error with the Runbook, but this time it was much more helpful.

Runbook Details

Error Details

 

Notice in the Error Details, that it now says “[FailureCategory=AuthZ-CmdletAccessDeniedException] The user “DOMAIN/OU/ServiceAccount” isn’t assigned to any management roles.” That’s much more helpful.

Error(s) executing PowerShell command: System.Management.Automation.Remoting.PSRemotingTransportException: Processing data from remote server failed with the following error message: [ClientAccessServer=EXCHANGE,BackEndServer=exchange.sc.lab,RequestId=f06caef2-2f46-424e-b6ec-b7419150d834,TimeStamp=2014-05-05 5:45:37 PM] [FailureCategory=AuthZ-CmdletAccessDeniedException] The user “SC.LAB/Managed Service Accounts/SCORCH/SCORCH_EXCH_Conn” isn’t assigned to any management roles. For more information, see the about_Remote_Troubleshooting Help topic.. Inner exception: . Command info: Command name: New-PSSession. Parameters: [ConfigurationName:Microsoft.Exchange],[ConnectionUri:http://exchange.sc.lab/powershell],[Credential:System.Management.Automation.PSCredential],[Authentication:Basic]..

Exception: ExchangeGatewayException Target site: ExchangeGatewayBase.CheckErrors

Stack trace: at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.ExchangeGatewayBase.CheckErrors(String commandText, ICollection`1 errors) at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.ExchangeGatewayBase.Execute(ExchangeRequest request) at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.LocalExchangeGateway.CreateRemoteSession(PSObject sessionOptions) at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.LocalExchangeGateway.ImportRemoteSession() at SystemCenter.IntegrationPack.ExchangeAdmin.Gateway.Core.LocalExchangeGateway.OpenRunspace() at SystemCenter.IntegrationPack.ExchangeAdmin.Domain.ExchangeGatewayFactory.CreateLocal(ExchangeConfiguration configuration, IActivityLogger logger, Boolean importRemoteSession) at SystemCenter.IntegrationPack.ExchangeAdmin.Activity.RunPowerShellCommandActivity.Execute(IActivityRequest request, IActivityResponse response)

 

So, since we now have the information that our Service Account isn’t assigned to any Management Roles, we now have a direction to look/correct.

I logged into my Exchange Admin Center, navigated to Permissions, and located a suitable Admin Role to add the Service Account to. In my case, I added it to the Organization Management role, as “Members of this management role group have permissions to manage Exchange objects and their properties in the Exchange organization. Members can also delegate role groups and management roles in the organization.”

I am not an Exchange Administrator, so there could be a more appropriate role to assign it; however, keep in mind that this Service Account will be used to automate any/all Exchange-related Activities from Orchestrator, so it will require sufficient privileges to do so.

Exchange Admin Center

 

After I applied the changes by adding the Service Account to the role, I re-ran the Runbook test again. This time, it was able to successfully complete the simple “Get-User” command against the remote Exchange server. I even tested the connection using SSL and without SSL, and both attempts were successful.

Runbook Success

 

I really hope this post will help someone, as it took me the better part of a day to search, and test to be able to finally come to a solution.

%d bloggers like this: