I have seen many people encounter issues with publishing Symantec Enterprise Vault behind ISA 2006. For our scenario, OWA users go through ISA both internally as well as externally. Why do we do this? Well, when you are publishing OWA 2007 behind ISA 2006, one of the requirements is to go onto your Exchange 2007 Client Access Server (CAS) and disable Forms Based Authentication and enable Basic Authentication instead. This is because ISA 2006 will be using Forms Based Authentication. Switching OWA on Exchange 2007 to use Basic Authentication instead of Forms Based Authentication allows us to avoid being prompted twice for authentication (once by ISA and then once by Exchange). Basic Authentication on the CAS allows ISA to pass the authentication through to Exchange without being prompted a second time.
So why do we point both internal and external users through ISA? That is because we want users to get the same OWA experience both internally and externally. We don’t want internal users pointed directly to Exchange and get a Basic Authentication prompt while external users get Forms Based Authentication when outside the corporate network. By pointing internal and external users directly through ISA, they will get the same experience internally and externally.
As you can see in the following image, in Symantec Enterprise Vault, IIS contains several directories which include a directory called EnterpriseVault:
Prerequisite
Properly configure IIS on your Client Access Server (CAS) to host the certificate(s) needed for external and internal access. The certificate recommended for this configuration is a Unified Communications (UC) certificate. You can read more about these different configurations here.
Note: For this article, we will be using a UC certificate that contains 4 Subject Alternative Names (SANs). Our requested certificate’s CN was webmail.shudnow.net. The first SAN name requested was also webmail.shudnow.net. Our request was created using the following EMS command:
New-Exchangecertificate -domainname webmail.shudnow.net, autodiscover.shudnow.net, casserver.shudnow.net, casserver -Friendlyname Shudnow -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true -subjectname “c=US, o=Shudnow Inc, CN=webmail.shudnow.net”
- NetBIOS name of CAS (casserver)- used if there is a need/want to connect to services such as OWA using the NetBIOS name of the CAS while connected to the internal network.
- FQDN name of CAS (casserver.shudnow.net)- used so we can publish Autodiscover internal URLs to point directly to the CAS. This name is required if your Exchange Server will be hosting the Unified Messaging rule and you plan on integrating Unified Messaging into your Office Communications Server 2007 Enterprise Voice envirnment. If you have an internal PKI, I would recommend leaving this FQDN out and requesting a certificate with this FQDN to avoid exposing your servername to the public.
- Autodiscover.shudnow.net – used so external clients can retrieve external URLs to connect to web distributed services.
- Intuitivname.shudnow.net – used for services such as Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, web service distribution (OAB, OOF, and Availability). Common FQDNs used are exchange.domain.com, owa.domain.com, mail.domain.com, webmail.domain.com, etc. This article will use the example FQDN: webmail.shudnow.net.
Note: For purposes of this article, the only name in your certificate that is essential for publishing Symantec Enterprise Vault is #4 (Intuitivename.shudnow.net). But since you are requesting a certificate, I would advise you to properly create a certificate with any other names that are required which include #1-4.
You will also want to do the following:
- At the minimum, the ISA 2006 Supportability Update is required which is located here. I would recommend using SP1 instead which is located here.
- Create an Exchange Web Listener
ISA 2006 Configuration
You must ensure that you go onto the CAS and export the certificate with its private key and import that into ISA 2006 (Please make sure you have the licenses needed for installing a certificate on multiple servers if required by your certificate vendor). A guide on how to do this is out of the scope of this blog. Once the certificate has been imported on the ISA 2006, ISA configuration can begin. Start by publishing each Exchange 2007 role as needed. For purposes of this article, we will only show how to publish your Enterprise Vault rule and steps needed to configure your OWA publishing rule to get Enterprise Vault to work through OWA.
Enterprise Vault Publishing Rule
For our Enterprise Vault publishing rule, we will go to Servername > Firewall Policy > New > Website Publishing Rule.
Give your Website Publishing Rule a name. Click Next to Continue.
Select Allow. Click Next to Continue.
Since we will be publishing a single Enterprise Vault Server, choose “Publish a single Web site or load balancer.” Click Next to Continue.
If you have installed a certificate for your Enterprise Vault Server, choose “Use SSL to connect to the published Web server or server farm.” If you have not installed a certificate for your Enterprise Vault Server, choose “Use non-secured connections to connect the published Web server or server farm.” We did install a certificate on our Enterprise Vault Server, so we will choose the first option. Click Next to Continue.
Enter the Internal Site name of your Enterprise Vault Server. Then enter the IP Address of your Enterprise Vault Server. Click Next to Continue.
Because the IIS directory name on your Enterprise Vault Server is called EnterpriseVault, you must enter that name in the Path (Optional) field as is displayed in the following screenshot. Click Next to Continue.
Because we will be accessing Enterprise Vault through OWA, we will want to make to enter our OWA URL name in the Public Name field. For purposes of this lab, our OWA URL will be webmail.shudnow.net. Click Next to Continue.
You will want to select the Listener you created for your Exchange environment. Click Next to Continue.
Select Basic Authentication. Click Next to Continue.
Leave the setting to All Authenticated Users. Click Next and then Finish.
Once you have finished the creating the publishing rule, go into the properties of your Enterprise Vault publishing rule and go to the Paths tab. Ensure your paths display as follows (which they should if you followed the above correctly). Click OK to Finish.
OWA Publishing Rule
Typically, you create your OWA publishing rule using the Firewall Policy, “Exchange Web Client Access publishing Rule.” There is a bug that prevents you from setting up Link Translation rules that are needed to get Enterprise Vault to work. Because of this, make sure you write down all your settings for OWA because we will need to re-create the OWA publishing rule using a regular, “Web Site Publishing Rule.” We will not go through the entire steps of creating the OWA publishing rule, but will rather go through the modification of this rule to ensure Symantec Enterprise Vault works.
So now we have our two publishing rules:
Open your Exchange OWA publishing rule and go to the Link Translation tab and select “Apply link translation to this rule.” Click Next to Continue.
We will now want to make some Link Translation Mappings
These mappings include:
How does this work?
A user connects to OWA using webmail.shudnow.net. They will attempt to access Enterprise Vault. Because they are connected to OWA, you want them using the webmail.shudnow.net name. ISA will create a link translation rule so when the user tries to access the Enterprise Vault rule, they will use the webmail.shudnow.net name instead. But because ISA has the Enterprise Vault publishing rule, ISA knows how to proxy those requests to Enterprise Vault. The reason we created the Public Name as webmail.shudnow.net for the Enterprise Vault rule is because this rule uses the listener for Exchange which contains a certificate that does not include the certificate that contains the entvault.shudnow.net name. It does contain the webmail.shudnow.net name though.
Hi Elan,
Great article btw. My dilema is probably a misconfiguration on my part. I was wondering if you had time to check my config.
I posted my issue on the EV forum which explains my issue. https://www-secure.symantec.com/connect/forums/is…
It seems like after logging into OWA, ISA tries to fetch the EV icons and scripts from the EV server instead of using the CAS RPC extensions.
where did I go wrong?
Thanks for your help.
-S
Thanks Elan for your attention
Hello Elan,
I have some questions for you about this article…
So, i'm using Enterprise Vault 8.0 SP3 ver. with HTTP 80 port to access web application. In general, i have already published in ISA the following exchange 2007 services – OWA, Outlook Anywhere, ActiveSync,…. that's why we use HTTPS communication, also i need to publish EV in ISA 2006 and that the communication will be secure – encrypted.
It is interested to me that if i change in EV site properties the "Use TCP Port 80" to "Use HTTPS on SSL Port 443" then i will also to implement SSL in IIS of Evault and that's why then configure the SSL certificate.
Do you know what kind of certificate do i need to use to push then HTTPS on Enterprise Vault.. ?
P.S I'm little bit confused with configuring SSL Port to Enterprise Vault entirely because i'm using HTTP 80 port already, could you suggest me simply how to setup it ?
Santiago, I've never really set up Enterprise Vault and have only published it via ISA for which I created the article for. So I apologize, but I can't really provide you with any more information on this. What I would suggest though, is to post in the Symantec EV forum section and ask how you can enable SSL on your IIS directories for Enterprise Vault. You would then just have ISA bridge to the EV IIS directory over port 443 which is on the bridge tab on the ISA rule. You would then want to set up the link translation rules to have the client go to https. I have no tried this at all so try and test this in a lab before doing it in production.
Hello Elan,
I have some questions for you about this article…
So, i’m using Enterprise Vault 8.0 SP3 ver. with HTTP 80 port to access web application. In general, i have already published in ISA the following exchange 2007 services – OWA, Outlook Anywhere, ActiveSync,…. that’s why we use HTTPS communication, also i need to publish EV in ISA 2006 and that the communication will be secure – encrypted.
It is interested to me that if i change in EV site properties the “Use TCP Port 80” to “Use HTTPS on SSL Port 443” then i will also to implement SSL in IIS of Evault and that’s why then configure the SSL certificate.
Do you know what kind of certificate do i need to use to push then HTTPS on Enterprise Vault.. ?
P.S I’m little bit confused with configuring SSL Port to Enterprise Vault entirely because i’m using HTTP 80 port already, could you suggest me simply how to setup it ?
I have this working with Exchange 2007, TMG 2010 (isa) and EV 8.0 sp2. I did this to get the EV extensions working in Outlook for Outlook Anywhere. Everything works but I am prompted for credentials the first time Outlook tries to do something with EV such as retrieve or store.
Is there a way to avoid this?
Not sure. I've only ever published the EV stuff through OWA as described in the article. The first thought I have is that EnterpriseVault IIS directory authentication doesn't match the Authentication Delegation on the TMG Rule and you get prompted. There are other things such as you may not be using NTLM on the listener with KCD to the IIS directory or Pre-Auth Bypass directly to the server to bypass authentication credentials as NTLM cannot have another auth provider in the middle.
Elan, Thanks for the reply! I think I'm pretty much stuck right now with the extra authentication. My TMG server is not a domain member so constrained delegation is not an option for me. This is a security team decision. I'm sure as soon as the higher ups get annoyed with typing their passwords so many times (Like I don't type mine in 300 times a day!) that they'll lighten up a little bit and just let us optimize our 2007 front ends with our F5 load balancers, which btw, make OWA really scream. This is an excellent article. Probably the most complete on the net in regard to the topic.
Rainy day update:
Executives do not want to type passwords. I will reference this thread later in the future when I tell team-members things like this :) So now it's time to re-engineer some things on the TMG and join it to the domain. I will also be setting up NTLM authentication for Outlook Anywhere so this should be an interesting event.
Tanks for a great blog Elan.
One question for you Elan.
Regarding "There is a bug that prevents you from setting up Link Translation rules that are needed to get Enterprise Vault to work" how will I see the error occur. Or will I not see any error but it just will not work.
The reason I ask is that I do not know whether the “Exchange Web Client Access publishing Rule” was used when the OWA rule was created or “Web Site Publishing Rule.” I do not want to reconstruct the rule unnecessarily.
thanks
Don't think you will see anything in specific. This article was written a while ago and it may work now. When I wrote that, I heard of someone having this issue and that they used a regular website publishing rule which fixed the issue for them. I didn't test it out myself.
I will update the existing rule and see how it will work.
Thank you very much Elan.
Thanks for this info. We toyed with this solution. But having all of our users go out to the ISA server when they are internal was something we weren’t thrilled about due to high availability concerns.
What we have done is we created a second website (with a different IP) on the CAS boxes, configuring it for basic authentication and creating the necessary CAS hooks with powershell. We left the default CAS website as forms-based auth. Then you can direct the ISA traffic to the secondary website using the second IP while leaving your internal OWA traffic to the primary website. This guarantees FBA for both internal and external and the same namespace (if you want) while allowing internal traffic to not require the ISA to be up, etc.
This does make EVault config in web.config a little more interesting since both primary and secondary websites in CAS point to the same OWA dir and web.config. So you have to point the EnterpriseVault_WebDAVRequestHost entry to the secondary website’s IP address. But it all seems to work.
The next challenge was to make Evault in OWA and Outlook work correctly on kiosks (where the windows user is not necessarily the same as the user’s mailbox).
update on my side. this is required for the outlook anywhere rule (if you use outlook anywhere).
1. You’re re-directing all the EV FQDN to the OWA FQDN to avoid the need to have the EV FQDN in the cert. So no.
2. No because again, you’re re-directing the EV traffic to the OWA listener/rule.
3. Depends on how your ISA to AD authentication is set up.
Hi,
Great instructions! Now if I could only get it to work.
1. Is a UC cert required for this method to work?
2. What should the Authentication be set at on the OWA listener?
3. I’m assuming LDAP traffic must be allowed between the ISA server and the internal network?
What I blogged about is 100% OWA. Whether it does something for Outlook Anywhere, I have done or looked into. I’ve published Enterprise Vault using the method I blogged about above for OWA twice at two different client and it’s been successful both times. If you do the above and it does anything for Outlook Anywhere, I’d love to hear so I can update my blog.
I am confused about this custom rule creation. You mention OWA and Symantec mentions Outlook Anywhere. Is this only required for Outlook over HTTPS or both OWA and Outlook Anywhere?
If you have multiple EV sites, I’d assume that you would just create multiple ISA rules for each of your EV Sites and have them all go through the webmail name as I instructed in the article.
Great instructions Elan!
How would this work with multiple EV sites? I’m trying to get OWA working at a place that has multiple EV sites but all use the same url for webmail. the flow is ISA -> CAS proxy -> MB\EV
thanks!
Hi Elan
The instructions works fine.
Thanks a lot
Arif