If you have questions about using mojoPortal, you can post them here.
You may want to first review our site administration documentation to see if your question is answered there.
Well this is a strange one that I do not yet fully understand, but I noticed that the System Log on two mojo sites on the same web server stopped working at around 08:45 22 October 2026. No human changes were made at that time.
IIS logging also stopped, about 3 minutes earlier, which must be related in some way, but I don't yet understand that either.
Anyway the issue with the mojoPortal logging is that my sites can no longer write to currentlog.config or indeed any file with a .config extension! This being the mojoPortal default log4net config, and the file name that gets loaded and displayed in the Administration > System Log interface.
If I change the config in log4net.config to write to e.g.
<file value="Data/currentlog.log" /> or <file value="Data/currentlog.txt" /> (etc)
then logging works fine, but I cannot see the log through the admin interface.
I have not yet established what caused this change in behaviour. It feels like a server hardening measure, but no Windows Update was installed that morning, and I certainly didn't do anything. My server in on Azure, and I can see some evidence of some system account activity, that I also don't fully understand yet, about 2 minutes before the change!
Has anyone else encountered this?
And @ mojoPortal people, is there a way of making the System Log page load a different file name? I couldn't see anything in web.config. (I know I could switch to in-database logging though, and might have to do this).
And has anyone seen IIS logging stop at the exact same time and got a solution for that one??
UPDATE: if you do see this issue, I now know it can be a symptom of a compromise of your server. It's not a real change from Microsoft. I'm building a new server and setting up my sites there... Fortunately I've not (yet) found any damage to my sites/content.
I found I had left script permission enabled on the \ClientScript folder of a site, and rogue aspx/ashx files had (somehow!) been created there (the folder was not writable to the application pool identity), and then presumably used to inflict further changes on the server. Check all sites \Data and \ClientScript folders > handler mappings > edit feature permissions > ensure only "Read" is ticked.