IBM Support

How to determine the correct RPCHTTPProxyMap_TSM on Exchange 2013

Troubleshooting


Problem

Exchange 2013 introduced a new way to establish connections to MAPI backend by using RPC over http/https personalized connection string.

Symptom

Using IBM Spectrum Protect - Data Protection for Microsoft Exchange Server a mailbox restore operation might fail with error:

ACN0151E Errors occurred while processing the request.

Cause

The RPCHTTPProxyMap_TSM registry key is not set correctly.
Data Protection for Microsoft Exchange Server is designed to automatically build a proper personalized connection registry key but it might be needed to modify the generated registry value manually.
This is also described in the IBM Knowledge Center article "Ensuring successful MAPI connections" (see link below).

Environment

Microsoft Exchange Server 2013

Diagnosing The Problem

Proceed with "Using the TDPMAPI with the TESTMAPI command" (see link below).
If the TDPMAPI TESTMAPI command fails with MAPI_E_NETWORK_ERROR, then this article and its solution might apply.

Resolving The Problem

In complex environments with multiple Client Access Servers (CAS) the following commands can be used to build a proper registry key:


1. How to get personalized Exchange server ID:

whoami | get-mailbox | fl name,alias,exchangeguid,userprincipalname

==========================================================
Name : Administrator
Alias : Administrator
ExchangeGuid : 8d771abc-1ff9-41ce-9e53-fb02535b2470
UserPrincipalName : Administrator@exchdom.local
==========================================================

To get personalized server ID we concatenate ExchangeGUID and the part of UserPrincipalName starting from @:
8d771abc-1ff9-41ce-9e53-fb02535b2470@exchdom.local


2. How to construct the value for RPCHTTPProxyMap_TSM registry key:

2.1. Get output for 'get-outlookanywhere' cmdlet:

get-outlookanywhere | fl server,internalhostname,internalclientauthenticationmethod,iisauthenticationmethods

=================================================================
Server : WS2012EXCH2013
InternalHostname : ws2012exch2013.exchdom.local
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
=================================================================

Make sure that for both InternalClientAuthenticationMethod and IISAuthenticationMethods is set Ntlm authentication.

If it is not, it could be adjusted with the following cmdlets:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod NTLM
Get-OutlookAnywhere | Set-OutlookAnywhere -IISAuthenticationMethods NTLM,Basic,Negotiate

After reconfiguration the IIS servers should be restarted.

Check if InternalHostname is included in the certificate used in Exchange.

2.2. Get Autodiscover response by using the following cmdlet:

Get-ClientAccessServer | Test-OutlookWebServices -Identity <admin mailbox alias>
-MailboxCredential (Get-Credential) | where {$_.Scenario -eq "AutoDiscoverOutlookProvider"} | fl

2.3. Construct registry key value.

Generally, the RPCHTTPProxyMap_TSM registry key has the following format:

=============================
<Domain>=<Proxy Server>,<RpcHttpAuthenticationMethod>,<RpcAuthenticationMethod>,<IgnoreSslCert>
=============================

where:
Registry key part Value source and description
Domain Here we can specify just * wildcard. This should work in any case.
Proxy Server = 'InternalHostname' field from 'get-outlookanywhere' cmdlet output.
The prefix of http:// versus https:// is used to indicate whether an HTTP or an HTTPS connection should be made.
RpcHttpAuthenticationMethod = 'InternalClientAuthenticationMethod' field from 'get-outlookanywhere' cmdlet output.
Basically it should be 'ntlm'
RpcAuthenticationMethod = text for 'AuthPackage' tag from Autodiscover response:
=================================
<Protocol>
<Type>EXPR</Type>
<AuthPackage>Ntlm</AuthPackage>
=================================
Basically it should be 'ntlm'
IgnoreSslCert Configures whether or not the SSL certificate should be validated. Basically should be 'false' if
cmdlet 'Get-OutlookProvider -Identity EXPR | fl CertPrincipalName' returns blank value.


3. General steps to check whether Exchange 2013 RPC/HTTP works

3.1. Check if RPC Proxy server received the RPC/HTTP request.
Open IIS log on CAS server, default position at: C:\inetpub\logs\LogFiles\W3SVC1
Search for the keyword: "/rpc/rpcproxy.dll" and mailbox profile server("ExchangeGUID@domain") string, for example:

2014-06-03 00:01:12 fe80::9143:de1f:df24:f3bb%12 RPC_OUT_DATA /rpc/rpcproxy.dll e4c38a4d-df1a-4f0e-92fd-0e74374685a3@ex2013.com:6001&CorrelationID=<empty>;&RequestId=5ec2722c-03e8-418d-aef0-f8b3cd9ee665&cafeReqId=5ec2722c-03e8-418d-aef0-f8b3cd9ee665; 443 EX2013\SM_a1cffd475d404127b fe80::9143:de1f:df24:f3bb%12 MSRPC - 200 0 64 60637

Result:
a.) If there is no such log entry, the CAS server didn't receive the request at all.
Check network setting and CASServer string in Regkey to see whether CAS server is correctly pointed.
b.) If there is a log entry, but the last 4 digits of RPC_OUT_DATA is "40x ?? ?? ??", the "40x" could be 401,402 or 403:
Check authentication settings. This usually caused by IIS authentication failure.


3.2. Check if RCA receives the request.
Enable RCA "Rops" logging tag by modifying Microsoft.Exchange.RpcClientAccess.Service.exe.config, Restart RPC Client access service.
Open RCA logs, default position at: C:\Program Files\Microsoft\Exchange Server\V15\Logging\RPC Client Access
Search for keyword: "Classic,,,,ncacn_http" and mailbox profile server("ExchangeGUID@domain") string.

Result:
a.) No entry: RCA didn't receive the request.
This case is mostly unlikely if step 1 is successful. Check Exchange server settings.
b.) Error entry:
The error message is human readable and mostly on Exchange server settings, diagnose and fix the error.

[{"Line of Business":{"code":"LOB26","label":"Storage"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSERBW","label":"IBM Spectrum Protect for Mail"},"ARM Category":[{"code":"a8m0z00000006lJAAQ","label":"Data Protection (DP)->Microsoft Exchange"}],"Platform":[{"code":"PF033","label":"Windows"}],"Version":"All Version(s)"}]

Document Information

Modified date:
19 November 2020

UID

swg21688418