We help IT Professionals succeed at work.

Outlook anywhere fails to connect. Exchange 2019 RPC: 1818 CallCancelled.

Hello.
 Half a year ago i had got Exchange 2013 with RPC over HTTP ( Outlook anywhere) as main protocol.
 One day it failed for all external clients: outlook just wont connect,
 or connects but after 1-3 hours if outside of our corporate network.
 Testconnectivity showed  RPC: 1818 CallCancelled
 I ve tride everything but nothing helped to solve problem.
 
 Ok.
 Ive migrated to Exchange 2019.
 No cas or mailbox servers left from Exchange 2013.
 For nearly a month everything was fine, but one day, suddenly
 Outlook Anywhere failed again.
 Just the same bug and same error  RPC: 1818 CallCancelled.

Deployment: 2 Cas+Mailbox servers (both roles on each server) in DAG.
F5 big ip as router / firewall
SSL Bridging is ON on F5 , SSL offloading disabled in Exchange


Testconnectivity screenshot in attach.
What can i do and how to troubleshoot this bug?
Got any ideas?
Thx in advance.
----------.png
Comment
Watch Question

Michael B. SmithManaging Consultant
BRONZE EXPERT

Commented:
Does MAPI over HTTP work at exrca? That is the preferred protocol for Ex2019.

What version of Outlook is being used?
Edward van BiljonMessaging and Collaboration Technical Lead (Exchange MVP & MCT)
BRONZE EXPERT
Distinguished Expert 2019

Commented:
Did any recent windows updates apply? What CU of Exchange 2019 you running? Have you tried connecting with just Mapi over Http as Michael Suggested?
Saif ShaikhServer engineer
BRONZE EXPERT

Commented:

This is only for the error: An RPC error was thrown by the RPC Runtime process.
Error 1818 CallCancelled


Try this and see if it helps:

=======================


On the Mailbox servers: a DWORD entry needs to be created on each Mailbox server named "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to "1".
Next, the RPCProxy will block access to the DC servers unless there servers are included in the ValidPorts regkey.
So, set the following on the Client Access Servers:
1.The ValidPorts setting at HKLM\Software\Microsoft\RPC\RPCProxy needs setting so that the entries referring to 6004 point to DC servers in addition to the mailbox server.
2.The PeriodicPollingMinutes key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ needs setting to zero to prevent RpcHttpConfigurator from updating the Valid Ports key automatically.
Finally, you need to make sure that the DCs are listening on port 6004:
On the Global Catalog servers: a REG_MULTI_SZ entry needs to be created on each GC named NSPI interface protocol sequences at HKLM\System\CCS\Services\NTDS\Parameters\ and the value set to ncacn_http:6004.
There is 1 last thing to deal with in this SSL-ID load balanced configuration.
Outlook profile creation hard codes a call to DSProxy on 6004.
Which means that we can get split connectivity during profile creation.
To deal with this minimal volume of traffic, there is 1 final regkey that should be set on the mailbox servers:
On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that profile creation should use.
By using only 1 DC for profile creation, all DSProxy calls will be proxied into that single DC, once again avoiding split connectivity.


Apart from the above MAPI over HTTP is also a good feature. So why not use the latest and greatest.

Author

Commented:
Hello.
I've tried this solutinon earlier in Exchange 2013 and it didn't nelped me.
I'll give it a try another one time on todays evening.
Only one question:
>> On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that >> profile creation should use.
I've got no subfolder "parametrs" so i think i should create it?
It is not said here what kind of parametr  "NSPI Target Server" should be : reg_multi_sz ?

As for mapi : it also dosent work normaly. I've got another question about it.

Author

Commented:
>>Does MAPI over HTTP work at exrca? That is the preferred protocol for Ex2019.

Mapi dosent work normaly.
I described it here :
https://www.experts-exchange.com/questions/29174162/Outlook-mapi-synchronization-bug-and-mail-delays.html

>>What version of Outlook is being used?
Outlook 2013 , 2016 , 2019

>>Did any recent windows updates apply? What CU of Exchange 2019 you running?

All updates were made after issue appeared.
Was CU3 , now CU4 with latest security update for CU4.
All windows updates installed.

>> Have you tried connecting with just Mapi over Http as Michael Suggested?
Yes, i've tride. Mapi dosent work normaly also.
Commented:
Ok. I've found my solution.
It was F5 big ip load balancer / firewall.
Today i've exluded it from managing exchange load balancing, and made simple port forwarding
from white real ip to Exchange grey ip for ports 443 and 80.
Outlook connected immideatly, testconnectivety passed.
That's all folks.
Thnx for everyone and have a good day :)