How can you monitor the effectiveness of background maintenance tasks? Moving logs to another location.

The need to defragment mail databases in Exchange Server 2010 arises due to the fact that when information is deleted from the database, it is not automatically compressed (remains blank pages), and accordingly the size of the database file does not decrease. For example, if you transfer user mailboxes from a 20 GB mail database, overall size 5 GB, then the file size will remain unchanged 20 GB. However, the released 5 GB of “free” space will be used by new elements in the future.

Therefore, if you need to reduce the size of the mail database file in Exchange 2010 by removing unused pages, you can use one of the following techniques:

• Create a new database, transfer all the boxes to it and delete old database
• Perform offline defragmentation of the current database

Each of these methods has its pros and cons. Offline defragmentation involves downtime of user mailboxes, but it is the only affordable solution in case of shortage disk space(you simply have nowhere to create a new database).

On the other hand, migrating boxes to a new database is a less risky procedure, but in addition to the need to have enough free space for storing two mail storages, generating a large number of transactions also significantly increase the requirements for available free space, and as a result, the user migration process may take several days.

It is necessary to clearly distinguish between the processes of offline and online (interactive) defragmentation of the Exchange 2010 database. Interactive defragmentation in Exchange runs constantly when the option is enabled Enable background database maintenance (24 x 7 ESE scanning). This procedure is performed in background includes removing obsolete elements from storage and optimizing page layout. The main goal is to free up unused space by compressing records to the minimum number of pages possible to reduce the number of I/O operations. Note that unused space is not returned to the system. Offline defragmentation allows you to free up this space.

Determining the amount of free space in the Exchange 2010 database

To find out the current size of the database and the amount of free space in it (those unused pages) in Exchange 2010, run the following command in the Exchange Management Shell:

C:\>Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto

Name DatabaseSize AvailableNewMailboxSpace—- ———— ————————

WI-DB-01 17.26 GB (18,604,766,720 bytes) 8.544 GB (9,247,766,016 bytes)

IN in this example it can be seen that the current size of the WI-DB-01 database is 17 GB, and there is as much as 8.5 GB of free space in it. And if you want to free up this space, the size of the mail database file can be reduced by defragmenting it with the ESEUTIL utility.

NOTE. If your server is part of a DAG group Notusegiveninstructions!

Preparing to Defragment Exchange 2010

When planning database defragmentation, you need to clearly understand that in order to complete this work, you need to unmount the necessary base, that mail is unavailable for all users in this database.

Next, you need to make sure that there is enough free space to perform defragmentation. The defragmentation process creates new file database and the disk simultaneously store the old and new file, in addition, additional space is needed for temporary files created by the eseutil utility.

So if you are going to defragment Mail Exchange, you must have free space equal to at least 110% from the current database size (excluding empty pages).

In my case, this means that we need to have at least 9.6 GB of free disk space:

17.26 – 8.54 = 8.72

8.72 x 1.1 = 9.6

If the current disk does not have this amount of space, you must specify an alternative location for temporary files in the eseutil parameters. This may be another drive or a network UNC path, however, please note that if you use a UNC path, defragmentation time may increase significantly due to bandwidth and network delays.

You also need to make sure that you have an up-to-date backup copy of the database being defragmented, so that there is no excruciating pain later...

Using ESEUtil to defragment the Exchange database

Open command line Exchange Management Shell and go to the directory with the mail database file:

Cd D:\Data\WI-DB-01

Let's unmount the base.

Dismount-Database WI-DB-01

We start defragmentation using the ESEUtil utility.

D:\Data\WI-DB-01>eseutil /d WI-DB-01.edb /t\\tmp_srv\exch\temp.edb

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server

Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating DEFRAGMENTATION mode…

Database: WI-DB-01.edb

Defragmentation Status (% complete)

……………………………………………

Moving ‘\\ tmp_srv\exch\temp.edb’ to ‘WI-DB-01.edb’…

File Copy Status (% complete)

0 10 20 30 40 50 60 70 80 90 100

|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|

……………………………………………

It is recommended that you immediately perform a full backup

of this database. If you restore a backup made before the

defragmentation, the database will be rolled back to the state

it was in at the time of that backup.

Operation completed successfully in 2798.218 seconds.

Mounting the base:

Mount-Database WI-DB-01

Let's make sure that its size has decreased:

Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto

Name DatabaseSize AvailableNewMailboxSpace

—- ———— ————————

WI-DB-01 8.328 GB (8,942,190,592 bytes) 5.219 MB (5,472,256 bytes)

WI-DB-02 14.63 GB (15,785,670,144 bytes) 4.696 GB (4,968,761,856 bytes)

WI-DB -Archive-01 658.1 MB (689,542,784 bytes) 234.6 MB (241,164,544 bytes)

(Short notes)

When the database has approached its limit (for example, 100 GB), you need to start moving some mailboxes to a new database. Which boxes should be moved to stabilize the size of the mail base?

It is clear that those mailboxes, which noticeably increase in size. But in order to identify such mailboxes, you need to regularly take statistics on mailboxes and analyze it.

If such a process is not established, then you can rely on some heuristic statements (controversial, but useful for a start).

1. There is no point in moving mailboxes that have already reached or will soon reach their maximum allowed size.

2. There is no point in moving mailboxes that have been around for a relatively long time (created a long time ago) and remain small or stable in size.

GUI is used to move the user's mailbox or the New-MoveRequest cmdlet

ExchangeServer 2010 allows you to move a mailbox to another database without interrupting the user's work.http://blogs.technet.com/b/exchange/archive/2011/01/24/3411868.aspx

The number of simultaneous copy threads is limited. This protects the server (storage) from overload. Copying can take quite a long time.

After the move, the mailbox in the source database is marked as SoftDeleted. (starting from SP 1 http://technet.microsoft.com/en-us/library/dd298174.aspx )

Get-MailboxStatistics -Database "Mailbox Database 01" | where ( $_ . DisconnectReason -eq "SoftDeleted" )

After moving mailboxes, the original database is not reduced in size or freed up space:

ServerName	Name	DatabaseSize	AvailableNewMailboxSpace
———-	—-	————	————————
MB2	Mailbox Database 01	101.4 GB (108,859,031,552 ...	5.7 MB (5, 976 , 883 bytes)
MB2	Mailbox Database 02	75.26 GB (80,807,526,400 b…	2.5 MB (2, 621 , 440 bytes)
MB1	Mailbox Database 03	53.88 GB (57,856,294,912 b…	12.28 MB (12,877,824 bytes)
MB1	Mailbox Database 04	26.88 GB (28,865,265,664 b…	87.63 MB (91,881,472 bytes)

After the transfer is complete, you need to check the success of the process and remove requests to move through the GUI or

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest -Confirm: $false

You need to delete SoftDeleted mailboxes:

$b = Get-MailboxStatistics -Database "RUMS Mailbox Database 01" | where ( $_ . DisconnectReason -eq "SoftDeleted" )

$b | % ( Remove-StoreMailbox -Confirm: $False -Database $_ . database -Identity $_ . mailboxguid -MailboxState "SoftDeleted" )

After this, free space will appear in the source mail database:

Get-MailboxDatabase -Status | select ServerName , Name , DatabaseSize , AvailableNewMailboxSpace

ServerName	Name	DatabaseSize	AvailableNewMailboxSpace
———-	—-	————	————————
MB2	Mailbox Database 01	101.4 GB (108,859,031,552 ...	55.97 GB (60,094,939,136 b…
MB2	Mailbox Database 02	75.26 GB (80,807,526,400 b…	28.5 GB (30,605,312,000 by...
MB1	Mailbox Database 03	53.88 GB (57,856,294,912 b…	12.28 MB (12,877,824 bytes)
MB1	Mailbox Database 04	26.88 GB (28,865,265,664 b…	87.63 MB (91,881,472 bytes)

The base can then be packaged to reduce its size.

Database packaging can be done according to two scenarios.

The first is traditional for a single base. The database is unmounted and packaged using the eseutil /d utility. The process requires free space +10%*<размер исходной базы>. Service for the entire duration of work

The second one is suitable for DAG. A new base is being created on new storage facilities. Mailboxes are copied to the new database. This method also works for a single base. The overhead for free space is higher than in the first method: new storages must be created for all copies in the DAG. (The strategy may vary: to speed up copying, you can create one additional copy for new base, and after completing the process of transferring mailboxes, add the remaining copies to the storage spaces freed from the original database.)

If you do not have free storage, then in the case of a DAG, you will have to delete all additional copies of the database, unmount it, pack it, mount it and add additional copies again - obviously this can take much longer. Therefore, it is recommended to make databases no more than 100GB, and in the case of DAG, have free space for maneuver.

When implementing Exchange, an unpleasant situation arises - we seem to have fulfilled all the space requirements for Exchange, but it is inexorably decreasing... we begin to understand and understand that all kinds of logs are growing faster than we expected, so how to deal with them? The following describes methods for truncating/moving various logs, in general, everything that will help us solve the problem. Separately, I would like to note that all the information is in the technet technical library :) and here it is just selected for a specific task: to recall ways to solve problems with lack of space due to the growth of logs.

Transaction logs

Transaction log the most important element Exchange. Here's an example: When a message is sent, the transaction is first written to the log. Until the transaction is committed to the Exchange database, this data exists only in system memory and transaction logs. In the event of a crash, you lose the contents of memory and all you have left are transaction log entries. These logs are important for restoring a damaged database. The same goes for other transactions: messages received, items deleted, and messages moved to other folders. Accordingly, these logs grow very quickly, so how can they be reduced?

1. Backup

One of the functions performed when a full or incremental backup completes successfully is to truncate transaction log files that are no longer required to restore the database. Exchange 2013 only supports backups Exchange based on Volume Shadow Copy Service (VSS).

Great article on setup. Reserve copy using Windows Server Backup

2. Enable Circular Logging

When circular logging is enabled, the transaction log is cleared immediately after transactions are posted to the database.

With EAC Circular Logging turns on like this:

When Enhanced Storage Engine circular logging is enabled additional files no logs are created, instead overwritten if necessary current file magazine. However, in a continuous replication (DAG) environment, log files are required for log shipping and conversion. As a result, when you enable continuous replication circular logging, the current log file is not overwritten, and logs are created for the shipping and translation process closed files log, that is, log continuity is ensured, and logs are not deleted while they are needed for replication. Replication service Microsoft Exchange and bank service Microsoft data Exchange communicate using remote procedure calls (RPC) regarding which log files can be deleted.

3. Moving Transaction logs

Well, in the end, we can move the logs along with the database to another location/disk.

There is a great cmdlet for this Move-DatabasePath. Here's an example of transferring the MDB01 database and transaction logs to drive M to the appropriate directories:

Move-Databasepath “MDB01” –EdbFilepath “M:\DB\MDB01\database\mdb01.edb” –LogFolderpath “M:\DB\MDB01\logs\”

Queue Database

These are of course not logs, but if you need to free up space, moving this database can help you. Queue Database is a temporary storage of messages awaiting the next stage of processing. Each queue is a logical collection of messages that are processed by the transport server in a specific order. All queues are stored in one ESE database. Queues are hosted only on Mailbox servers or Edge Transport servers. The location of the queue database and its transaction logs is controlled by keys in the application XML configuration file %ExchangeInstallPath%Bin\EdgeTransport.exe.config.

All we can do with it is move it to another place. Enough comprehensive information about moving is in the technet library in the article Change the Location of the Queue Database

TransportLogs

Transport logs provide information about what is happening in the transport pipeline. Quite comprehensive information about disabling/enabling logging and moving them is in the technet library in the article Transport Logs.

The following transport logs are available in Microsoft Exchange Server 2013:

• Agent logs
• Connectivity logs
• Message tracking and delivery reports
• Pipeline tracing
• Protocol logs
• Routing table logs

Protocollogs via EAC: servers\servers\select server\transport logs\protocol log

For example, change the storage path Message Tracking via EAC: servers\servers\select server\transport logs\message tracking log.

I would like to separately note that you can only move to local folder. Problem with placement on network resource can be bypassed by using the mklink command and creating a link to a network resource. For example, create a link mklink /d “D:\HubReceiveSMTPLog” \\Server\HubReceiveSMTPLog , now you can use the Set-TransportService cmdlet and the –ReceiveProtocolLogPath “D:\HubReceiveSMTPLog” parameter to store ReceiveSMTP logs on a network resource. This method Suitable for other logs as well.

IISlogfiles

In the IIS log you will have information, for example, about connecting your iPad using the activesync protocol. The size of IIS logs, if not monitored, can be very large. How can I automatically delete them or move them to another disk?

1.Automatic deletion of logs

Run the following ps1 script daily through the scheduler (change the log storage path if necessary) and all your IIS logs older than 30 days will be deleted without requiring your attention.

set-location c:\inetpub\logs\LogFiles\W3SVC1\

foreach ($File in get-childitem) (

if ($File.LastWriteTime -lt (Get-Date).AddDays(-30)) (

del $File

You can run the ps1 script through scheduler as follows:

• Create a task in scheduler
• Create an action: start a program
• In the program/script field: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• In the add arguments(optional) field: -command “pathTOscript\name.ps1”

2.Moving logs to another location

• Open IIS Manager from Administrative Tools and select Default Web Site.

• Open Logging (double click on the Logging icon)
• Change the log storage location

• Save your changes. Next file the log will be written to a new storage location
• The same can be done with the power of powershell:

Import-Module WebAdministration

Set-ItemProperty ‘IIS:\Sites\Default Web Site’ -name logfile.directory “D:\IISLogs”

Logging folder

And finally the Logging folder, which by default is located in ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging. Many logs of various services are stored here, and can take up quite a large amount of space. Especially notable in terms of volume are the diagnostic and performance log files, which are located in the folder ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics’

A simple solution to this issue was found on the Internet; run it daily via scheduler and all logs from these folders older than 14 days will stop bothering you :)

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-14) | Remove-Item

P.S. I personally prefer to cut only diagnostics:

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-2) | Remove-Item

Microsoft Exchange Server, starting with version 2007, stores queue messages in an ESE format database - Mail.que located in the folder. After several years of use the database transport queues can grow to enormous sizes. In my case, after about 4 years of using Exchange Server 2010, it grew to 900MB, not much, of course, but there are cases on the Internet when its size reached 80-100 GB. After creating the database again, its size will be 8MB. A large database size can affect system performance and take up unnecessary disk space. I noticed this when one of my transport servers began to slow down terribly due to the antivirus. After re-creating the queue database, the problem disappeared.

Although Exchange performs automatic online defragmentation of this database, its size will never decrease. For example, if during a failure, your transport server received and stored 10 GB of mail in the queue, then later, when the mail leaves, the storage file size will remain 10 GB. Therefore, my recommendation is that if the database has grown more than 200MB, then it needs to be created again. This is done as follows.

1. It is necessary to install the service Microsoft Exchange Transport on pause. The service will stop accepting messages, but will “get rid of” all messages in the queues.

2. Run the cmdlet Get-Queue and make sure there are no messages left in the queues.

3. Stop the service Microsoft Exchange Transport.

4. Open the folder %ExchangeInstallPath%TransportRoles\data\Queue and make sure the file mail.que is in it.

5. After doing this, rename the directory %ExchangeInstallPath%TransportRoles\data\Queue V %ExchangeInstallPath%TransportRoles\data\Queue1.

6. Start the service Microsoft Exchange Transport, folder Queue, base mail.que and log files will be created. The size of the newly created database will be about 8.2 MB.

7. Make sure that the transport service is working properly and you can delete the folder Queue1.

Information about the location of the database file is located in the file %ExchangeInstallPath%Bin\EdgeTransport.exe.config, so if you want to move the base, then instead of step 5, change the path to the new file and follow step 6.

Related posts:

Did you like the post? Want new ones delivered straight to your inbox? Nothing could be easier, subscribe to the newsletter right now.

When defragmenting, data stored on hard drives computer are moved so that the files are split into fewer parts. Defragmentation helps speed up data access and retrieval. Defragmenting data on hard drives improves their performance and the efficiency of an organization's servers. In Exchange 2007/2010, defragmentation (more precisely, offline defragmentation) allows you to free up disk space. How? Everything is very simple, when you delete information from the database, it is not automatically compressed (empty areas remain), and accordingly the size of the database file does not decrease.

For example, if you delete/move user mailboxes with a total size of 5 GB from a mail database of 100 GB in size, the file size will remain unchanged at 100 GB. However, the released 5 GB of “free” space will be used by new elements in the future.
However, if you need to reduce the size of your mail database file in Exchange 2010 by removing unused pages, you can use one of the following techniques:
Create a new database, transfer all the boxes to it and delete the old database
Perform offline defragmentation of the current database
Each of these methods has its pros and cons. The first is good because the procedure is less risky, but also less convenient, because if you have 500 emails in your database. boxes, it will be very difficult to carry them by hand. The second method is not convenient because it requires quite a few resources (more on this we'll talk further) and in case of failures, it is not known what this can lead to, but it can cope with a large database relatively quickly. The choice is yours. I don’t think it’s worth describing the first method, everything is intuitive, so I’ll focus on describing the second method.
In order to use offline defragmentation, the Eseutil command is used. In Eseutil mode integral part The process of defragmentation is to create a new database that contains all the data that was in the original database, except that empty pages are discarded and indexes are rebuilt. After defragmentation is complete, the original database is deleted or stored in specified by the user place, and a new version gets the same name as the original database.
Before you start reducing the Exchange2007/2010 database using the Eseutil command, I suggest you consider the commands Exchange Management Console which may be useful for understanding the situation with databases and email accounts.

Using the following cmdlet, we can view the organization's available mail databases:
Get-MailboxDatabase

Now let's see what mailboxes are in a specific database (in this example, Mailbox Database 1)
Get-MailboxDatabase "Mailbox Database 1" | Get-Mailbox

In order to import statistics into CSV file at the end of the command we add
| Export-CSV C:\mailboxes.csv
A mailboxes.csv file is created in the root of drive C

Now let's move on to the commands for offline formatting, the first thing you need to do before reducing the database is to unmount it, for this you can run the command Dismount-Database DATABASE NAME, or run Exchange Management Console come in "Server Configuration- Mailbox" With right side there will be all Databases, select the one we need and click on it right click mouse and select Dismount Database.

ESEUTIL /d "G:\Exchange server\OTS\ots.edb"
Defragmented temporary file will be created in the root of drive C, it can take up to 110% of the original database - this must be taken into account.


ESEUTIL/d "G:\Exchange server\ROZN\rozn.edb" /t"G:\temp\tempdfg.edb"

The defragmented temporary file will be created on the G drive in temp folder, can take up to 110% of the original database (you must first create a file tempdfg.edb) then it will replace the existing database (in this example rozn.edb)

I hope the article was useful to you and you successfully reduced the size of your mail database.