I have a query about Exchange 2007 published via Forefront TMG (ISA). External clients resolve owa.domain.com to the Forefront IP and Forefront provides forms-based authentication. What should we get internal clients to resolve owa.domain.com to? The internal IP of the CAS server or Forefront's IP? We are using split DNS with Internal and External OWA URLs set the same à la http://www.amset.info/exchange/singlenamessl.asp. If I set owa.domain.com to resolve to Forefronts IP, clients receive the nice login form but I am concerned what effect this will have on internal Outlook clients connecting to other exchange web services, such as availability, OOF and OAB downloads. If I set owa.domain.com to resolve to internal CAS IP I’m confident internal Outlook clients will have no problems with other exchange web services. However they don’t get the pretty login form when they connect to Owa but are given the Basic login prompt (FBA disabled on Exchange CAS to accommodate Forefront).

In general, I prefer to obtain UCC certificates from a public issuer for the TMG server like you did, and to use an internal Enterprise CA for certificates for the CAS servers. That advice applies whether you have split-brain DNS like yours or different internal and external namespaces. I assume that you've already figured out that you'll want to be sure that DNS resolves to internal addresses for internal clients, and external for external, but for completeness I'll post it anyway. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Ed, Thanks for your reply. We're not using a UC certificate but I think we're OK from a certificate standpoint (or as OK as you can be with a single name certificate in Exchange 2007). My question more revolves around your second point. I agree, I'd prefer owa.domain.com to resolve internally to the CAS IP so internal Outlook clients can get to Exchange web services (OAB, OOF, Availability etc) without having to go through and authenticate via the firewall. It just seems cleaner. However, if someone from internal does go to Outlook Web Access they get prompted with the Basic authentication dialog. It would be nice if they had the same login form (or at least a login form that can be customized to look the same) as they get when external. Is this acheivable? Or at the very least, it would be nice to allow integrated authentication as well as basic on the OWA virtual directories so internal clients aren't prompted for credentials at all. This seems to fall over though because we still have mailboxes on 2003 servers accessing OWA through the same URL via the CAS legacy virtual directories. From the sounds of it, the legacy virtual directories only support forms-based authentication or basic (reference the Authentication section of the following article: http://msexchangeteam.com/archive/2007/02/07/434523.aspx) Your thoughts? Thanks, Mark.

The way I've handled that is to create a separate OWA virtual directory for Internet-based access from the TMG server using SSL and port 4433 (arbitrary) and configuring the default OWA virtual directory for forms authentication. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Ed, Thanks for your response. I’ve never needed to create extra virtual directories so please bear with me. Do you have some basic notes that you follow to get this working? If not, how does the below process sound? It seems to work on a test system although I haven’t got any 2003 back-end servers in that environment to see how they react (or EV extensions and all the other production bells and whistles). 1. On the CAS, bind the Default Web Site to its current IP. 2. Add an extra IP to the CAS. 3. Create a new IIS website called “External” bound to the extra IP. 4. Bind the External site to the same owa.domain.com certificate but on SSL port 4433. 5. Create the following virtual directories in the new site (since we’re supporting Exchange 2003 and 2007 mailboxes through the CAS): New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType Mailboxes -Name "exchange" -WebSiteName "External" New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType PublicFolders -Name "public" -WebSiteName "External" New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType Exchweb -Name "exchweb" -WebSiteName "External" New-OWAVirtualDirectory -Name "owa" -WebSiteName "External" 6. Disable forms-based authentication on those virtual directories in the External website. 7. Enable forms-based authentication on those virtual directories in the default website. 8. In Forefront, on the ‘Bridging’ tab of ‘Publish OWA’ rule, set it to redirect to SSL port 4433. 9. In Forefront, on the ‘To’ tab of ‘Publish OWA’ rule add the IP of the CAS that’s bound to the CAS External website. 10. From a DNS standpoint owa.domain.com will resolve to Forefronts External IP from the internet and to the CAS’s default website internally (since all the other weird and wonderful Autodiscover, EWS and OAB virtual directories still reside in the default website). 11. In Forefront, leave the ‘Outlook Anywhere’ rule forwarding requests the default website on the CAS rather than the external website (for the same reason as above … Autodiscover, EWS and OAB virtual directories). With this done, internally Outlook will point directly at the CAS default website for all web services. Internally OWA clients will get the login form from the CAS’s default website. Externally Outlook clients will still connect to the default website on the CAS via forefront. Externally OWA clients will receive forms-based authentication from Forefront and then forefront will connect via SSL port 4433 through to the External website on the CAS. Assuming that looks OK, I have one last question. Do you know if all the OWA logic resides in just those virtual directories (I’m concerned that maybe OWA may also use some of the stuff in the EWS virtual directory)? Thanks for your help, very much appreciated. Mark.

Regarding steps 2 and 3, an extra IP address isn't required because you are binding to a different port. The rest of it looks right. OWA doesn't use any of the stuff in the EWS virtual directory. However, publishing OWA this way may not properly publish EWS and OAB directories required by Outlook when using Outlook Anywhere. You might want to try the New-WebServicesVirtualDirectory and New-OABVirtualDirectory cmdlets. Outlook Anywhere and ActiveSync should work fine the way it did before with their own publishing rules to the orignial website at port 443 as before. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Ed, I added the extra IP since IIS was moaning about a conflicting port. The second website was also listening for http traffic on port 80. Since TMG will be redirecting http to https before it gets to the website I moved that off to a random port as well and IIS was then happen to load both websites with only 1 IP. I meant to get back to you sooner but I was only able to put this back into production this weekend. Tested OWA and RPC/https against Exchange 2003 and 2007 mailboxes. Solution works perfectly. The only down side was the work to make the TMG and Exchange login forms look similar but worth the effort. Thank you very much for your help, I owe you a beer. Mark.

No beer required. You can just mark my posts as helpful! Happy to have helped.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."