Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an Exchange 2003 SP2 FE/BE topology where the company is hosting two separate SMTP domains for two different sub-companies, so I created an additional OWA website as per this article.

Everything works fine: users in the first company access OWA via and users in the second one go through

Now the customer is requesting RPC/HTTPS access for users in the second company, but using the address It doesn't work, because the additional Exchange HTTP Virtual Server in the front-end server doesn't have the required /Rpc virtual directory; howewer, I'm unable to add it: the whole website seems to be managed by Exchange, and if I manually create virtual directories in it via the IIS manager they just don't work (404 error).

Is there any way to implement RPC/HTTPS in an additional web site which is running an Exchange HTTP Virtual Server?

share|improve this question
up vote 0 down vote accepted

Opened a support call with Microsoft and finally got it solved.

The problem is related to Exchange ISAPI filers, which (as I was supposing) intercept all calls to the HTTP Virtual Server and refuse them if asked for some URL that's not managed by Exchange.

Solution: remove the default application mapping to exprox.dll from the non-Exchange virtual directories when you create them via IIS manager. It works for standard virtual directories, and for RPC/HTTPS ones, too.

share|improve this answer

I' ve the same problem. If you export the configuration from the first Virtual Server (in IIS) and you create the new Virtual Server (setting the correct IP), it works (OWA, RPC over HTTPS) The problem is that in this way the Virtual Server is not avaible in the System Manager.

Do you've find an other solution?


share|improve this answer
You should NOT create OWA web sites from IIS; they really need to be managed by Exchange. Why didn't you create it from there? – Massimo Aug 18 '09 at 20:36

Li abbiamo creati da IIS perchè se li creiamo dal System Manager non funziona l'rpc/https. Quello che non riusciamo a capire è da dove deve essere tolta la exprox.dll (se dalla root del sito o dalle subdir) quando crei il secondo sito dal sys manager.

share|improve this answer
Non credo sia opportuno parlare in lingue diverse dall'inglese qui dentro :-) Comunque, io ho semplicemente creato il sito da Exchange (con tutte le virtual directory del caso); poi ho creato a mano le vdir di RPC e da queste ho tolto i mapping a exprox.dll. – Massimo Aug 19 '09 at 9:36

Ok We cannot find the exprox.dll on the RPC VDir (and also RPC with Cert) as you suggest. The exprox.dll is only in the VDir created automatically by System Manager on IIS when we made the second website (ExWeb, Public and so on..)

As I understand, do you find the exprox.dll when you create the RPC VDir on IIS?

share|improve this answer
You can find it as a jolly application mapping, visible by clicking the "Configuration" button in the virtual directory's application settings; the button is disabled is the vdir isn't part of an application pool, but the settings STILL applies, even if you can't see it; you can get to it if you create an application for the vdir (you can remove it after, if not needed). – Massimo Aug 19 '09 at 12:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.