Summary:

After installing a second copy of Sage CRM on a machine, the features provided by the Sage CRM webapps may cease to function. This issue can be caused by the first install name being a substring of the second CRM install.



Symptoms:

This issue may arise in the following scenario:

  1. Sage CRM is installed on a machine. The instance name we will use in this example is "CRM".
  2. Another copy of Sage CRM is installed on this machine. This install's instance name contains a substring of the first install, where the trailing characters of the instance name match the first instance name in its entirety. An example of this is "ABCCRM"

An error stating that the CRM rewriter is not working will appear during the installation of the second Sage CRM isntance. On attempting to access the dashboard or other webapp-hosted features in the second instance, an error occurs.

When testing the second install using the "Hello World!" URL (http://crm-server/sdata/abccrmj/), the following IIS error will appear, if the Tomcat instance for the first CRM install is not running:

 

HTTP Error 502.3 - Bad Gateway

A connection with the server could not be established

Most likely causes:
• The CGI application did not return a valid set of HTTP errors.
• A server acting as a proxy or gateway was unable to process the request due to an error in a parent gateway.

 

If the Tomcat instance for the first install is running, then a HTTP 400 or 403 (both authentication-related errors) may be returned.



Cause:

This issue is caused by the SData rewrite rules for the first CRM install taking precedence for those in the second install.

For the first install ("CRM"), the URL Rewrite module may contain a rule as follows:

Pattern: crmj/(.*)$

Rewrite URL: http://{C:1}:10009/crmj/{R:1}

This rule will accept any URL directed to the SDATA rewriter containing "crmj/", and forward it on to the CRMJ webapp hosted on the Tomcat instance listening on port 10009.

 

The second install ("ABCCRM") may have a rule similar to that shown below:

Pattern: abccrmj/(.*)$

Rewrite URL: http://{C:1}:11009/crmj/{R:1}

 

This will take any URL hitting the SDATA rewriter that contains "abccrmj/", and forward it to the CRMJ webapp named ABCCRMJ, hosted on a Tomcat instance listening on port 11009.

At this point, we can see that the first rule will also match all URLs intended for the second CRM install. Here's the "Hello World!" test URL referred to earlier, showing how it matches the first rule:

http://crm-server/sdata/abccrmj/

The issue can be investigated and confirmed using the Failed Request Tracing module in IIS. Using this, you will be able to see the rewrite action that results in the HTTP request being sent to the wrong Tomcat instance.

 

Resolution: 

The issue is easy to resolve. In the URL Rewrite module settings in inetmgr, change the inbound rules so that the rules for the second install appear before those in the first install in the ordered list. If the first installation of Sage CRM is no longer in use, then the old rewrite rules can be removed. Once done, an IIS reset is not required, and Sage CRM does not need to be restarted.