Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


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

Posted on 2013-01-28
Medium Priority
Last Modified: 2013-01-31
I'm about to undergo a major migration from Exchange 2003 to 2010.  Up until now, my organization has used the same URL (webmail.domain.com) 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?

Question by:marrj
  • 4
  • 3
LVL 16

Expert Comment

by:Bruno PACI
ID: 38827417

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.

Author Comment

ID: 38827476
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.
LVL 16

Expert Comment

by:Bruno PACI
ID: 38827625
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...
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 38828687
If I want all clients (internal and Internet) to browse to https://webmail.domain.com, rather than having internal clients directed to http://servername.domain.com, 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?
LVL 16

Expert Comment

by:Bruno PACI
ID: 38829054
NEVER touch virtual directories !

You must create a "split DNS" configuration so that internal DNS servers resolve the name webmail.domain.com 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 webmail.domain.com 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 "webmail.domain.com". 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 "webmail.domain.com" with a DNS record named "same as parent".

Doing like that,  your internal DNS server are now able to resolve webmail.domain.com 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
- webmail.domain.com
- autodiscover.domain.com (where domain.com 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.

Author Comment

ID: 38831206
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 webmail.domain.com.  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 https://servername.domain.com.  The only way I can get the OWA logon page to pop up using https://webmail.domain.com is to change the Internal URL on each of the virtual directories in EMC to match https://webmail.domain.com.  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.
LVL 16

Accepted Solution

Bruno PACI earned 2000 total points
ID: 38831460
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 https://xxx.xxx.xxx.xxx/owa 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 "webmail.domain.com" 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 "webmail.doman.com".
2) check that TMG resolve the name webmail.domain.com 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 https://webmail.domain.com/blahblah
5) Create the TMG publishing rules for your needs.

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Among the most obnoxious of Exchange errors is error 1216 – Attached Database Mismatch error of the Jet Database Engine. When faced with this error, users may have to suffer from mailbox inaccessibility and in worst situations, permanent data loss.
Upgrading from older Exchange server to the latest Exchange server can be tiresome, error-prone and risky, without being a seasoned exchange server administrators. It can become even problematic if you're an organization that runs on tight timeline…
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…
Is your OST file inaccessible, Need to transfer OST file from one computer to another? Want to convert OST file to PST? If the answer to any of the above question is yes, then look no further. With the help of Stellar OST to PST Converter, you can e…
Suggested Courses
Course of the Month11 days, 21 hours left to enroll

564 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question