Attempting a fresh install on a new Windows Server 2012 R2 VM. Successfully installed PHP 7 on IIS 8.5. Copied SuiteCRM source to a new IIS application. Run the install.php page and I receive a 500 internal server error. Weird thing is I get absolutely no logs or detail. No Application/Server event entries, no PHP error log entries, basic IIS log of the response. I triple checked all of the PHP configuration and my test pages are working correctly. I set the display_errors setting to on and the only change is that instead of the generic html error page I receive a completely blank html page, as in no content between body tags.
I’m not a PHP guy and have never seen this behavior in IIS before. I’ve been through all of the traditional IIS settings, gave the IIS user access to every folder it could ever want, rebooted everything I could think of, and no change. After some googling I found that the @ prefix in PHP suppresses errors so I removed the few of them that existed in install.php and again no change.
I’m fairly crafty and am willing to play around but I just have absolutely no idea of where to start. Does anyone have any tips on debugging this behavior or educated guesses on less-than-random things to try?
I’m not familiar with windows servers, but, I think that by default in windows you need to set the logs to on, another thing to look at is .htaccess, and again I don’t know how this behaves in windows servers, one more thing is your source, maybe is corrupted in someway, try to download it again.
That’s impossible, then your server is not logging, simple as that, you need to check it
Thanks for the reply. I don’t know what other logs to check but everything I know of in the chain shows nothing. I’m not familiar with htaccess but by googling it looks like it’s strictly an apache thing and doesn’t have an IIS equivalent. I’ll try re-downloading the source, that’s a good idea. Thanks again.
I actually have the exact same issue, but with Apache 2.2.9, MySQL 5.5.42 and PHP version 5.5.36 under CentOS. Tried downloading the image again to ensure now file corruptions on the first download and no go. If I roll back to a clean install of 7.6.1, works perfect. Unfortunately, there appears to be an issue opening a handle on Apache’s error log in this case. However, I can generate mock errors with other scripts and the log get written to. Any other reports of this? Any suggestions?
Interesting that you’re receiving the same behavior on a different platform. I wonder if this indicates something more core to the source itself, maybe like a missing dependency that’s not handled well or a bad error handling path.
I haven’t had a ton of time to work on this yet this week but last night I went down the path of re-downloading/extracting the source but still have the same behavior. After reading some posts about similar issues with PHP/CGI error logging I tried multiple combinations of the display_errors, log_errors, and error_logging config settings that yielded different results but nothing useful in terms of getting to a detailed error. Still no windows event logs, detailed iis errors, php log entries, or detailed output to the browser. I also tweaked several IIS settings with the goal of trying to determine if the issue is related to 32/64 bit version or CGI configuration and so far the evidence would point to the problem lies outside of either of these which indicates likely a php execution issue or source issue.
After reading your response I may version 7.6.1 since my next step was to install sugar to at least make some progress on my proof of concept.
Guys,
We use Windows and Ubuntu all the time on our Hosting area.
Save yourself some time and use Xampp for windows it now comes with MariaDB
Just be sure you are careful and secure it - Just google that.
We also use Win 2008 or 2012 in our labs…
Good Luck…
Joe
I’d love to but I’m in an enterprise environment where we only allow IIS apps and SQL server for deployment so I have to get it working on that system. If I had more flexibility I’d just host it and this wouldn’t be an issue.
Sorry to hear that, it will be a long road. MSSQL is not bad we have used it for 20 years, but we never use it with SuiteCRM. If you are using MSSQL because if Enterprise then take another look at MariaDB or MYSQL, I have worked with MYSQL Database systems with 3 and 4 Mil Records.
Good Luck…
Just a quick update that it looks like this happens on 7.6.6 as well with same configuration so no go there. If I have more time to look at this I’m going to start rechecking dependencies but I’m not hopeful that will go anywhere and I may end up just scrapping and going with sugar.
I had a similar (but not exactly equal) problem recently. I was getting error 500 with nothing in the php logs (I read a Stack Overflow article saying that this is known to happen in some situations).
I had different results with different browsers / users (which is strange, being a server error).
The problem eventually solved itself, or maybe due to something I did (but nothing fancy, just log in, log out, repair and rebuild).
