CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage


I have installed a new complete SO8SR4 environment to which I have migrated a 7.5-database. The new environment were initially set to be using FCGI, the old 75-environment (which only had CS installed) were set to use CGI (.exe).

I have done all changes I can come to think of, but the login-page for CS is ALWAYS automatically routing to rms.exe instead of accepting rms.fcgi. After login, all other pages is using .fcgi as expected though.

* I have set reg_id 251 in crm7.registry to ".fcgi".
* That made CS use FCGI on all pages but the loginpage
* Then I set the reg_id 260 (Setup has asked for setting up FastCGI) to 0 and ran the upgrade.exe again to to get the question to enable FCGI and have the installation application set all possible .FCGI-settings in the environment.
* That didn't seem to work either.
* I have flushed caches on the debug-page in CS
* I have restarted App Pools and sites, etc.
* As this only affects the login page, I can't see any type of script that potentially could affect this.
* I have done backups of the IIS-settings using appcmd and compared those settings-files to backups of other environments, without finding any noticeable differences. Especially not when it comes to the CGI-related settings of the IIS.
* I think it worked with logging in via *.FCGI with the clean install DB, so it seems related to some setting in the database.
* All parts that I have tested seem to work in the implementation, but there are errors in the upgrade.exe that probably might be the cause of some problems.

Noted Problem after CS upgrade.exe
* reg_id=158 (Used for version checking ejSender) were still set to "7.5.1000.0" but "ejSender.exe -about" gives Version: 8.0.1000.0
* That generated the error: "[05352] [(System) ] [ejournalCron] 2017-04-18 08:52:08.686 [0.084] [0.084]: Wrong version of ejSender. Please contact local support to correct the installation."
* This have now been fixed using UPDATE crm7.REGISTRY SET value = '8.0.1000.0' WHERE reg_id=158
* No changes
* It seems that some part of the upgrade of CS don't complete as it should
* The Command-prompt is started in elevated mode
* The folder in the FileException exists (D:\superoffice\so_cs\bin)
* Windows Registry-settings for the CS-site is correct

D:\superoffice\so_cs\bin>upgrade.exe -dbDebug -verbose
Domain: cs.localcustomerdomain.se
Your Name [adm_soadmin]: xxx
Connect to so80 as crm8?(y/n): y
Checking netserver connection...
Upgrading from version 8.0.1000.0 to version 8.0.1000.0
Updating notice frame data...
Updating wsdl descriptions...
Updating dictionary base...
Sending license info to eJournal...
Setting config.version...
Updating html reports...
Upgrading/installing html reports...
Registering ejSender version...
Deleting messages without ticket connection...
Cleaning up profile duplicates...
Resetting postponed date for non-postponed tickets...
Enabling custom notify for users...
Upgrading eMarketing templates...
Exception caught in main()
FHFile::FileException: fopen("c:\ejournal\config", "rb" + failed, errno=No such file or directory; cwd=D:\superoffice\so_cs\bin
Stopping old/crashed mailings
Update packages...

Package compactMode version 22 is up to date, no need to upgrade
Package Macro foundations version 16 is up to date, no need to upgrade
Package Split request screens version 11 is up to date, no need to upgrade
Package System screens version 152 is up to date, no need to upgrade
Do you want to start the ejScheduler service?(y/n): n
Updating cachetable...
Upgrade done.

1. Is there some other setting, but the reg_id=251, in the database that could make CS behave this way?

2. Is there some IIS-settings that could make CS behave in this way?

3. Could file security settings of files in the CS-folder affect this in some way?

4. Could Reg_ID=261 (Use Impersonation for FastCGI) affect anything like this? In which cases should this setting be enabled?

5. Anybody knows which activities that is happening at the state of the error in the upgrade?

If anybody have some experience of this and have a solution, I would appreciate some feedback! :)

Best regards

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

Usually you don't have to change anything in registry to enable fcgi.

Have you tried running upgrade.exe -onlyFcgi  ? It should install everything correctly.

I also assume you've set up the correcet handler mappings and enabled CGI in the ISAPI configuration.

Av: Simen Mostuen Iversen 18. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

I haven't done any manual addings but the handler mappings seem to be there (on the scripts-level in the IIS). I can't see any mapping missing for the rms-part either. Everything works as it should with fcgi after login, so that doesn't seem to be the problem.

Yep, the "Allow unspecified CGI modules" is enabled, if that is what you mean. Even if my understanding, based on different articles concering configuring CGI-modules, is that this shouldn't really be necessary and actually doesn't seem to be recommended due to security risks. According to Stian it shouldn't be needed if everything else is correctly set up. According to Margrethe, this setting needs to be enabled for the SOAP-API to work in CS for Web Tools (Archive as request). But I haven't digged deeper in WHY this actually should be necessary for the SOAP-API to work (if everything else is set up as it should).

To be honest, I can't see from my logs that I have tried out the "upgrade.exe -onlyFCGI", I might have missed that one. Though, I did the workaround with setting reg_id=260 to 0, to automatically get the question while running upgrade.exe without the argument. So I suppose that should do the same thing, but I can't be sure of course. But all parts seem to be there in the IIS at least. I don't know what other parts in the database that could affect this part.


Av: Marcus Svenningsson 19. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

Can now verify that running "upgrade.exe -onlyFCGI" did not do any difference for the loginpage routing problem.


Av: Marcus Svenningsson 19. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

Hi, do you mean that when you go to https://service.yourserver.com, then you are redirected to https://service.yourserver.com/scripts/rms.exe instead of rms.fcgi?

Have you checked the contents of the default.htm/index.htm file in /CustomerService/www/doc folder?

Av: Frode Lillerud 19. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

Whichever way trying to access rms.fcgi will automatically switch to rms.exe.

Nothing in Event viewer, nothing useful in IIS/CS/CSNS logs. 

Frode, what shall we check in those files?

Av: Emilija Vilija Treciokaite 20. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

Error in upgrade.exe - Solved

I have now identified, what seem to have been, the cause of the error during running upgrade.exe.

While changing the hostname for CS I missed the "http://"-part of the URL for the settings "cgi_url" and "cgi_url_internal" in the CONFIG-table, so they only included the hostname and not the whole url. :)

After adding that, upgrade.exe went through without errors.

Though, it still didn't update the version-number for ejSender in reg_id=158 in the REGISTRY-table. Before the upgrade, I changed it back to the old version number just for test purposes, to see if it would be changed when all parts seemed ok for upgrade.exe. Why this didn't get set, I don't know, but it might be related to other settings already having been set as the upgrade.exe have been run 11 times with different fixes in between.

That the implementation did work as well as it did, despite the missing "http://" surprised me a bit. But got explained by Stian that it isn't used as much as one thinks.

Stian: "Cgi_url and cgi_url_internal isn’t used very much. In normal web communication is uses what the browser gives back. But when creating for example emails with direct links, this is used (and in mailing)."

Loginpage reroute - Still not solved

The above changes didn't change the behaviour of the loginpage though. It still routes to rms.exe all the time.

Av: Marcus Svenningsson 20. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage


No, when going to "http://cs.domain.net/scripts/rms.fcgi" it always routes to "http://cs.domain.net/scripts/rms.exe". It also goes to that page at logout of CS.

So I suppose it shouldn't be dependent on "defaultDocument" in any way, if that is what you had in mind?

But for the record, if using the url "http://cs.domain.net/scripts/", it doesn't route to the rms.exe-page, but instead shows a "HTTP Error 403.2 - Forbidden" (You have attempted to view a resource that does not have Read access.).

Based on the settings in the web.config it looks like directoryBrowse should be forbidden, but I don't know why it isn't routed to the rms.exe in that specific case.

The web.config in scripts don't seem to contain anything out of the ordinary:

<?xml version="1.0" encoding="UTF-8"?>


<handlers accessPolicy="Execute, Script">
<add name="FastCGI help" path="help.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\help.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI spm" path="spm.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\spm.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI stat" path="stat.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\stat.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI blogic" path="blogic.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\blogic.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI customer" path="customer.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\customer.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI admin" path="admin.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\admin.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI document" path="document.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\document.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI ajax" path="ajax.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\ajax.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI rms" path="rms.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\rms.exe" resourceType="File" allowPathInfo="true" />
<add name="FastCGI ticket" path="ticket.fcgi" verb="GET,HEAD,POST" modules="FastCgiModule" scriptProcessor="D:\superoffice\so_cs\www\scripts\ticket.exe" resourceType="File" allowPathInfo="true" />

<directoryBrowse enabled="false" />

<clear />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="index.html" />
<add value="iisstart.htm" />
<add value="default.aspx" />
<add value="rms.exe" />


Av: Marcus Svenningsson 20. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage


I'm afraid that I read your comment a little bit too quick... :)

No, I have not. As there is no such file in my doc-folder. Neither is there anything out of the ordinary in the web.config in the doc-folder.

I have checked the corresponding index.htm file in the \doc\agent-folder though, and that file includes a static route to rms.exe instead of rms.fcgi.

But my assumption was that this shouldn't affect the normal loginpage-parts but some other function relating to "agents", what that now is.

Av: Marcus Svenningsson 20. apr 2017

RE: CS routes (or fallbacks) from rms.fcgi to rms.exe automatically on the loginpage

This has to do with two System settings for SSO.

If SSO is used, settings should be like in the screenshot, but then login page will run rms.exe

If SSO is not used, settings should be disable and rms.fcgi will work

Av: Emilija Vilija Treciokaite 19. jun 2017