Moving Exchange 2013 log files

I'm running Exchange 2013 and ended up expanding a VM's disk that holds the logs for they where growing really large...  Specifically the transaction logs..  I now need to either shrink the disk or just move the logs to a smaller disk and purge this one..  Below are the three different types of Exchange logs on this disk.  Should I just run the various commands and move them?  Or..  Stop all Exchange services.. Mount a new smaller disk.. Copy all contents of E: and then delete the old one and rename the new one to E: ?

E:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics
E:\Program Files\Microsoft\Exchange Server\V15\Mailbox
E:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MB ShaikhCommented:

It is very straight forward, if you want to relocate the location of the logs path to different location then follow the below link

or if you want to purge the logs, just enable the circular logging for the particular database for which you need to purge the logs, then give it some time then exchange will automatically purge logs up to the point where it need the log.
(note :- In exchange 2013 no need to start the Information Store Service where as earlier versions you need to restart the Information Store Service to take this effect.

hope this will help you.
Muhammad AsifSenior Solutions ArchitectCommented:

You may move the Databse edb and logs files folder to another drive with the help of given below thread:

The Exchange logs are not truncated by default. Mostly people take the backup of mailbox database which also truncate the logs as well. If you are not taking the backup of Exchange server then temporarily you may enable the circular loging as suggested by MB Shaikh. Please note that enbaling cirular loging is not recommended solution.

The reason is that, you will not have any option or logs to recover the database incase of any mailbox database corruption or incase of any issue.

The proper resolution of this issue is backup. To take the backup, you may also use built-in Windows Backup solution as well. You may refer to this article for more details:
gopher_49Author Commented:
MB Shaikh,

Your link is for Exchange 2010 not 2013.  I need to move the below log types.

Diagnostics logs
Mailbox logs
Transport Role Logs
IIS Logs
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Todd NelsonSystems EngineerCommented:
Take a look at the references at the bottom of the following article to move the diagnostic logs.  They will be the same for Exchange 2013 and 2016...

If you need to move the mailbox transaction logs, take a look at the following.  Note that you can move the log files separate from the DB files...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gopher_49Author Commented:

I'll have at least 200 GBs to move...  I'm assuming like previous Exchange versions the DB will be dismounted.  Should I get my log issue figured out before moving?  That way it's less to move?
Todd NelsonSystems EngineerCommented:
The diagnostic logs will not require the DBs to be dismounted.

However, if you are looking to move the DB transaction logs, then you should plan for an outage.  Make certain you have a recent successful backup in either case.

An alternate option for DB transaction logs, would be to enable circular temporarily (like MB Shaikh and Muhammad Asif suggested) and then move the log path.  Of course, enabling circular logging also requires a dismount of the database.
gopher_49Author Commented:
I might have to resort to circular logging for it seems there are about 200 GBs that won't Free up
Todd NelsonSystems EngineerCommented:
Are you not running a full VSS backup of your Exchange servers?  If not, you really should because it will clear out the DB transaction logs.

If you don't have a current backup solution, try Windows Backup ...
gopher_49Author Commented:
I am but for some reason there are around 200 GBs that never purge...  Maybe there are 200 GBs always generate within a day or so?  I ran a full backup via VEEAM VSS truncate logs and the next day there where 200 GBs..  Below is my schedule...

At 8pm Mon through Fri I run a VSS copy only job with VEEAM.

Then at 3am Tues through Friday I run an Ahsay offsite Exchange mode log backup job.

Then at 3am on Sat I run an Ahsay offsite job via Exchange mode database.

For some reason logs just keep on building...  Even the next day after a truncate job
gopher_49Author Commented:

Here is my plan of action.  

Take full VSS compliant snapshot backup
Enable circular logging
Move all logs files
Purge old volume
Turn off circular logging
Open a ticket with Microsoft if logs still grow at a super fast pace?
Todd NelsonSystems EngineerCommented:
How many mailboxes are there?

200 GB of DB transaction logs in a day is not normal if you are running one server.  But that will depend on how many mailboxes and mail is being sent/received.
gopher_49Author Commented:
3 x DBs ..  150 mailboxes ..  It seems that around 200 GBs never purge.  I'm hoping circular logging fixes it..  Especially once moved..
Todd NelsonSystems EngineerCommented:
150 mailboxes?  Are you sure the 200 GB is solely DB transaction files.  There are diagnostic logs as well and those will grow more rapidly but they aren't retained for more than 30 days.

Did you make any attempts to remove the diagnostic logs using the first article I provided?  No DB dismount required.
gopher_49Author Commented:
These are only transaction logs..  The transaction log folder by itself will always be at least 200 GBs.  Diag logs are in a dedicated folder...  What file format does diag logs use?  I'll check and see if they are mixed in there...
Todd NelsonSystems EngineerCommented:
Run this command from the EMS to confirm your EBD and log file paths...

Get-MailboxDatabase | fl Name,EdbFilePath,LogFolderPath

Open in new window

IMO, the EDB and log file paths need to be different for each DB.

The EdbFilePath will contain an EDB file and a folder for content indexing.

The LogFolderPath will contain primarily .log files but will also contain tmp.edb, .chk and .jrs files.  Only the .log files in that folder can grow out of control if not kept in check.
Todd NelsonSystems EngineerCommented:
Also, run the following command.  It will tell you whether there is free space within the DBs themselves.

Get-MailboxDatabase -Status | ft -auto Name,DatabaseSize,AvailableNewMailboxSpace

Open in new window

gopher_49Author Commented:
There is the below Free space..

11 GBs
43 MBs
672 KB
gopher_49Author Commented:

If I run VEEAM via truncate VSS mode and void waiting for my offsite job to run I can easily manage the log file size until this weekend...  That allows me to make these major changes on a Friday which allows me a much larger windows to perform a full restore if needed.  I also have instant VM recovery where the VM runs out of the backup and changes are committed later...  I have two other VM restore methods too...  I'm thinking I wait until Friday.  Do you agree?
Todd NelsonSystems EngineerCommented:
If you can tolerate waiting until Friday, it sounds like a decent plan.
gopher_49Author Commented:
I'm running a backup right now...  Once done I'll have plenty of storage until tomorrow night...  It will be just fine until Friday evening..  I'll confirm in the morning ..
gopher_49Author Commented:

It seems that DB is 1.7 in size ?!  I have no manual reg keys.  I assume I need to add the reg key to increase?  Once added what do I have to do?  It isn't dismounted yet.
Todd NelsonSystems EngineerCommented:
It seems that DB is 1.7 in size ?!


I have no manual reg keys.  I assume I need to add the reg key to increase?

What are you referring to?
gopher_49Author Commented:
1.7 TBs and I don't have the Database Size Limit reg keys in place.  I just added them.  What do I need to do for it take affect?  Default limit is 1 TB.  Maybe that's why my logs have grown so large for this DB?
Todd NelsonSystems EngineerCommented:
1.7 TB for 150 mailboxes?!  That's obscene!  I find it hard to believe there is a 1.7 TB DB with only 11 GB free within the DB.

DB size could be a factor but not really sure because it's still only 150 mailboxes.  With only 150 mailboxes, there shouldn't really be that many logs generated.  I recommend you work on creating more databases and making an attempt to evenly distribute by sizes and for easier manageability.  With Exchange 2013 Standard, you can have as many as 5 databases.  With Exchange 2013 Enterprise, that number increases to 100 databases.

Additionally, work on implementing retention policies to remove old or unnecessary mail data.

I'm a little surprised you are asking about log size when you should have issues with DBs over 1.0 TB dismounting--assuming Standard version.  If Enterprise version, there is no DB size limit.
gopher_49Author Commented:
I just added the Database Size Limit REGWORD and set it to 3 TBs to void it dismounting.  Do you think the default 1024 GB limit noted here is why I can'y commit these log files?  I just added the REGWORD key ... How do I make it take affect?  Also.  I just added up my users mailbox usage.  The command "Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select-Object DisplayName, @{name="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}}, ItemCount | Export-Csv "UserMailboxSizes.csv" -NoTypeInformation" generated a .CSV that claims only 836095 MBs is being used in mailboxes?!  Does this mean the log haven't been committed yet and this report doesn't know the correct size?  Something doesn't add up.

How can I force the Database Size Limit change to take affect?
Todd NelsonSystems EngineerCommented:
How do I make it take affect?

Mount the DB.  If the DB was not dismounted prior to the registry change, you will need to dismount the DB and then mount the DB.

Does this mean the log haven't been committed yet and this report doesn't know the correct size?

Again, are you sure your 1.7 TB database only has 11 GB of free space and not 1.1 GB of free space?  Will you post the results of "Get-MailboxDatabase -Status | ft -auto Name,DatabaseSize,AvailableNewMailboxSpace"?
gopher_49Author Commented:
People are about to come to work.. Didn't want to dismount right now.  Below is the output of the command.  DB 7 is the one with the log issues.  Should I dismount real quick?

Name                  DatabaseSize                       AvailableNewMailboxSpace
----                  ------------                       ------------------------
MailboxDatabase-v5-HA 207.4 GB (222,667,210,752 bytes)   11.36 GB (12,202,147,840 bytes)
MailboxDatabase-v6-HA 167.3 GB (179,583,320,064 bytes)   47.81 MB (50,135,040 bytes)
MailboxDatabase-v7-HA 1.708 TB (1,878,108,667,904 bytes) 100.9 MB (105,775,104 bytes)
gopher_49Author Commented:

VEEAM VSS Truncate job is done...  All but 200 GBs is purged in the logs...  I guess the only way to get rid of these logs is to enable circular logging?  No matter what there is always 200 GBs left over...
Todd NelsonSystems EngineerCommented:
If you look into the folder where the log files are, what are the dates of the log files?  They should be no older than this week if your backup has been completing successfully and clearing out the logs.
gopher_49Author Commented:
They are current...
gopher_49Author Commented:
over 110 thousand...
Todd NelsonSystems EngineerCommented:
Yeah...that doesn't sound right if you are getting a proper full VSS backup.  I recommend you contact Veeam to understand what may be going on.  Because after a successful full VSS backup runs, there should be no more than 20 log files that remain.  Hard to believe your single Exchange server would accumulate 110,000 log files in less than a day if Veeam just completed a full VSS backup.  Sounds like a misconfiguration of the backup.
gopher_49Author Commented:
My Ahsay offsite vendor is having the same issues .. VEE purged all but 200 GBs
gopher_49Author Commented:
I'm considering run a Windows Exchange only backup Friday evening
gopher_49Author Commented:

I'll contact VEEAM, however, I got off topic with this thread..  We'll focus back on moving logs files for regardless I have to..  I created a huge virtual disk that needs to be purged..  It's 1.3 TBs..  Just for logs..  I'll jump back on here later today or tomorrow to confirm my game plan for moving the logs..

gopher_49Author Commented:
Due to my recent issues I'm actually keeping drive E: and getting rid of drive D:  I have the below two folders on drive D:  How do I move these?

D:\MonitoringDiagnosticLogs\MSExchangeHMHost      only has one file and hasn't changed since 2-2-18

D:\TransportRoles\Logs\SyncHealth\Hub            doesn't have any files
gopher_49Author Commented:
I ended up following this link and moving remaining folders with all Exchange services stopped, deleting drive letter, adding it back and copying back over.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.