Exchange 2010 Calendar Repair (Part 2)

If you would like to read the first part in this article series please go to Exchange 2010 Calendar Repair (Part 1).

Introduction

In part one of this article series we started to look at the configuration of the Calendar Repair Assistant in Exchange 2010. Let’s get straight down to business in part two and look at the logging features, followed by an example of the Calendar Repair Assistant in action.

Calendar Repair Assistant Logging

Since the Calendar Repair Assistant is making changes to users’ mailboxes, it is good to know that full logging capabilities are provided with the feature and each time a user’s calendar is repaired, the log file is written to. Calendar repair logging is enabled by default on each mailbox server.

In part one of this article, it was seen in Figure 1 that there are a total eight parameters relating to the control of the Calendar Repair Assistant, five of which are related to the calendar repair log. These five parameters are discussed below. After each parameter has been discussed, we’ll look at the contents of an actual log to see the type of information presented to us.

  • CalendarRepairLogEnabled – By default, the Calendar Repair Assistant has logging enabled and therefore this parameter is set to true. To disable the Calendar Repair Assistant logging on any particular mailbox server, simply change this parameter value to false. For example, to disable Calendar Repair Assistant logging on the server called EXCH, the following cmdlet can be used: Set-MailboxServer –Identity EXCH –CalendarRepairLogEnabled $false
  • CalendarRepairLogSubjectLoggingEnabled – Like the calendar repair log itself, the calendar repair log has subject logging enabled by default. Having the subject of calendar appointments written to a log file may not be required in some security-sensitive environments and therefore it is possible to prevent this from happening in much the same way as is possible with message tracking in Exchange 2010.  To disable the Calendar Repair Assistant subject logging on the server called EXCH, the following cmdlet can be used: Set-MailboxServer –Identity EXCH –CalendarRepairLogSubjectLoggingEnabled $false
  • CalendarRepairLogPath – By default, the Calendar Repair Assistant log files will be found in the \Program Files\Microsoft\Exchange Server\V14\Logging\Calendar Repair Assistant folder as can be seen from Figure 4.


Figure 4: Default Log File Location for the Calendar Repair Assistant

If it becomes a requirement to move these log files to a different location, then this can be easily achieved by using the Set-MailboxServer cmdlet with the CalendarRepairLogPath parameter. For example, to move the log files to the folder C:\CRA, the following cmdlet can be used:

Set-MailboxServer –Identity EXCH –CalendarRepairLogPath C:\CRA

If the folder C:\CRA does not already exist, the cmdlet will still execute successfully. However, note that the C:\CRA folder will not be created until the next time the Calendar Repair Assistant runs. Note that any old log files will remain in the previous log file location; only new log files will be housed in the new location.

  • CalendarRepairLogFileAgeLimit – Calendar repair log files are not removed by default, meaning that these log files will continue to accumulate until either a configuration change is made or the log files are deleted manually. The default value for this parameter is 00:00:00 which equates to zero hours, minutes and seconds. If the Calendar Repair Assistant has been configured to look 30 days into the future when repairing calendar items, it could be a requirement to remove Calendar Repair Assistant log files older than 30 days. To do this, the following cmdlet can be used: Set-MailboxServer –Identity EXCH –CalendarRepairLogFileAgeLimit 30
    Once this has been set, note that the subsequent value of this parameter will be displayed as 30.00:00:00 as opposed to the default value of 00:00:00. In other words, the value of 30 days is now represented in addition to the hours, days and minutes.
  • CalendarRepairLogDirectorySizeLimit – Finally, this parameter controls the size of the directory containing the log files. As you will have seen from Figure 2 in part one of this article series, this parameter has a value of ‘unlimited’ which means that there is no directory size configured by default. Although disk space is plentiful and cheap these days, be aware that Calendar Repair Assistant log files will continue to grow until such times as the age limit and directory size limit parameters are configured accordingly. To ensure that there are never more than, say, 1GB of Calendar Repair Assistant log files, the following cmdlet can be used: Set-MailboxServer –Identity EXCH –CalendarRepairLogDirectorySizeLimit 1GB

Looking back at Figure 4, it can be seen that the Calendar Repair Assistant log files have a specific name format. For example, one of the log files is called CRA2010053019-1.neil. This file name can be broken down as follows:

  • CRA – the prefix “CRA” to show that this is a Calendar Repair Assistant log file.
  • 2010 – the year in four digit format
  • 05 – the month in two digit format. Therefore, this log file is from May.
  • 30 – the day in two digit format. This log file is therefore the 30th day of the month.
  • 19 – the hour of the day in two digit 24-hour format. Therefore, this log file is from 7pm.
  • -1 – the generation number of the log file, which is increased every time the same mailbox is processed within that hour.
  • neil – the alias of the mailbox that was processed by the Calendar Repair Assistant.

The Calendar Repair Assistant in Action

Now that you’ve seen how to control the Calendar Repair Assistant and its associated logging, let’s now take a look at the entire process and discover what the users see as well as discover the contents of a log file generated as the result of a fixed calendar. In order to do this in a lab environment, we need to first generate a problem. To do that, let’s take the scenario where the user Rob requests an important meeting with the user Neil. Although Neil accepts the meeting request, he subsequently deletes the meeting request from his calendar and, worse still, doesn’t send any update to Rob informing him of this fact. In order to prevent Rob from turning up at the meeting on his own, the Calendar Repair Assistant has the ability to fix Neil’s calendar by re-adding the deleted meeting request to his calendar.

So, after deleting the meeting request from Neil’s calendar and not sending any update to Rob, the Calendar Repair Assistant runs against all the mailboxes on the server that hosts Rob and Neil’s mailboxes. Let’s now look at the Calendar Repair Assistant log files generated as a result of this issue. First, let’s open the log file for Neil’s mailbox, which in this case is called CRA2010053021-1.neil. You can see the contents of this log file in Figure 5.


Figure 5: Empty Calendar Repair Assistant Log File

As you can see from Figure 5, there isn’t any relevant detail to the problem in this particular log file. Why is this? The answer to this question is because the details of the repaired meeting item belong in the log file associated with the meeting organizer, namely Rob. The required details can therefore be found in the log file for Rob’s mailbox, which in this case is called CRA2010053021-1.rob. You can see the contents of this log file in Figure 6.


Figure 6: Detailed Calendar Repair Assistant Log File

You can see from the log file shown in Figure 6 that there are four consistency checks performed, namely CanValidateOwnerCheck, ValidateStoreObjectCheck, UserExistsCheck and MeetingExistenceCheck. It’s the MeetingExistenceCheck consistency check that has failed, which, according to the description “checks whether the item can be found in the owner’s calendar or not”. As a result, the inconsistency is reported as “Could not find the matching meeting in attendee’s calendar”.

Now that the Calendar Repair Assistant has successfully run against both Rob and Neil’s mailbox, let’s see what the impact has been to Neil, who mistakenly deleted the calendar item in the first place. If we look into Neil’s calendar we will see that the meeting request has been re-created. Additionally, if we now open up the meeting item in Outlook, it will look similar to the one shown in Figure 7.


Figure 7: Repaired Calendar Item

The additional meeting fix information is highlighted within the red box. You can see from Figure 7 that a clear description of the calendar item issue is given together with advice on what Neil needs to do to ensure that the calendar item is not re-created automatically again. In this particular example, the meeting should be declined so that Rob receives a decline response, rather than Neil just deleting the meeting and not sending a decline response.

Summary

That completes both parts of this two-part article series. Hopefully after reading this article you have come to realize that the Calendar Repair Assistant is a valuable tool for your users to make use of.

If you would like to read the first part in this article series please go to Exchange 2010 Calendar Repair (Part 1).

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top