Symptoms
The following error is being thrown in Exchange and client cannot create email accounts with Exchange 2010 integration.
Standard - Exchange Integration Permissions
-------------------------------------------
Analysis Result: Warning.
The following rights are still required for Impersonation:
- RoleBased Access Control
Select Repair to attempt to grant these permissions. If the permission cannot be granted automatically, you can run the following command from the Exchange command prompt:
new-ManagementRoleAssignment -Role: ApplicationImpersonation -User: "DomainUseraccount"
Duration: 0.5781287 seconds
Diagnoses
Reviewed the client's issue and after testing the EWS URL received an error:
System.Exception: Message: Exception has been thrown by the target of an invocation. Could not connect to the Exchange server. Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. ServiceName: ExchangeMetadataService ServiceGuid: 7d160f9c-fa06-4348-8efe-0ea0cf01ed15 InnerExceptionMessage:
at SourceCode.Workflow.Common.HostedServers.SmartObjects.ExecuteListMethod(SmartListMethod listmethod)
at SourceCode.Workflow.Design.Exchange.ExchangeManagementDataHelper.GetMailboxDatabases(String serverName)
at SourceCode.Workflow.Plugins.Exchange.ExchangeServerItem.AddMailboxDatabases()
Provided client with the following information to configure WinRm:
WinRM is a prerequisite for the K2 Exchange Integration and must be properly configured on the Exchange CAS servers and the K2 Servers. See the following KB article for additional details: http://help.k2.com/KB001189, in the Configuring WinRM section.
The error that was thrown usually points to SPNs. Here is an article on how to create them: http://bretstateham.com/creating-service-principal-names-spns/
This is a pretty good blog that also discusses troubleshooting WinRM:
http://blogs.technet.com/b/jonjor/archive/2009/01/09/winrm-windows-remote-management-troubleshooting.aspx
Once WinRM has been configured you can perform a WinRM remote ping from the K2 Server machine(s) to the Exchange CAS server(s) to verify it's working:
winrm id –r:dCASServerName]
Note that eCASServerName] must be one of the Exchange CAS Servers rather than the Exchange alias. A successful ping will look something like this:
PS C:UsersAdministrator> winrm id -r:dlx.denallix.com
IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 6.1.7601 SP: 1.0 Stack: 2.0
Standard - Exchange Integration Permissions
-------------------------------------------
Analysis Result: Warning.
The following rights are still required for Impersonation:
- RoleBased Access Control
Select Repair to attempt to grant these permissions. If the permission cannot be granted automatically, you can run the following command from the Exchange command prompt:
new-ManagementRoleAssignment -Role: ApplicationImpersonation -User: "DomainUseraccount"
Duration: 0.5781287 seconds
Resolution
WinRM was configured per the information provided and changed the EWS URL to read .local from .com and the issue was resolved.
