One common configuration issue that is encountered is when a customer wishes to access CRM via both a machine name (e.g. http://crm-server/CRM/eware.dll) and via the internet, using a fully-qualified domain name (e.g.

Typically, they may find that accessing the interactive dashboards may work when on the local network, but not when accessing CRM using the FQDN. Further to this, an issue may occur when selecting a dirll-down option (such as selecting a Communication) from a dashboard gadget.

An example of this may be seen when accessing the My Open Opportunities dashboard gadget to view an opportunity summary. If this issue is present, on accessing the link the page will not load, and a "Page Cannot be Dispayed" message may appear in the user's browser..



The above issues are due to the way that the ManagedFusion rewriter works in v7.1. These issues can be resolved, but require an understanding of how the SDATA redirector works.

The rewriter acts as a transparent proxy: requests to the SDATA application are redirected to the CRM Tomcat webapps without the knowledge of the user. Requests will be proxied if the request matches a value stored in a rules file.

The rules used by the rewriter follow the format used by the Apache mod_rewrite module. The rules themselves are stored in \CRM\Services\IISUtils\CRMRewriter\CRM.Rewriter.rules.

On an un-customised install, a rewrite rule will look like the following for a CRM instance named CRM71:

RewriteRule ^/sdata/crm71j/(.*)$ http://%{HTTP_HOST}:10009/crm71j/$1?%{QUERY_STRING}&originalHostCRMRedirector=%{HTTP_HOST} [P]

Note the values highlighted in blue indicating the CRM instance name and the Tomcat listening port (found in \CRM\tomcat\conf\server.xml).

The rewriter will attempt to match HTTP requests matching the regular expression highlighted in yellow above. The requests will then be proxied to a URL generated using the green section.

As you can see from the above, the green URL is not a literal value - the HTTP_HOST parameter is used to determine the host name that is being used by the client.

Consider a user accessing CRM from the LAN. They may access CRM using the following URL:


A request to the SDATA schema for that install will look like the following:


This is proxied to the following URL using the rules given above:


As you can see, the request will be routed directly to crm-server on port 10009. This port is generally open, and the SDATA schema will be displayed.

Next, consider a user who is accessing CRM using the fully-qualified domain name. They might access CRM using the following URL:

This request would be proxied to the following:$schema&originalHostCRMRedirector=crm-server

Note that would generally resolve to a public IP address. As such, port 10009 would generally be blocked by a firewall. This would result in a failure to load the SDATA schema.

The solution to this is not to open port 10009. Since the rewriter that is proxying the request is resident on the CRM server, we can force the request to resolve to localhost. There are two relatively easy solutions.

The first option is to amend the rewrite to the following:

RewriteRule ^/sdata/crm71j/(.*)$ http://localhost:10009/crm71j/$1?%{QUERY_STRING}&originalHostCRMRedirector=%{HTTP_HOST} [P]

This forces all requests to resolve to localhost.

The second solution is to add an entry to the server's hosts file so that always resolves to localhost. This will force the request to be handled locally, thereby not crossing the firewall boundary. This issue is preferred on earlier realeases of v7.1.

In earlier patches of v7.1, the former solution (changing the rewrite rule) would cause an issue, as the HTTP_HOST variable would be used to generate hyperlinks for some dashboard gadget actions. This would result in errors like the one mentioned at the beginning of this article. A user would be redirected to localhost on their own machine as a result of an attempt to drill down on an opportunity.

Alternatively, if the CRM.Rewriter.rules had been amended so that the request was routed to crm-server rather than HTTP_HOST, this would result in the request failing, as crm-server would not be resolved across the Internet.

The solution to the above issue is to use the originalHostCRMRedirector parameter. This has been available in more recent patches of v7.1 (SP2 and later). By default, this will use the HTTP_HOST value passed in the header of the client's HTTP request. The value passed by this parameter is used to generate the drill-down URLs that are discussed here.

Changing this value so that it points to a hostname or IP address is generally a bad idea, as it becomes impossible to distinguish between users who are on the LAN and those accessing over the Internet, and guarantees that one or the other will experience issues with gadget drill-downs.

The above information is specific to Sage CRM V7.1. Different methods are used for redirection in v7.0 and v7.2.

More information:

The above information is provided for educational purposes. Sage does not encourage editing the contents of the CRM.Rewriter.rules, though we acknowledge that it may be required in some circumstances. Before editing this file, ensure that it is backed up, and consult your local Sage support desk should you need guidance.