@Julian_Halliwell Bingo, you got it!! I have never seen/touched that. It looks like the default must be different on Win10 IIS vs Server. Every day’s a school day 
My quest for info on Lucee will now continue. THANKS!
Edit: DAMN, I just tested it through a VPN so I could change my IP and it’s not IP restricted, so everybody will get it 
I have detailed error messages now (albeit everybody can see them, but I’m on a clone server with an used domain so I can live with it in the short term)
the CFQUERY was my fault, wrong table name!
the CFFILE issue, appears to be that Lucee is unable to access the drive. I am thinking it’s likely needed to be change to run under a user account
I did indeed need to change the Lucee service to a user account to perform the CFFILE write.
Once I did that I was very excited to see that the site started working, until I tried an account log in and I end up with it taking me to a page that just says OBJECT MOVED
Disappointing I thought this might have been an issue of full compatibility. I will investigate in the morning to see if this is a config issue or the actual code.
There’s another error mode you can set: “Detailed errors for local requests and custom error pages for remote requests”. You can also control it in your web.config file (in your web root) as
<httpErrors errorMode="DetailedLocalOnly" defaultResponseMode="File"></httpErrors>
@Julian_Halliwell I think that is the one I selected. I’ll need to go check.
With regards to my code hitting a brick wall. I found that it was CFLOCATION that was the issue.
Any use of CFLOCATION is failing displaying “Object Moved”
It was using a relative path …/games/index.cfm so I changed it to use the root /games/index.cfm and also tried a full HTTP URL, they all give the same result.
a search of the forum did find this
I located the boncodejp13.settings file but it did not have a reference to <EnableHTTPStatusCodes>False</EnableHTTPStatusCodes> so I added it with the value TRUE, and restarted Lucee. It didn’t fix it
Have you changed the right boncodejp13.settings file? You may have changed the wrong file. Please see this post were I’ve changed the settings in the wrong file:
Thanks @andreas I had a read of that post and got a little lost
I was changing the file in the Lucee folder and not in the Windows directory.
The question I have is what should I be changing in that file?
Thanks
This maybe 
. Sorry for the confusion. Just wanted to show you how easy it is to change settings in the wrong boncode settings file, cause it happened to me once.
ohhhhhhh got it. Looks like I’m a little stuck
Did it work?
I am not actually sure what to put in there after reading that other link that you posted.
I haven’t tried this yet
<EnableHTTPStatusCodes>False</EnableHTTPStatusCodes>
I added the EnableHTTPStatusCodes above to the settings file in the windows folder. It’s still not working but is now giving a little more information apart from Object moved
Please check and adjust your setup:
Ensure that Tomcat is running on given host and port.
If this is a timeout error consider adjusting IIS timeout by changing executionTimeout attribute in web.config (see manual). [2023-09-08 14:52:29 ]Generic Connector Communication Error:
Hmmm, this looks more like your setting is breaking the connection. Can you change the setting back to the initial setting and show the server response headers of that “Object Moved” you had?
Previously there was no entry at all there, I set it to TRUE, and it gives the same result as if it was not there, as in just displaying OBJECT MOVED and nothing else.
Can I pull more info from Chrome?
Yes, you should get the server response headers from the chrome dev tool. Or you can get them also with curl.
I’m not great with the console, is that the PROPERTIES?
On another note. I set up a simple page, literally a CFLOCATION to a page with a drop of text and it works, but the other CFLOCATION on the other page, very odd. I tried changing the location of the file, such as not jumping from one directory to another, staying on the same page, but still the same issue.
You need to find out, what is happening in detail. In Chrome press F12 to open “chrome dev tool”, then click the “network” tab. You may need to tick the “preserve history” option. Clear the history and do a reload of the page that has the issue. Then click on the page that was loaded, and you will see all client data sent and the servers response data.
Can you also try accessing your app directly through port 8888 to see if the issue is persisting there too?
Does this help?
Access-Control-Allow-Origin:
*
Cache-Control:
private
Content-Encoding:
gzip
Content-Length:
184
Content-Type:
text/html
Date:
Sun, 10 Sep 2023 12:01:32 GMT
Strict-Transport-Security:
max-age=31536000; includesubdomains
Vary:
Accept-Encoding
X-Aspnet-Version:
4.0.30319
X-Content-Type-Options:
nosniff
X-Frame-Options:
SAMEORIGIN
X-Powered-By:
X-Xss-Protection:
1;mode=block
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding:
gzip, deflate
Accept-Language:
en-GB,en-US;q=0.9,en;q=0.8
Cache-Control:
max-age=0
Connection:
keep-alive
Content-Length:
57
Content-Type:
application/x-www-form-urlencoded
Host:
dailymessage.com
Origin:
http://dailymessage.com
Referer:
Upgrade-Insecure-Requests:
1
User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
Have you also tried accessing the app though port 8888 to see if the issue happens also there (to isolate an IIS issue from Tomcat)?
I’m also missing the 'Location:" header in your request. Have you set the preserve log? See: debugging - How to enable "Preserve Log" in Network tab in Chrome developer tools by default? - Stack Overflow
Important: please mask the cookie header when you post it here.
I’m having trouble getting it to respond using port 8888.
I found the preserve log issue, tried the page again and it looks like I have the same info (cookies removed from this and the above)
Access-Control-Allow-Origin:
*
Cache-Control:
private
Content-Encoding:
gzip
Content-Length:
184
Content-Type:
text/html
Date:
Mon, 11 Sep 2023 06:56:08 GMT
Strict-Transport-Security:
max-age=31536000; includesubdomains
Vary:
Accept-Encoding
X-Aspnet-Version:
4.0.30319
X-Content-Type-Options:
nosniff
X-Frame-Options:
SAMEORIGIN
X-Powered-By:
X-Xss-Protection:
1;mode=block
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding:
gzip, deflate
Accept-Language:
en-GB,en-US;q=0.9,en;q=0.8
Cache-Control:
max-age=0
Connection:
keep-alive
Content-Length:
57
Content-Type:
application/x-www-form-urlencoded
Host:
dailymessage.com
Origin:
http://dailymessage.com
Referer:
Upgrade-Insecure-Requests:
1
User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36