Mmmm…Outlook Web Access. Having had to deal with Notes’ pathetic excuse for webmail for the past six months, I was thrilled (thrilled! I say) to get myself some OWA action. "Any browser, and operating system" seems to be a fair statement, and in all cases, it still looks like Outlook. So of course, the next step is to get this baby out on the actual web! And I can think of no way I would do this except through our TMG 2010 server.
Outlook Web Access requires HTTPS connections (and rightfully so) but I like to make things easier on users when I can, so we’re going to publish OWA in stages. We’ll set up two listeners…one for http and one for https. Then we’ll set up a rule that accepts http connections to a short URL and configure this rule to perform our redirect to the https site and include the /owa path. Finally, we’ll set up the rule that will actually publish OWA as usual.
Assumptions
For the work to be performed in this post, we’re assuming you have TMG, a static ip.addr on your Internet connection that is not already configured for some other purpose, that you have a suitable certificate installed on your TMG server, and have added the A record into your external DNS that you want to use for web mail. All of these are fairly easy, but could also take up a post on their own.
Listeners
There are two schools of thought on this, and I have argued this with MSFT in the past. The tin-foil hat brigade wants to only accept https connections to OWA, and require users to type in the https:// and the /owa on the end of the URL. They can want all they want…THEY’RE WRONG! We know that users tend to leave off the protocol, and if we tell them to type slash Oh Double-U Ay they will probably wind up with \0uu8 so we’re not even going to try. We’ll just set up a rule that accepts a simple URL over http and redirects them to another rule that connects them to OWA over https. To do that, we need two listeners.
- Log onto TMG, browse down to the Firewall Policy, and in the actions pane (far right) click on Toolbox.
- Click New, Web Listener.
- Give it a name like allpurposehttp, configure it to use http, pick your external address, and set Authentication to “No Authentication.”
- Create another, call it allpurposehttps, configure it to use https, pick your external address, your certificate (I recommend a wildcard cert so you can use this for many things) and set Authentication to “No Authentication.” We’re going to let OWA handle the authentication, so no sense making the user also authenticate to TMG.
HTTP rule
Now let’s create our first rule. Remember, this one will accept a simple URL over http, and then redirect us to our proper OWA connection. We’ll use webmail.retrohack.com as the URL for our OWA.
- In our TMG console, browse to Firewall Policy, right-click it, then click New, Web Site Publishing Rule…
- In the first panel of the wizard, name it something relevant, and click Next.
- For select a Rule Action, click Deny and then click Next.
- In Publishing Type, just click Next.
- In Server Connection Security, just click Next. (Remember this is a Deny rule, so none of this really matters.
- In Internal Publishing Details, type in anything for Internal site name, and click Next.
- In Internal Publishing Details, just click Next.
- In Public Name Details, type in the short URL you want to give out to users. Then click Next.
- In Select Web Listener, pick your allpurposehttp listener from the drop down list, and then click Next.
- In Authentication Delegation, just click Next.
- In User Sets, make sure it shows "All Users" and click Next.
- Click Finish, and then right-click your new rule and choose Properties.
- Go to the Action Tab, select the check box for "Redirect HTTP requests to this Web page:" and fill in the URL for OWA, including the https:// and the /owa.
- Click OK, then click Apply up at the top, enter your change documentation, and hit OK.
OWA rule
Now we can setup our publishing rule for OWA.
- Once again, in our TMG console, browse to Firewall Policy, right-click it, then click New, and this time click Exchange Web Client Access Publishing Rule…
- Give your rule a name and then click Next.
- Pick Exchange 2010 from the drop down list, and select Outlook Web Access, then click Next.
- On Publishing Type, just click Next (unless of course, you actually have a farm of OWA servers.)
- On Server Connection Security, just click Next (default is to use SSL.)
- On the Internal Publishing Details, fill in the FQDN or hostname of your OWA server. No protocol, no /OWA, then click Next.
- In the Public Name Details, fill in the external FQDN…again, no protocol or path. Click Next.
- In the Select Web Listener, pick your https listener from the drop down list, and the click Next.
- In Authentication Delegation, select "No delegation, but client may authenticate directly" and then click Next.
- In User Sets, make sure "All Users" is listed and then click Next.
- In Completing the New Exchange Publishing Rule Wizard, click Test Rule and investigate any errors. If all shows green, click Finish.
- Up at the top, click Apply, enter your change control reason, and then hit OK.
Now you just need to hop out to an external machine, open a browser and enter your short URL…no protocol, no /owa. If you did everything above correctly, and your DNS records are in place, you see your browser redirected to your https site and then you’ll see the logon form for OWA. Win!
With this, we get the double-goodness of using simple URLs for web mail that take care of securely connecting our users automagickally. It’s not every day that we get both what we want and what we need at the same time. In honour of the rare occurrence, here’s a little jam to get your day going. I saw INXS from the front row at Radford College in 1987 when they had no sponsor, and again six months later when MTV was footing the bill. They were just as awesome the second time around, but a lot more personal from ten feet away.
direct link for RSS and email subscribers…http://www.youtube.com/watch?v=vSME53nL8tg
Do you prefer to make it simpler for your users, or to require longer URLs with https?
You might also enjoy:
{ 51 comments… read them below or add one }
Ed, help, we have a problem!
I followed the procedure. If I connect to OWA I get an error http 500 on the certificate in Internet Explorer window:
Error Code: 500 Internal Server Error. The certificate issued by an authority chain Was That is not trusted. (-2146893019).
Forefront TMG test result of the rule:
Category: Destination server certificate error
Error details: 0×80090325 – The certificate issued by an authority chain Was That is not trusted.
Action: Go to http://go.microsoft.com/fwlink/?LinkId=115965
If I connect directly to exchange server using the internal address from the TMG machine I get the same error.
I solved the issue of certificates. I exported the certificate on the Exchange server and I imported in the “Trusted Root Certification Authorities” TMG Server and Exchange Server.
Thank you, proceed with the work! : D
Sorry Shance, just woke up. Glad you got it sorted. Who issued the cert?
Ed
The problem was given by the internal certificate that the setup created for the echange server
Shance
Hi Ed,
Is the same approach for publishing Exchange 2010 RPC client access?
i.e Use AllpurposeHttps with no Authentication and “no delegation, but client may authenticate directly”
It seems to work, but I just want to make sure I have not left a gapping hole…..
cheers
Nick
Pretty much. See http://retrohack.com/enable-activesync-outlook-anywhere-exchange-2010/
for the specifics, but I use the same listener and it works a champ. Post any follow up questions you have on that post.
Cheers,
Ed
This works great for everything but:
User types:
https://mail.domain.com (https doesn’t redirect and instead receives a 403 error).
This works fine:
http://mail.domain.com redirects to https://mail.domain.com/owa
What are we doing wrong?
Hi Nicholas,
If you want them to be able to specify httpS but not require them to specify /owa, the easiest path would be to put a default.htm in the root of the IIS site, and do a meta refresh to the full url. Something like this…
D’oh! My own blog filtered out the HTML. Sorry about that. You’ll need to remove the extra spaces inside the <>.
< meta http-equiv="refresh" content="0;url=https://mail.domain.com/owa" / >
HTH,
Ed
Hi Ed,
Thank you for the suggestion — that is working admirably for internal users when they hit the CAS instances directly; however, it is not redirecting for external users (via TMG) for some reason.
I modified the Firewall Rule to allow ‘/’ as an additional path so I’m not seeing the traffic drop at the TMG (instead users who hit https://mail.domain.com externally are getting the default iisstart.htm Welcome splash)…
I checked the IIS parent site config and Default.htm is at the top of the default documents order…
Hi Nicholas,
That sounds more like an IIS thing than a TMG thing, since your external users are able to hit the iisstart.htm page. The quick fix would be to put that same redirect tag in the iisstart.htm file.
It’s that, or you are hitting cached content from either the IIS or TMG. Most don’t enable caching on the TMG so maybe an iisreset on the IIS server would straighten things out.
Personally, I would just paste the redir string into iisstart.htm since you know users are hitting that, and call it a day. Either way, let me know how things shake out.
Ed
Your instructions worked like a charm, Exchange 2010 is so much more fun and easier than 2007. I kind of felt important when I learned exchange 2007, but now anyone can set this stuff up with 2010. Even TMG got easier than ISA 2006, still they never teach you this trick ! Cheers.
Thanks a million ,i installed exchange edge transport server ,my environment only internal email,i cannot send email successfully through edge transport server,what lmhost setting is using in edge server,how to test the port are working in exchange,i don,t know what mistakes i made it.
Edwin,
Thanks for dropping by and leaving a comment. If you are having problems with your outbound, check out this post on TMG and/or this post on setting up the edge subscription.
HTH,
Ed
Hi Ed,
Do you have any advice\instructions on creating a wildcard Cert from an internal CA that then can be used for all Exchange 2010 services (IIS, OWA, SMTP,RPC ActiveSync,) as well for establishing a SSTP VPNs to TMG? i.e your AllpurposeHttps cert
Please can you confirm the certificate Template Used from the internal Root CA ( Web Server providing server auth etc) and what you would recommend as the SANS to include within the Cert request if any? Can I also confirm that the root Wildcard for a domain would support all hosts including those within a subdomain (*.domain.com support hosts within *.subdomain.domain.com) or would you need to add wildcard SANs for subdomains to the cert as well?
e.g
Single Wildcard & Host NetBIOS names
Set-Content -path "C:\domain_com" -Value (New-ExchangeCertificate -GenerateRequest -KeySize 2048 –FriendlyName “AllPurposeHttps” -SubjectName "c=xx, s=xxxxxx, l=xxxxxx, o=xxxxxxx, ou=xxxx, cn=*.Domain.com" -DomainName exchangeServerName, TMGServerName -PrivateKeyExportable $True)Or multiple Wildcard, exchange role paths & Host NetBIOS names
Set-Content -path "C:\domain_com" -Value (New-ExchangeCertificate -GenerateRequest -KeySize 2048 –FriendlyName “AllPurposeHttps” -SubjectName "c=xx, s=xxxxxx, l=xxxxxx, o=xxxxxxx, ou=xxxx, cn=*.Domain.com" -DomainName *.subdomain.Domain.com, mail.Domain.com, mail.subdomain.Domain.com, autodiscover.subdomain.Domain.com, autodiscover.Domain.com, exhangeServer.subdomain.Domain.com, exchangeServerName, TMGServerName -PrivateKeyExportable $True)Thanks in advance
Nick
Nick,
Sorry, but I barely have time to review comments; I cannot check your syntax right now but will try to do so this weekend. I can tell you that you will need to add a SAN for every subdomain. Wildcards only work at the same level. As for generating a CSR, check out this post I wrote on the Exchange Certificate Wizard. That should make this much easier for you.
Ed
Dont suppose you have anything on IKEv2 based VPNs and TMG 2010?
Considering you are one of three people I know who has even clicked around enough to notice that as an option…no. In the interest of completeness I may do something in the future on that, but it won’t be any time soon.
Sorry,
Ed
Hi,
I get errors in the test rule.
“certificate erro target server”
The target.’s name server is incorrect.
Please help soon as soon as you can.
Regarts
Henriux
Henriux
Can you paste the full message text (non-English is ok) in a reply to this, along with more info on external and internal names used? I suspect s particular issue but need more to be certain and don’t want to send you down a rabbit hole if I’m wrong.
Ed
Nice article on how to redirect Outlook Web Access traffic to HTTPS and /OWA using Microsoft Threat Management Gateway. http://t.co/lGVSJSI
CAN anyone help me please i did as mentioned above and the test shows green , but still i get access owa Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202) please help,much appreciated
Toufik, are you testing from outside your network and what URL are you using? Did you try to access your OWA URL using only HTTP and not HTTPS?
Hi Ed thanks for the reply,i m accessing owa from outside my network,say for instance my public name is : webmail.private.com i m usinbg :
https://webmail.private.com and as well http but none of them work the internal though works fine as i have 2 different urls one for the internal and external,
regards
Not sure. You should take a look at the TMG logs for when the failure occurs, and see if they shed more light on the issue. It might be something in the actual URL, or the way auth is configured.
Make sure you can hit OWA from the TMG server itself.
HTH
Ed
sorry for late reply i cant access owa from The TMG at all get the same error,the url is correct .
regards
That sounds like something is not right on the TMG itself then. Edit the system policy and make sure you permit your TMG to access websites internally. If you cannot access OWA from the TMG server itself, its tough to troubleshoot why external clients cannot.
Ed
hi ed any idea how to Edit the system policy and make sure you permit your TMG to access websites internall , smuch appreciate it
regards
1) launch TMG management console
2) browse to firewall policy
3) In the task pane, scroll down to the bottom, and click “Edit System Policy.”
4) Scroll down to the bottom, Various Category, Allowed Sites. Make sure it is enabled, and then add the appropriate sites. I add all networks and local host, but you may choose to only add internal or create a list of appropriate sites.
Good luck,
Ed
Thanks ED i l give it a shot on monday will let you know ,
regards
Hi ED sorry for coming back to u late , i was busy with dpm sttuff . i tried your recommendation and it worked yeaaaaaaaaaaaaaaaaaaah worked thank you very much i f i meet u i l buy you cold ones,please can you help me how to create a simplified url for my users,dont want them to type https://doman.com/owa
want to remove the owa how to that ,i tried the one above here when i configure the weblistener it keeps saying it s in use , much appreciated
regards
Make sure whatever name you used (I used webmail.retrohack.com above) is not associated with any other http rule, and that the actual rule to publish OWA is set only for https. You only want to use http to hit the Deny rule that redirects, and you only want to use https to hit OWA for real. Try using a different name, like mail or mailbox instead of webmail if you cannot find where webmail is already being used to make sure that it is not a problem with the name already assigned to another http rule.
Remember, this is leveraging the behaviour of host headers for http, so that name must be unique.
HTH
Ed
Hi Ed it is sorted out much appreciated , all the best
regards
hi ed now internal url seems to be problematic , when i type in the internal url for owa it takes me to iis default web page any idea ? regards
Does it work from internal workstations but not the TMG, or does it not work from anywhere?
Is the internal URL internal only, or are you running a split DNS and using the same name internally and externally?
What is the problem client using for DNS?
Can any machine access the internal OWA URL successfully?
Does the external OWA URL work when tested from the outside?
the internal url without the /owa at the end it will take me to default iis site,regards
that’s as it should be by default…if you want to use the internal FQDN as your URL and be redirected to OWA automagically, you will need to set up a redir in the web root. Create a default.htm and paste something like this
There is an extra space after the < and before the > that you will need to edit out.
HTH,
Ed
Thanks Ed for the quick reply , i leave it as it is then much appreciate it
regards
Hi Ed hope you will help on this,atuodiscover not working externally when i want to set new account from a joint domain , outlook will not find the autodiscover (only externally).Tested autodiscover connectivity failed as well ,went to technet docs didnt find any good references,we using TMG 2010 ,we do have a host record for autodiscover,does it have to be the external ip of the TMG ? owa works fine np ,internally it s fine as it can find the cas server.we using two Urls but both of them are public routable ,domain.net and domainlive.net which is for all our external url owa,outlook anywhere activesync and all ,the host record for autodiscover is as autodiscover.domain.net but it seems not resolving externally, any guidance please,
Regards
Yes, autodiscover.example.com must resolve to the (external) ip.addr on the TMG that is publishing autodiscover, and of course you rule must be set up to publish the autodiscover path. More work is required than to just publish OWA. See http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8946 for another approach to doing this if you didn’t make out well with what I had above.
does the internal Autodiscover url must match the external one say internally is autodiscover.doman.net , externally does it has to be the same ,must both of internal and external A Record to be the external TMG IP ?
now when i test the punlishing rule in owa ,the test for owa and ecp run correctly and shows green but for /Exchange/* ,/public/* gives this erros:
Error details: An unexpected response was received from the server. HTTP response: 500 Internal Server Error
Action: Verify that the intended server is published and that virtual directories exist. Ensure that you can browse the published site directly from an internal client computer. any ideas ED , i m really sorry for bugging u a lot
regards
The internal URL’s FQDN should resolve to the CAS server, the external should resolve to the TMG’s external ip.addr. The results you describe from the testexchangeconnectivity.com site sound very much like your publishing rule is not correct. If you can get to the /Exchange using the internal URL you should get a 403, not a 500. /Public is for older public folders, and I hope you don’t care about them. I don’t and have no advice for them. If using the internal URL to /exchange still gives you a 500, your CAS server might have an issue.
Hi ED here is what the testexchangeconnectivity looks:
But let explain our envirement:
we have user@domain.net this our smtp adrress
we have mail.domainlive.net for external urls owa,oab,activesync,
we have two wild card certificates:
*.domai.net
*domainlive.net
what i did is int the internal A Record i added autodiscover.domain.net mapped to the CAS ip.
externally : autodiscover.domain.net mapped to the externall TMG ip As per ur suggestion right.
now the error Host name autodiscover.domain.net doesn’t match any name found on the server certificate, or was it suppose to be autodiscover.domainlive.net which is on the wild card cert in domainlive.net here is the full message hope it make sense to you,i can connect to owa externally without any problmes,Thanks in advnace
ExRCA is attempting to test Autodiscover for user@domain.net. this is
Testing Autodiscover failed.
Test Steps
Attempting each method of contacting the Autodiscover service.
The Autodiscover service couldn’t be contacted successfully by any method.
Test Steps
Attempting to test potential Autodiscover URL https://DOMAIN.net/AutoDiscover/AutoDiscover.xml
Testing of this potential Autodiscover URL failed.
Test Steps
Attempting to resolve the host name DOMAIN.net in DNS.
The host name couldn’t be resolved.
Tell me more about this issue and how to resolve it
Additional Details
Host domain.net couldn’t be resolved in DNS InfoNoRecords.
Attempting to test potential Autodiscover URL https://autodiscover.DOMAIN.net/AutoDiscover/AutoDiscover.xml
Testing of this potential Autodiscover URL failed.
Test Steps
Attempting to resolve the host name autodiscover.DOMAIN.net in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: TMG EXTERNAL ADDRESS
Testing TCP port 443 on host autodiscover.DOMAIN.net to ensure it’s listening and open.
The port was opened successfully.
Testing the SSL certificate to make sure it’s valid.
The SSL certificate failed one or more certificate validation checks.
Test Steps
ExRCA is attempting to obtain the SSL certificate from remote server autodiscover.DOMAIN.net on port 443.
ExRCA successfully obtained the remote SSL certificate.
Additional Details
Remote Certificate Subject: CN=*.DOMAINlive.net, OU=xx, O=DOMAIN.net, L=xx, S=XX, C=xx, Issuer: CN=DOMAINXXXX-CA, DC=DOMAIN, DC=net.
Validating the certificate name.
Certificate name validation failed.
Tell me more about this issue and how to resolve it
Additional Details
Host name autodiscover.DOMAIN.net doesn’t match any name found on the server certificate CN=*.DOMAINlive.net, OU=KZN, O=DOMAIN.net, L=XXX, S=XX, C=XXXX.
Attempting to contact the Autodiscover service using the HTTP redirect method.
The attempt to contact Autodiscover using the HTTP Redirect method failed.
Test Steps
Attempting to resolve the host name autodiscover.domain.net in DNS.
The host name resolved successfully.
Additional Details
IP addresses returned: TMG EXTERNAL ADDRESS
Testing TCP port 80 on host autodiscover.DOMAIN.net to ensure it’s listening and open.
The port was opened successfully.
ExRCA is checking the host autodiscover.DOMAIN.net for an HTTP redirect to the Autodiscover service.
ExRCA failed to get an HTTP redirect response for Autodiscover.
Tell me more about this issue and how to resolve it
Additional Details
An HTTP 403 error was received because ISA Server denied the specified URL.
Attempting to contact the Autodiscover service using the DNS SRV redirect method.
ExRCA failed to contact the Autodiscover service using the DNS SRV redirect method.
Test Steps
Attempting to locate SRV record _autodiscover._tcp.DOMAIN.net in DNS.
The Autodiscover SRV record wasn’t found in DNS.
Tell me more about this issue and how to resolve it
Thanks in advance
Toufik,
You’ve neither set up your SRV records in DNS, nor correctly published the /autodiscover/* through your TMG.
I cannot comment on how you have your certs and URLs set up since you have obfuscated the domain specific information beyond my ability to glance at and recognise an issue. I can’t say I blame you for that, but that moves this from a simple helping hand that takes me a few minutes to parse and that I’d be willing to give, to a request for consulting services that involves much more time, and which I no longer do.
If you’d like to get some more private assistance, please use the contact form (linked at the top of the page) to reach out to me directly (and privately.) In response I will provide you with the exact data I need. Amazon and/or Starbucks gift cards are both nice tokens of appreciation and lets you set a value you feel my assistance is worth, and makes up for the time I spend helping.
FWIW, if you fix the SRV record and the publishing of autodiscover (instructions are in that TechNet article I linked above) and odds are you’ll be set. That advice is still free.
Hi ED sorry for the late reply i was busy doing other stuff, i did not plan or design their exchange envirement i just inherited a complete failed transition from 2003,2007 to 2010 it was a complete nightmare,got activesync working ,regarding the autodiscover i will not bother as for now gpt too many things to worry bout ,anyway thanks for all ur help i really appreciate it all the best.
Regards
Glad you have things working Toufik!
Hey Ed,
I have a redirect/certificate question. We use a third party server for spam filtering, which is using our mx record. We made a new dns entry for our tmg/edge server, the record points email.summit911.org to our tmg server. I have an already established godaddy certificate on my mail server which is mail.summit911.org. Would it be better to redirect requests on tmg to point requests for email.summit911.org to mail.summit911.org/owa, or should i make a new certificate for my mail server using email.summit911.org instead of mail.summit911.org?
Would the redirect process be the same as your instructions above? Would i have to change the external url for owa to the email.summit911.org address, or leave it the same and let the redirect push the requests for email.summit911.org to https://mail.summit911.org/owa ?
Aaron
I typically like to do redirects on the TMG, so I can fully control it, and I like to use a simple names, so I would publish the URL http://email.summit911.org on the TMG as a DENY and then redirect that to https://mail.summit911.org/owa, which I assume you are using for actually publishing OWA using the TMG.
You just don’t want users to try https://email.summit911.org, since clients can get a little pissy about redirects on secure connections.
Hey Ed,
This post is very helpful. Thank you.
A quick question. After you’ve configured this, can you leave authentication on EMC for the client server as FBA or WBA?
Our users are getting double authentication on OWA from outside the network and internal users are not being redirected.
Thanks
Hi Tunde,
Thanks for the comment, and the follow. As to your questions; if you are using Forms Based Authentication and getting prompted twice, it sounds like SSO is not setup correctly. Check your SPNs and delegated authentication for Kerberos. And are you trying to point your internal users to the TMG instead of directly to your CAS? That would work, if you are using split DNS and have the listener for this publishing rule set up to listen on both the internal and external networks…more details needed if that doesn’t answer your question.
Ed
Thanks for your response. I’ll double-check those things you mentioned. I didn’t configure the environment, so, there is alot of going back and forth.
Internal users are configured to talk to CAS (cas-array) directly. I believe redirection has to be configured on IIS for the internal redirection to work (correct me if I’m wrong). There is something I notice on the IIS server however, the redirection was done on the folder level (Default-WebSite -> Exchange and Default-Website-ExchWeb) only. No redirection on the root (default web site) itself. Could this be one of the problem as well?
T
Hi Tunde,
If you want the simple redir from a user friendly url (http://mail.example.com) to the “real” url (https://mail.example.com/owa) then yes, it should be done at the root of the site, since that is what the user friendly url connects to. Yes that could be one of the problems.
HTH
Ed