“Slow Performance” accessing CRM IFD published with ISA/TMG

This is an awesome technet blog done by Philipp Sand (Microsoft CSS Forefront Security Edge Team), now I had the same issue where my IFD TMG implementation was extremely sow, only after applying his method did things speed up and I could see a massive improvement not only on the browser but on the Outlook client as well…

So herewith his method:

Scenario:

Consider the scenario, where your CRM IFD is up and running. You setup the publishing rule in TMG and everything appears to work as expected. Now you start sending the information about the published CRM to your users in their home office. A few minutes later you receive the first calls from users complaining that accessing the CRM IFD is terribly slow from their home office.

Time to look at the TMG now, to answer the question: WHY ISN’T TMG COMPRESSING THE TRAFFIC?

First of all you have to verify if compression is enabled. This can be verified when you open the Web Access Policy and open the HTTP Compression settings:

Next you should select the “Return Compressed Data” tab, to verify if the Listener you use in your CRM web publishing rule is listed there. It should be listed by default, the listener is called CRM Test in this case:

The next thing you should verify is which Content Types will be compressed at all, by clicking the Content Types …button.

This will show the following list of content types:

As you can see TMG doesn’t compress all content types by default, only those which are configured in HTML Documents and Text.

To verify what’s configured in those two content types, you have to open the properties of the content types using the Toolbox:

As you can see neither in HTML Documents nor in Text you can find an extension or content type which matches the “TOP TALKERS” from the Fiddler trace. That’s why TMG isn’t returning the traffic compressed.

You may ask yourself now, why isn’t TMG compressing everything by default to save bandwidth?

Here’s a good answer from TechNet:

In general, some Web servers, when responding to a request, do not accurately provide the content type in the response header. For example, a response may include a Microsoft Office PowerPoint® 2007 (.pptx) file, but the response header may indicate that the content is plain text. When an Internet Explorer client receives this type of response in compressed format, it cannot interpret the response, and the user sees meaningless characters on the monitor. If the response is received uncompressed, Internet Explorer can interpret it, and the user can open and view the content.

http://technet.microsoft.com/en-us/library/cc995227.aspx

Button Line: It’s all about user experience. The scenarios where compression can break a website are more common than the scenarios where it helps to improve the user experience.

Note: By default TMG won’t ask for compression, when you use it in as forward proxy configuration, to provide the best user experience.

Of course there can always be scenarios, where you might need to add specific content types to the compression List, in order to provide a better user experience. Publishing CRM 2011 IFD is one of these scenarios.

In order to enable the compression for the “TOP TALKERS”, please do the following:

1. Configure a new Content Type set, including the content types which are listed in the TOP 3 of the TOP Talkers:

application/x-javascript

text/javascript

text/xml

2. Open the Compression settings -> Return compressed settings -> Content Types… and select the CRM content type you just created.
3. To verify if the changes had been applied correctly, you can start another fiddler trace from your client. When you use the Inspectors again, you can see that the RAW content is compressed / non-human readable.

Access to the CRM should be much faster now for users with slow bandwidth.

I hope you can find this article useful.

Update:

We found that some customers experienced some performance issues, even after applying the changes as described in this blog article.

When investigating in this performance issues, we found that you can add another performance boost to the client access when you enable the compression between ISA/TMG and the CRM server.

By default ISA/TMG won’t ask for compression for the traffic between ISA/TMG and the published web server. This is because compression always causes some CPU overhead (compression / decompression) on the Web Server and on TMG, and compression to save bandwidth usually isn’t needed in current LAN infrastructures.

In order to enable the compression between ISA/TMG and the CRM Server, you have to open the HTTP Compression preferences, and select the “Request compressed data” Tab this time.

Add a new Computer Object, which describes your CRM Server, and add it to the list:

Requesting compressed data, changes the way the CRM server generates the responses. With these changes we could observe a much better caching behavior on the client. Which results in a much smaller number of requests the client has to send to the published CRM IFD Web site.

We’re currently investigating in the details of this behavior. We will provide more detailed information once we’ve completed our internal investigations for this behavior.