marrj
asked on
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 (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?
http://www.msexchange.org/blogs/walther/news/oab-issues-after-simplifying-the-owa-2010-url-507.html
http://www.msexchange.org/blogs/walther/news/oab-issues-after-simplifying-the-owa-2010-url-507.html
ASKER
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.
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.
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...
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...
ASKER
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?
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.
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.
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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-ActiveSy
Have a good day.