EnterpriseVault Archive Folder is not Accessible from the External Clients while accessing OWA Published through Forefront TMG(Threat Management Gateway)

 

Introduction

I have seen a lot of people using Archiving Solutions for Emails from EnterpriseVault. It has been discussed over a period of time in a lot of different forms and ways and in different forums. Recently while working on an issue related to EnterpriseVault I found out an interesting issue. That’s what I am going to discuss with you today in this Blog.

 

Scenario

In this particular scenario we had OWA(Outlook Web Access) Published through Forefront TMG server for the External clients. And we had the Archive Folder on the OWA page which was not accessible when we were accessing OWA from the external clients.

 

Troubleshooting

As part of our normal troubleshooting we gather TMG Data Packager logs from TMG server while trying to reproduce the issue. That’s what we did in this case as well. We also collected the HTTPWatch logs from the Client end. You can download the TMG BPA(Best Practices Analyzer) from the link below and Data Packager is a part of TMG BPA:

https://www.microsoft.com/en-us/download/details.aspx?id=17730

 

And HTTPWatch can be downloaded from the link below:

https://www.httpwatch.com/download/

NOTE: You can only collect logs using Basic version of HTTPWatch. If you have some Troubelshooting Experience or if you want to gather some experience, then you need the Professional version of HTTPWatch so that you can analyse the Logs. But you will need to buy the license for the Professional Edition.

When we looked at the HTTPWatch logs from the client we could see this:

So, as you can see we were getting HTTP Response 400 for all our /OWA/EnterpriseVault/ Directories. And 400 is an Error which denotes “Bad Request”.

For more information on HTTP Responses please refer the article below:

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

 

Then we started investigating the issue backwards to understand where is this “400 Bad Request” coming from. We knew by now that we are definitely not sending something right in our GET Request to the server that’s why it is returning that error. As per the Description of the “400 Bad Request” Error: The request cannot be fulfilled due to bad syntax.

We had an advantage here that our Internal traffic from TMG to the Exchange CAS(Client Access Server) was HTTP. So, we could look at the Network Traces to see the traffic flowing between the TMG and the CAS server. But we still had a challenge to look at the Network Monitor traffic between the External client and External NIC of TMG as it was SSL.

So just for data gathering standpoint we changed the External traffic between the TMG and the Client also to HTTP by changing the Port on the listener on TMG to HTTP Only. And we reverted it to HTTPS after collecting the Traces.

NOTE: Its not recommended to configure TMG to listen on HTTP for the External traffic. It should always be SSL as it is more Secure due to Encryption.

Then we looked at the Network Captures on the External Network of TMG and we Filtered it to see just the /owa/EnterpriseVault Traffic which was of our interest. And we could see something like this:

 

 

Please pay attention to the GET Request which is for a PNG file under the /owa/EnterpriseVault Folder. Then pay attention to the User-Agent Field in the HTTP Header. That shows that the Client Sent the User-Agent Header in this GET Request and we received it as well on the TMG server.

Now, lets have a look at the same Request on the Internal Interface of TMG:

 

 

So as you can see above its same Request which we saw coming from the client to TMG. We are now sending it to the CAS server. But if you now pay attention to the HTTP Headers we don’t have the User-Agent Header in the Request. So, there was something on this Server which was stripping off the User-Agent Header while forwarding the Request to the CAS server.

And that’s the reason the CAS server returns the Error “400 Bad Request” ( as shown in the above screenshot), the same Error which we see on the Client.

So, now we know that the issue is happening because some component on the TMG server is stripping off the User-Agent Header from the Request coming from the Client, while sending it to the CAS server.

But the Point to keep in mind here is, although the User-Agent Header was getting stripped off at TMG Server, it doesn’t necessarily mean that it’s the TMG Application itself which was stripping it off. It could be any other Third-Party Software running on that server as well which can do that. And we even confirmed it by looking at the TMG trace that TMG application was not Stripping of that header(I cant put the TMG trace part here as the TMFs required to parse the TMG Trace BIN File are not available publically and you guys wont be able to Parse it).

When we came to know that its not the TMG Application which was stripping off the Header, we started looking for any Third Party Software installed on the server, because it has to be some Third Party Software which would have been doing it.

And while checking for it we came to know that was a Third-Party Web Filter which was Installed on the TMG server. We could see it under the Web Filters Tab under System.

So, we Disabled that Third Party Web Filter and then tested and after that we were able to Access the Archive Folder on the OWA page while trying to access it from the External Client.

 

Conclusion

Even if we see any particular issue originating from the ISA/TMG server, it doesn’t necessary mean that its this Application which is causing it. ISA/TMG is just one application running on that Hardware. The issue could be with any other Software like an Anti-Virus, Network Card Drivers or some Third Party Web Filter or Application Filter as it was the case in this particular scenario.

All the issues have to be investigated In-Depth in order to get to the Root of the issue.

I Hope it was an Informative Blog.

 

 

Blog Written By

NITIN SINGH

SUPPORT ESCALATION ENGINEER, FOREFRONT EDGE SECURITY, MICROSOFT