I've noticed this bug too and have reported it to SM.

We have over 340GB of logs in this folder, which would compress down to less than 1GB if the logs were being written to the correct folder!

I reported also to SM but was told that these are logs specifically relating to the SmarterMail web interface and con not be moved.

The problem is that even setting them to exception only they are getting to be nearly 50 GB a month and as they are on the c drive and can not be moved to have manually delete the logs.

Really need for SM to allow them to be moved or reduce the size of these logs.

Maybe using a symlink will allow us to relocate the log files.

I'll test this out when I get a chance!

If they can't be moved then ST should make sure that the auto compression and deletion of logs files is also applied to this folder too.

I am sure I tried a symlink and it did not work. Could be wrong though as it was nearly a year ago that I looked in to this and contacted SM support.

So, I'm revisiting this since upgrading to v17.

Now I'm seeing the following logs being written to the  C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\Logs folder.

DebugLog 2019.07.10.txt

SignalRLog 2019.07.10.txt

2019.07.10-SharePoint.log

ErrorLog 2019.07.10.txt

2019.07.10-bosh-xmpp.log

Some of the other files, previously reported, are now being written to my correct log directory (S:\Logs).

It's possible to copy historical log files that are now being written to the correct folder (i.e. EWSLog 2019.01.12.txt) and this doesn't break searching the logs within the web interface.

However, the auto-compression of these log files doesn't work anymore. This appears to be caused by the name format of certain files being changed.

Taking the EWS log as an example, I have 300+ log files (over 340GB) in the C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\Logs folder. The format of the filenames is EWSLog 2019.01.12.txt, but SM is now writting these files to the correct logs folder and naming them like 2019.07.10-ews.log.

So, I copied all of these old EWS log files to my correct log directory and then ran the following Powershell script, which renamed all the files for me.

Get-ChildItem "S:\Logs\EWSLog*" | Foreach { Rename-Item $_ ($_.Name -replace "EWSLog ", "" -replace ".txt", "-ews.log") }

Now these new files will be compressed when the daily maintenance task runs!

I also opened this thread on this subject: https://portal.smartertools.com/community/a91932/unify-log-locations-for-smartermail.aspx

I do not understand why we would have to work out scripts and solutions ourselves for this - is it impossible for SM to write all logs to a designated folder configured in the web interface?

We have most logs being written to the correct folder (what we configured), but some are still written in DRIVE:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\Logs, including very large YYYY.MM.DD-bosh-xmpp.log files written there daily (this is not our configured location).

I recall someone mentioning that the logs within the C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\Logs folder had to be stored there as they are written by a particular process.

Ideally, these logs should be located within the custom log path that you can set with SM.

At a minimum, ST need to ensure that the log auto-compression rules apply to these files too - just like they do with the Message Sniffer logs (which are stored in C:\Program Files (x86)\SmarterTools\SmarterMail\Service\SNF).

I agree.  We have SmarterMail domains & log data stored on a D: drive.  I expect a program to be as self contained as possible, not having crap scattered all over the place.  So when i say "put it on Drive D:"  I mean everything. ALL data, not bits and pieces. For me, this would ideally even include all of the configuration data.   oh.. you want reliable backups ?  "yea, sorry, only got partial backup because you did not specify the 99x locations of where we scattered the data at. and now its gona take you 6 hours to get smarter mail back up and running"  

Ideally i would like to be able to take smartermail, install it, and have all of the data, confugration, etc, etc... everything - at a location we specify.  Then, for an upgrade, restoring a backup, repair or to move it to a new server, just zip up the data, install smarter mail at the new location, drop the data, unzip, point smarter mail to the data location, press start, and it is fully functional again.  Self contained data bundle.

Haven't migrated to SM17.... can you confirm or post...  are the logs, directories.. still  being ignored???

As of Build 7125, logs are still all over the place. Some go to the folder you specify, some remain in the SM Program folder in MRS\App_Data\Logs

uugghhhhh...  We don't like any logs written to the C: drive.. AND we need know exactly where they are being written to...

Thank you for the update.. Appreciate it

We installed SM to another drive to avoid this, but we also have a separate drive where we would like to store the logs, but only a part of them go there. So, we have logs in 3 locations:

1. IIS logs are on C:\

2. some SM logs are inside the SM install folder on drive D: (for example)

3. some SM logs are on a folder on drive E: (example) - the ones that actually listen to the configuration we entered in WebMail

We know how to move the IIS logs, but would like to have the logs at point 2 also go in the folder at point 3.

Thanks for the update...
The IIS logs are controlled by IIS.. so no worries.

We do NOT install anything on the C:\  if at all possible.. 

we have and will spread SM17 similar to what we are doing to SM15

  * Logs - go to one physical drive/logical drive.

  * Domains / email to several other physical drives

  * Spools to yet another separate physical drive.

Hope that is  Sm Tools folks will chime in on this.....  

Thank you Ionel  for the update.

**BUMP**  
So i am trying to trouble shoot why SM17 will not send out any emails....

There are  ZERO logs.. in the location that they are supposed  to be .. thus there are zero logs to trouble shoot with.

~~~

I how do I trouble shoot something that I can't see ???

~~~
Logs should be located on K:\Drive ...

Merle,

Since you have active Maintenance and Support on your license key, I would suggest opening a ticket with Support directly so that one of our technicians can get eyes on your server and help troubleshoot.

Thank you for the suggestion.

Found the logs....

but wish SM would mark this with the tag of "being fixed"  ...  Reason that the logs are located on different logical drive is to keep things as fast as possible....

After a reboot for regular Win updates... SM is now going to correct log location...   but didn't do that by simply restarting the SM service.   Not sure if it related or not but also when the server re-booted.. SM service didn't start automatically.. received this:

=======
[10/2/2019 4:55:46 AM]

System.UnauthorizedAccessException: Access to the registry key '230' is denied.
   at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
   at Microsoft.Win32.RegistryKey.InternalGetValue(String name, Object defaultValue, Boolean doNotExpand, Boolean checkSecurity)
   at Microsoft.Win32.RegistryKey.GetValue(String name)
   at System.Diagnostics.PerformanceMonitor.GetData(String item)
   at System.Diagnostics.PerformanceCounterLib.GetPerformanceData(String item)
   at System.Diagnostics.PerformanceCounterLib.GetCategorySample(String category)
   at System.Diagnostics.PerformanceCounterLib.GetCategorySample(String machine, String category)
   at System.Diagnostics.PerformanceCounter.NextSample()
   at System.Diagnostics.PerformanceCounter.NextValue()
   at MailService.Core.MailServerStats.UpdateRealTimeStats(Process mailServiceProcess)
=======

not sure if the two things are related or not...