IIS 7 and Above
URL Rewrite Module
RewriteModule Error - Cannot create a file when that file already exi...
Last post Dec 04, 2018 02:06 PM by tulsaconnect
Dec 03, 2018 03:31 PM|tulsaconnect|LINK
We have started getting the following error on several IIS servers (HTTP Status Code 500). We are running the latest build of URL Rewrite 2.1 (which seems to be 7.1.1980.0) on Windows Server 2012 R2. When the issue occurs, it typically occurs on ALL websites
on the server. A reboot of the server does not fix the issue -- uninstalling and then reinstalling the URL Rewrite module typically fixes it for a while, but it tends to come back. The Event Log does not provide any clues. Any help would be appreciated.
Taken from a trace:
HttpReason URL Rewrite Module Error.
ErrorCode Cannot create a file when that file already exists. (0x800700b7)
Dec 04, 2018 09:26 AM|Brando Zhang|LINK
As far as I know, 500.50 is rewrite error occurred during RQ_BEGIN_REQUEST notification handling. A configuration or inbound rule execution error occurred.
The error ’Cannot create a file when that file already exists.‘ mean a binding host header may conflict on the target server. So firstly ensure that you are not sharing the IP address/port on IIS unless you have set the host name on the binding on the target
website. If the target server already have the same binding, it could display the error message.to solve this issue you could try to remove the other website or change the port for your website.
For more detail about what is the actual problem try to use “Failed Request Tracing
Rules” feature to find out the reason.
Dec 04, 2018 02:06 PM|tulsaconnect|LINK
Thanks for the reply. The issue is now fixed, I am including as much detail as I can here in case anyone else runs across this in the future.
The log snippet I pasted originally was indeed from the Failed Request Tracking log. One bit of additional info I did not include on the original report was that we run Plesk Onyx (a web hosting control panel) on this particular IIS server. It turns out
that the problem was with the way Plesk was creating URL Rewrite rules, and not with the extension itself. Specifically, when you would create rules via the control panel (they were specifically rules designed to secure Wordpress instances), they would show
up inside IIS's GUI under the Rewrite Rules area, but they were NOT being written to the web.config file (maybe they were in the IIS metabase at that point? Not sure).
So, in troubleshooting this, I discovered that if I disabled each rule via the IIS GUI and then re-enabled them, they would then get written to the web.config properly and then the site would start working again. Yesterday a KB article appeared on the Plesk
support site (not sure I can link it here - but search for EXTWPTOOLK-2191 in Google and you will find it) that contained a fix for the issue (which involved upgrading a component of Plesk).
So, it did not have anything to do with host headers in this case. I am still curious as to what exactly the bug was, as it was very frustrating to diagnose.