Ok, generally speaking – in production environments you would not consider running a Storage Group with Circular logging enabled.

But, there are a few occasions where it is useful to do so – the most common of which is during large Migration Scenario’s.

You see when you move a mailbox from Exchange 2003 / or indeed between servers within Exchange 2007, depending on the amount of Mailboxes that you are moving; and indeed the amount of messages contained therein – lots of Database Transaction logs can be generated.
Now this is not a problem when you are moving just a few mailboxes, but if you are in a migration scenario and you are moving hundreds or thousands of mailboxes the potential to run out of disk space right “smack bang” in the middle of your migration process is a real possibility.
This happens because all mailbox messages are created within the target Database and then remove from the source database – the creation of and then the deletion of messages represent transactions – which therefore creates logs.

A way around this, and indeed if you Google the situation you will find that it is suggested by a number of people - is to switch the Storage Groups of your Target Databases into Circular logging (if you would like to find out more about CL I did a post on it HERE).

Now for non-clustered Mailbox Servers – this is a pretty simple task – but a question that I have seen doing the rounds recently is how can you accomplish this if the target databases storage group is based around CCR?
Well the good news is – its actually not that hard – but you need to consider the implications of turning on Circular Logging for CCR clusters.

In Exchange 2007, and more to the point CCR – Circular Logging is called CRCL (Continuous Replication Circular Logging) – which unlike normal CL is managed by the replication service (normal CL is managed by the Information Store Service).
As mentioned in my previous article (above) on Circular logging – no additional logs files are generated and the current log file is overwritten – however  in CRCL the current log is not overwritten and the closed logs are shipped over to the passive node – it is at this point the log is overwritten and the process begins again – this helps maintain the replication process (essentially logs are not deleted until it has been verified that there are no longer needed by the shipping process).

Now the above is merely the pre-cursor to the following issues with having your Storage Groups using CRCL:

• As you in essence end up with a singular transaction log you will not be able to to roll back beyond your last full backup
• You will not be able to perform any incremental backups

Therefore if you choose to enable CRCL for migration purposes – you should ensure the following:

• That BEFORE you enable it – you have a full backup of your Information Stores
• You should only have it enabled for your migration purposes – when you have finished you should re-enable the normal transaction log processes

Typically enabling Circular Logging is a very simple process – on a normal / non-CCR clustered Storage Group you would just use the command Set-StorageGroup -Identity -CircularLoggingEnabled $True – however with dealing with CCR storage groups – the following is the agreed “best practice” as recommended by Microsoft:

• Suspend the Storage Group’s Replication Process (Storage Group Copy)
• Set the Circular Logging Flag
• Dismount the Database within the Storage Group
• Mount the Database
• Resume the Storage Group Replication Process (Storage Group Copy)

After which you can begin the process of Mailbox Migration – upon the completion of which you need to disable the Circular Logging on the Storage Group and re-enable your backups.

Now the above – can be a bit of a pain – especially if you have multiple CCR Clusters, with Multiple Storage Groups and Databases therefore I would like to share a Powershell script that I wrote to assist me within my own migrations.

The script (which you can download from the link below) should be executed on a CCR Cluster within your Environment (it does not have to be the server which contains the storage that you are working on) – the reason for this is that the script makes use of commands that depend on Windows 2008 / Windows 2003 clustering services being installed.

SwitchCLogging-ForCCR.ps1

When you have download the script – it can either be executed via PowerGUI (recommended) or via the Exchange Management Shell (remember that you will need to have set the Execution level for PS script via Set-ExecutionPolicy RemoteSigned if you plan to run the script from the Management Shell).

Script Usage:

Open the Exchange Management Shell on the CCR Cluster where you downloaded the script to – type in the following command line (remember your Execution Policies):

\SwitchCLogging-ForCCR.ps1 – see below;

You will then be presented with the CCR Mailbox Servers which have been found in your environment – the ID numbering starts from 0 – type in the ID number of the CCR that you wish to work with and press – see below;

You will then be presented with the Storage Groups which are located on that server – again like the previous step – the groups are numbered from 0 – type in the corresponding number of the SG that you wish to enable CRCL for and then press – see below;

You will then be asked if you would like to:

1. Enable CRCL for the chosen SG
2. Disabled it for the Chose SG

These are numbered options 1 and 2 – chose the correct number and then press – see below;

The script will now go away and enabled CRCL logging on the CCR Storage Group – you will be prompted to confirm that you want to Suspend the Storage Group copy and indeed if you wish to Dismount the Database which is contained within that Storage Group – confirm both – see below;

You are then ready to begin your Mailbox Migrations. Once completed you should run the script again – only on that occasion choose option 2 to disable CRCL logging on the Storage Group.