Same URL for Exchange 2010 OWA, ActiveSync, AutoDiscover, ECP, and RPC

I'm about to undergo a major migration from Exchange 2003 to 2010.  Up until now, my organization has used the same URL ( for all of the Exchange services - OWA, RPC, ActiveSync.  I'm reading some articles that have led me to believe that this setup may not be possible in Exchange 2010.  I have successfully been able to redirect the default website in IIS to the OWA directory to simplify the OWA URL in 2010, but will this cause the other virtual directories to stop working properly?  I have configured my test environment according to this article.  Is it possible to have one URL for all of the CAS services in Exchange 2010?  If so, how do I make it happen?
Who is Participating?

Improve company productivity with a Business Account.Sign Up

Bruno PACIConnect With a Mentor IT ConsultantCommented:
Ok, sorry for the misunderstanding.
My english is quiet poor.

Well. In a standard Exchange installation (I mean an installation with no specific settings other than those done by the installation process) the OWA web site does not take care of the URL used to reach the site, so whatever you use in the HTTPS://blahblahbla/owa if "blahblahblah" resolve to the correct IP it works (except the certificate security warning of the name does not match the URL).

So probably something has been done on your IIS settings to restrict the URL to match the hostname.

Before doing any modification on IIS can you try something to help locate the trouble:

what happens if you use the CAS IP address in the URL instead of the servername ? Try an OWA access through the URL from the internal network please. You may have a certificate security warning but if you accept to proceed do you reach the OWA web page ? Does the URL in the address bar has been changed ?

OWA 2010 internal code use some page redirect that use InternalURI value to redirect the client to some part of the site (ecp, OAB, etc...). So yes it's important the InternalURI to be well configured.
If you have a CAS Array with NBL or HLB, you then have a VIP associated to the NLB. Should have create a DNS name that is associated to the VIP. And yes this name should have been configured as the InternalURI on every virtual directory.

What is surprising me is that ususally problem with bad internalURI only appear when you click on some part of the OWA wbe page when you are on your mailbox. As an example you may be unable to reach the "Options" page... But usually the logon form can be reach and the mailbox content is shown.

What you describe is a failure in getting the authentication form.

Anyway, because of my bad understanding of your problem initially I thought you were talking about modifying virtual dirs properties in IIS, what is quiet "dangerous".
But modifying URI using Exchange Management Shell commands is "safe". Saying "safe" I mean that Exchange will not destroy the virtual dirs and then you'll alwayd be able to get back to the previous state by using the same cdmlets to reapply previous settings. So it's not "dangerous".

About DNS, in fact you already have a splitted DNS cause your internal domain name is the same that external domain name, but I supposed internal IP addresses are on a private IP range while external IP addresses for public names are in public IP ranges.
So the externally resolved "" DNS name wil externally resolve to a public IP address while the "webmail" DNS record you'll create in your internal DNS zone will resolve internally to a private IP address. This is the definition of a splitted DNS.

So, if you take time to note the current InternalURI on each Exchange virtualdir on each CAS server so that you'll be able to get back to these settings, in my opinion it's safe to make these changes and test:
1) check that the certificates on the CAS servers contains the name "".
2) check that TMG resolve the name to the internal IP address, and NOT THE EXTERNAL one !
3) create an internal DNS name webmail that resolve to the internal IP of the CAS Array.
4) change the internalURI on each vdir to use
5) Create the TMG publishing rules for your needs.
Bruno PACIIT ConsultantCommented:

Absolutely nothing have changed about that on Exchange 2010... The default URL is supposed to be .../owa like it was .../exchange on Exchange 2003 and if you want that the root virtual directory to be redirected to .../owa you'll do that with the same way than before.

There are other virtual directories that exist now but the "entry point" is .../owa.

You don't have to worry about ActiveSync and OutlookAnywhere URLs because the virtual directory name is autoamtically added to the URL by the device (smartphones will automatically add /Microsoft-Server-ActiveSync, and Outlook will automatically add /OWA as far as I can remember).

Have a good day.
marrjAuthor Commented:
Ok, thanks.  What a relief.  Was the article that I presented correct in the method for redirecting /owa to the default website for a simpler URL?

Also, have you had any experience using a wildcard cert from Comodo for all CAS services?  I've heard that there can be issues there as well.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Bruno PACIIT ConsultantCommented:
Yes the article you present describes a valid method.
If you don't want to play with HTTP redirection in IIS you can also use the good old method of changing the default.htm in the root site so that it contains an http client redirect instruction.
In my opinion it's safer than playing with IIS HTTP Redirect because as said in the article you may propagate bad parameters if you don't take care about inheritance.

As far as I remember the OWA publishing wizard in TMG does not publish the root directory in the public names, and you can't add it as there are already subdirectories published (/owa, /exchange, /OAB, etc...). Adn if you remove all these names to remplace them by /* you'll then have issues with publishing rules for ActiveSync and OutlookAnywhere because /* will also apply to their URLs.
So the easiest way in my opinion is to:
1) Use the wizard to create publishing rules for ActiveSync, OutlookAnywhere and OWA.
2) Copy the publishing OWA rule that was made by the wizard in a new publishing rule. In the public name of this new rule remove all virtual directories and change for /*. Make sure that this new rule is placed AFTER the other publishing rules in the TMG rules list so that wizard's publishing rules are tested BEFORE.
3) You should configure the rules to use SSO based on the URL domain name else you'll have to enter credentials two times if you use the simplified URL.

I don't know about wildcard cert. I successed to make it work with a internally generated wildcard certificate in a Proof of Concept configuration but I can't tell you it will works because it depends the way the certificate is generated...
marrjAuthor Commented:
If I want all clients (internal and Internet) to browse to, rather than having internal clients directed to, do I need to change the entries under each of the virtual directories in EMC or just create an internal hostname that directs the requests?
Bruno PACIIT ConsultantCommented:
NEVER touch virtual directories !

You must create a "split DNS" configuration so that internal DNS servers resolve the name to the internal IP address of your CAS server (or the virtual IP of your NLB if you have load balanced CAS servers) and external DNS servers resolve the name to the external IP address that point to the TMG server.

A good way to do that:
On your internal DNS servers, create a new forward lookup DNS zone that you call "". In this zone create a new host (type A) DNS record, leave the hostname blank and type the IP address of the CAS server (or the VIP on the CAS NLB).
When it's done you'll see a DNS zone "" with a DNS record named "same as parent".

Doing like that,  your internal DNS server are now able to resolve to the internal IP of the CAS.

You need a certificate on your internal CAS servers because it would be a shame to let the user passwords travel on the network with no encryption, even internally !!! So even if HTTP is technically possible DON'T DO THAT !!!! Use HTTPS. By the way HTTPS is the default since Exchange 2007.
After installation each Exchange server will have generated a self-signed certificate but this certificate doesn't have the requested names for a publication through TMG.
You don't have to buy this certificate because a "public" certificate is not mandatory at this place. It's inside your private network, noone fron the external public network will dialog directly with the CAS server so no need to pay for a publicly trusted certificate.

If you want to create your own certificate, you can install the Certification Authority feature on an internal windows server, but don't choose a DC ! Also, if you install a certification authority just for that use choose a root standalone authority, not an enterprise one !!

With the New-Exchange-Certificate cmdlet you can create a certificate request for all the names you need internally. You can create a unique certificate that you'll use on all the CAS server. In this case this certificate must be a SAN one with the following names:
- internal Netbios name of each CAS server
- internal FDQN name of each CAS server
- (where match your SMTP domain)
- internal FQDN of the name associated to the VIP of the NLB (if you have one, else no need as the FQDN of the CAS server will suffice)

The cmdlet will generate a CSR file that you'll submit to your certification authority, then you'll deliver a certificate, export it in a file and import it on your CAS servers.
You also need to export the certificate of your root certification authority and install it on all servers and computers inside your network. This can be done easily by the way of a GPO applied to all internal machine, all the servers, included Exchange.

For external clients, you need to but a certificate from a public trusted authority. If you already have a wildcard certificate you may try with it.

You must ensure that your TMG server is able to resolve internal FQDN of you CAS servers and NLB. If your TMG server is member of the domain then this should be already done. Else you can use internal DNS server or a host file if you prefer. What is important is that when you ping the FQDN of your internal CAS servers from the TMG it muste resolve to the IP addresses.
Important: the certificate of your internal certification authority must be installed on the TMG server also, because the TMG server MUST trust the certificate of the CAS servers.

To check that, from the TMG server is your open IE to browse HTTPS://fqdn-of-internal-cas-server/owa you should reach the OWA page without any certificate security alert ! That is important and if it doesn't work there no need to go forward with the TMG publication rules.

At this time you can install your public certificate on TMG server. You must ensure that the Certificates console tell you that you have the private key of the certificate.

Then you can create your publishing rules.

TMG is smarter than ISA as it is able to recognize the type of external client. So you can have a unique TMG HTTPS Port Listener that is configured for Form-Based authentication for OWA publishing rule and it will also fit for ActiveSync and OutlookAnywhere publishing rules. TMG will automatically revert back to a basic authentication if the client type is not a recognized web browser.

Have a good day.
marrjAuthor Commented:
Do I really need a split DNS if my internal AD domain is the same name as my external registered domain?  All it would take to direct traffic to the Exchange server internally would be to create a hostname for  I'm sorry if I wasn't clear on that earlier.  My problem is that IIS doesn't seem to want to respond when I create such a hostname.  It will only respond to a request to  The only way I can get the OWA logon page to pop up using is to change the Internal URL on each of the virtual directories in EMC to match  I just want to make sure that this isn't going to break anything else, as you mentioned that it is not good to edit the vdir's.
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.