We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


Poor performance with RPC over HTTP

habanagold asked
Medium Priority
Last Modified: 2010-05-18
Testing Lab as follows:

Exchange 2003 Server - 1.8G Intel Celeron, 768MB RAM, plenty of disk space.
Running in a single Exchange Server,back-end setup for RPC over HTTP. Using SSL and OWA via HTTPS works very well.
Bandwidth is business grade cable, 5M/2M.

I have successfully implemented the rpc over http single, back-end server configuration. My Outlook 2003 client can connect and was validated. However, initially, I could open another user's calendar and send mail but have not been able to do so since the first connection. I get error messages stating that the connection to the Exchange server is unavailable. Outlook must be online or connected to complete this action. Also, I have mail stuck in my outbox now that won't go out when it did before.

Does my server and network bandwidth provide enough "horsepower" to run rpc over http? Also, the only way I was able to connect in the first place was to put my Exchange server in the DMZ of my firewall. I tried opening ports 6000-6004 but this apparently wasn't enough. I couldn't make a connection until I exposed all the ports of the Exchange Server.

My follow-up question is, what ports are needed in order to allow rpc over http to work without exposing the entire system?
Watch Question

"I couldn't make a connection until I exposed all the ports of the Exchange Server"

For rpc over https the ONLY port you need open is 443. If you have to open other ports, something is not right.

How is the performance on the lan? I must admin a Celeron 1.8 with 768MB of ram sounds rather flimsy for an exchange server. You mentioned pleanty of disk space, what kind/speed are the disks? How many mailboxes does this server support? I have a single exchange 2003 server running 200 mailboxes on a dual 3ghz xeon with 4gb of ram and 15k rpm u320 scsi disks and over 3mb Ts, and when using RPC over HTTPS and not in cache mode I notice some lag when using outlook.  

Hi habanagold,

You have not configured RPC/HTTPs properly, my bet is that your certificate is wrong.

Here is a guide from Sembee, and a guide from Petri on how to configure the client side.



You don't need to open ports 6000-6004 on your router/firewall. And you don't need to put the Exchange server inside your DMZ. The only port you need to open are ports 443.

Also, you running Windows 2003 operating system and Exchange 2003 on server with 1.8G Intel Celeron, 768MB RAM. I wouldn't run Windows XP Pro on such a hardware, instead I run Red Hat or Suse Linux or Fedora 5.0 on this hardware.

If it doesn't work from outside the LAN, then most likely it is not really running on https from within your LAN. There is a setting in OUtlook 2003, which will cause the outlook to use MAPI protocol when you are inside the LAN, even when you configure your outlook profile to use RPC over HTTPS.

I have two several questions.
1. Did you install a SSL certificate from a Public CA?
2. Did you configure your GC server?

Read this article very carefully, and pay attaention to what it says about configuring your GC server.
Most people who attempt to configure Exchange 2003 RPC over https feature fail to install a SSL certificate from a public CA and they don't even bother to configure the GC server.

Here are links to two webpages from one great website. It will tell you step by step what you need to do. Read it very carefully.
Campare the steps that it gives you and what you have done already. Follow his instructions very carefully and RPC over https will work.


Another thing, if you have single domain forest. Make all your domain controllers are GC (global catalog) servers. This is done from active directory domains and trusts.

I also want to point out to you why this sentence is in BOLD on the first webpage. Make sure you configure the registry key on your GC servers. And also use the rpccfg tool to confirm the port settings like he shows you. Read this sentence very carefully. You will fail if you do not listen to what he is saying. "Configure all your global catalogs to use specific ports for RPC over HTTP for directory services"  quote by Daniel Petri.



I will follow up on all suggestions, but I will say that I used my own Certificate Server to issue the SSL for my server. (They don't have a budget for this.) It seemed to work fine. I have read some issues about the NetGEAR FSV114 VPN Firewall I am using and that no matter what I do, this fiewall is inadequate for such a busy proposition as rpc over http.

Performanc on the LAN is excellent and I as I stated earlier, OWA over the Internet using SSL works great. In fact, if anyone would like to check this out go to https://mail.trottergrp.com/exchange and tell me what you think. I don't mind providing the name since this is just a domain for testing.

My Exchange Server  has been configure with registry settings recommended from Sembee @http://www.experts-exchange.com/Networking/Email_Groupware/Exchange_Server/Q_22044388.html.

My 2 domain controllers are both Global Catalog Servers. I would make the change with the Firewall to test but according to everything I read, I thought more ports would have to be open than SSL.

Also, this is a testing environment so if specifications are inadequate, then that is what I am trying to determine before my company makes its move from outsourced pop mail to in-house Exchange. I am very constrained by budget so I have to work with what I have. In fact, my whole testing lab is my personal equipment because they don't have a budget for such.

There is nothing wrong with using your own certificate, it will work fine - the only problem is that you will need to configure it properly, by which I mean manually.

The only ports you need open to your Exchange server is 25 and 443 (25 for mail, 443 for OWA and RPC/HTTPs)

You see how that site prompts you for a certificate?  That will break RPC/HTTP - but there is a way to fix it, you have to install the certificate manually (and install it to the Trusted Root CAs area)

I am writing a guide on doing this now, I suppose now you have given me a reason to hurry up a bit :)



Well I've gone from poor connection to no connection. I am a bit confused by all the suggestions. NITADMIN states no other ports need to be opened other that 443 while other have suggested that ports for RPC/HTTPs need to be opened. From the information provided, I assumed that the RPC/HTTPs ports were user defined per firewall and I assumed that they were from what I read. Don't these have to be opened for 2-way traffic?
•      Microsoft Exchange Information Store service (port 6001)
•      The referral service of DSProxy within the Exchange system attendant service (port 6002)
•      DSProxy service within the Exchange system attendant service (port 6004)

At any rate, I had other emgencies come up today and not too much time to devote to this. As I have stated before OWA via HTTPS is working fine. Doesn't this a least indicate that something it setup correctly?

The ONLY ports you need open on your exchange server is 443 and 25.

25 is for mail, 443 is for OWA, RPC/HTTPs, and everything else.

6001-6004 need to be open between your exchange server and the domain controller - that is all

You do NOT need to open these ports to the world


Test it from inside the network, close outlook and then > Start > Run > outlook /rpcdiag

I would bet that it is saying it is connected with TCP/IP, meaning that RPC/HTTPs is NOT working.

Install the certificate on the local computers, and make sure you have configured it properly - poor connectivity makes me wonder if your Registry entries on the DC are correct.




Sorry for not getting back to everyone. Lot's of emergencies have occured since working on this that needed to be attended to.

I took Red's advice and it looks as though I don't have RPC/HTTPS setup correctly because I cannot connect inside the network over this method. Guess I am going to have to start all over from scratch.

However, I thought I followed the info to the letter from the previous posts so if anyone has any ideas on how to start over and get this working, I am all ears.

There are a few places that this fails,

Most common is certificate problems, then registry problems.

On the machine that cannot connect, if you browse to https://servername/rpc do you get a certificate box pop up?

You need to install that certificate;

Click View Certificate > Install Certificate > Next > Browse > Show Physical Stores > Trusted Root Certification Authorities > Local Computer > OK > Next > Finish

Then try it again from inside the office,



Finally getting back to this. When I use https://servername/rpc inside the network I can connect, although I get a series of warnings stating that the certificate doesn't match the server I am connecting to and do I wish to continure. I assume this is because I created a certificate called "mail.domain.com" and I am not accessing the server by that name. If I do, I do not get the warning messages.

However, I must clear up something now that may be the problem. My DC's are W2K, not W2K3. When reviewing amset link by red, I noticed that I may need to install RPC Proxy service on my DC's. I don't find this available for W2K DC's. Is this where the problem is? I noticed in my environment that I presented, I never stated what DC's I had.

Do you need to have W2K3 DC's as well in order for this to work?
Yes, you need a 2k3 DC as well.

Sorry, you are in the same boat I was



Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


Thanks Red. I don't know where I missed this to begin with. Poor documentation by Microsoft; assumptions that everyone is using W2K3 everywhere for everything. We are a small company and it was pulling teeth just to get a new server and W2K3.

I am so sorry to have wasted everyone's time including my own with trying to get something to work that was never designed to do so. Since Red gave the correct answer, I am awarding him the points.

If I had know this earlier, I would have simply moved to a VPN solution for my Outlook Clients
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.