RSS Subscription 168 Posts and 2,769 Comments

Publishing Symantec Enterprise Vault in ISA 2006

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”

  1. 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.
  2. 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.
  3. Autodiscover.shudnow.net – used so external clients can retrieve external URLs to connect to web distributed services.
  4. 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:

  1. At the minimum, the ISA 2006 Supportability Update is required which is located here.  I would recommend using SP1 instead which is located here.
  2. 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.

Share

BackupExec 11d and Exchange 2007 Problems

I am at a client right now and we are attempting to get BackupExec 11d working with their Storage Area Network (SAN) and a Quantam Scalar i500 tape library system. The issue we are having is that when we try to back up the Exchange Information Store, we are getting an Access Denied message. Naturally with this type of message, we figure that the account on Backup Exec does not have permission to the Information Store. This brings me to this article here. We have properly given the user account all permissions needed to the Information Store. We also tried using a different account that had the same permissions as the article I have just linked, but also ran a couple Exchange Management Shell (EMS) commands to give that user account access to the Exchange Information Stores as well as user’s individual e-mail boxes:

Get-MailboxDatabase | add-adpermission -User “BackupExecAccount” -ExtendedRights Receive-As
Get-MailboxDatabase | add-adpermission -User “BackupExecAccount” -ExtendedRights Send-As
Get-Mailbox | add-mailboxpermission -User “BackupExecAccount” -AccessRights FullAccess

We verified that the BackupExec account does have a mailbox on the Exchange 2007 server and it is not being hidden from the GAL. This user is a local administrator on our Exchange 2007 box due to the user being a Domain Administrator user as well as an Exchange Organization Administrator. I’m not really sure what else it needs access to in order to be able to back up Exchange. We have followed the BackupExec documentation precisely and when that didn’t work, we even tried giving that user account additional permissions to the stores and mailboxes. We even logged on as this BackupExec user and opened up other user’s mailboxes just fine.

So because of all our issues, we initially though we are doing something wrong. Before we began searching on the internet, we ran a few more tests. We found out that when we back up the Information Store to disk, it works fine and we can see navigate the backup granularly. When I say granularly, I mean that we can navigate all the way down to a user’s mailbox. When we attempt to back up to our Quantam Scalar i500, that is when we get our access denied. Because of this new discovery, we figured it was a driver issue. We tried using the generic Microsoft drivers, Symantec BackupExec drivers, as well as Quantam’s drivers. Much to our dismay, drivers did not fix the issue. In addition to this issue, even when we back up to disk, we cannot do any restores.

So this is when we began digging deeper online. I found the following articles:
https://forums.symantec.com/syment/board/message?board.id=115&message.id=7386
https://forums.symantec.com/syment/board/message?board.id=115&message.id=13559

These two links describe the issues we are having. So it looks as though we are not alone. Many other people are having these issues. What I don’t understand is, this is a very big thing. How can BackupExec be released and not have full functionality with backing up to disk? I could understand if it was a driver issue with the tape library system we are using, but it is ridiculous that so many people are having issues with backing up to tape library. Not to mention that when we do actually back up to disk and it works, we have problems restoring items.

So to conclude, I would just like to say that I am disgusted at Symantec for releasing a product with so many issues. Not too mention they were having many complaints regarding these issues and took them several months to acknowledge these issues according to other users. We can only hope now that Symantec will hastily fix their product, do adequate testing, and release a product that works as intended. I will post updates to this as we find out more information.

Update

I feel really bad about posting this blog entry, but we have made a mistake. Apparently the client we were working with applied a registry hack which prevents certain MAPI clients from accessing the Exchange Server. The client implemented this because they wanted only Outlook 2007 clients from connecting to Exchange. You can see the KB article on how to do this here. Since Backup Exec makes a MAPI connection to the Exchange Server, it gets denied since it’s not recognized as an Outlook 2007 MAPI connection. Once this registry modification was undone and the Exchange server rebooted, Backup Exec works completely as advertised. Backup Exec is an excellent product and we have been very satisfied with the product.

Share