OMA on SBS2003 working alongside OWA

Hi All,
I'm trying to get my head round getting OMA up and running. I've already looked at and the VDir seems to be setup already, as per the KB.
I've currently got the original 'companyweb' Sharepoint, WSS3, and OWA running. OWA uses SSL and FBA with no problems. This is accessed externally by
In IIS, there is a redirect on the Default Website to "/Exchange"
Under the 'Multiple Identities for this website' it's set to:
 "(all unassigned)", TCP 80, blank host header
 "(all unassigned)", TCP 80,
And at the bottom it says "(all unassigned)", 443

On a website called "IntranetWSS3", there's the following:
Under the 'Multiple Identities for this website' it's set to:
 "(all unassigned)", TCP 80, 'intranet'

exchange-oma is set to 'integrated windows' and 'basic authentication', default domain set to '\'.

When trying to access OMA externally via "", I get, "HTTP Error 403, You are not authorised to view this page".

Any ideas, experts?


I can access OMA with no problems on the internal network. Both http://servername/oma and https://servername/oma work fine.
Who is Participating?
scriptaholicConnect With a Mentor Commented:
if in doubt, i suggest you first run the internet connection wizard to confirm permissions and certs etc are all setup ok. SBS is pretty self managing for owa/oma and needs no customisation of directories, structure, permissions etc  (if you do, youll most likely break it) i have forund in the past that this wizard has fixed issues generated by changing settings.

if you can stop and start the default site and it does so sucessfully it means there is no conflict with the ports & header information specifiedwith any other website. If there is no conflict then as you are using "all unassigned" port 80, with a blank host header it should be working.

i would try the same stop and start after setting the "unassigned" ip to your servers ip, as natp'd by the router, then stop and start. this will confirm that no other service or site is incorrectly using the port/host header combo. but i suspect it is fine as you say owa is working fine.

try the connection wizard first.
I struggled with these issues until I finally obtained a third party SSL cert (GoDaddy, Thawte, Verisign, etc.) for the site. If you are using ISA with SBS, all the necessary ISA rules get created automatically if you do the cert request from IIS Manager but do the import of the completed cert via ISA.
jonnyITAuthor Commented:
Not using ISA as it's just plain ole SBS2003 Standard (not premium). The OMA side of things is set to not requires SSL and I don't think it likes to use it anyway.
I don't think my the problems are with certs, although I am using a self-signed one.
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

jonnyITAuthor Commented:
ok cheers for the advice. I'll give it a go tomorrow.

I remember the wizard messed up the redirects to the exchange directory for owa when I last ran it. That's why I leave it as a last resort rather than the first thing to try. I need more confidence in the wizards!
i havent had any problem generated from running the wizard, and have often used as a "check" to make sure all is setup correctly. especially owa/oma/ companyweb access controls page & the certificate.

please post if it does cause any issue at all.
jonnyITAuthor Commented:
Just a check, but would you normally wait for all users to be logged off, before running CEICW?
jonnyITAuthor Commented:
Just ran CEICW and there was indeed an option in there for allowing access to OMA from web! All working nicely now.

Enabled that and everything's fine. Nothing else was messed up either, so cheers for your help!

jonnyITAuthor Commented:
Just a note:

It DID mess something up, although it was easy to fix. I had a call from one of our remote workers as soon as I had run the wizard, saying Outlook was asking him for a username and password and wouldn't accept anything. He connected via RPC over HTTP.

Turns out that in the Rpc directory on IIS, the "Integrated Windows Authentication" box had become unticked. A quick tick and we were away.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.