Calendaring, the recurring meeting and disaster
End users are always looking for ways to make their life easier in their work life and there is one area where that is glaringly evident, Calendaring. Users will make recurring meetings without any end dates, end dates that are so far out in advance that they might as well not have an end date, throw in attachments and other things that on the outside don’t seem so bad,but given time and they will wreak havoc on your environment.
We have seen some cases in CSS where recurring meetings have brought an entire Exchange Organization to its knees and leaving everyone thinking, “Why would someone do that?”. It happens day in and day out and users are none the wiser because they have not been properly educated. And that is where the crux of the problem lies, user education. As Administrators, its not only our job to make sure that the environment runs smoothly, but also letting our user base know what is a best practice and what isn’t.
When it comes to calendaring there is some great Office documentation that is out there already, however, in an effort to point customers to documentation on what would be best practices for recurring meetings, there were some things that were missing. As a Support Engineer, its easy for me to tell you what’s wrong, but it goes a long way if I have something that says it as well.
One of the things that we see in CSS is when recurring meetings are modified. The first couple of times are no problem, but there comes a time when a simple change turns into a critical situation. Recurring meetings are special meetings and their history is very important, so it needs to be retained. So, when we make a change to that meeting, the original gets copied to the modification. We make another change and now the 1st modification and the original get copied to the 2nd modified meeting. Make a 3rd change and we start the process over again. At some point, there are too many copies attached to the message, so we go and clean it up and make it a nice neat embedded attachment.
Each time that meeting needs to be processed, because its been modified, store will take that meeting and expand out all the attachments and go through all the attendees before the modifications can be sent. Guess what all that processing does to the Exchange server? Uses up all its resources causing your users to complain of poor performance.
Here are some of the ways that I have seen this manifested:
1. Excessive transaction log creation. Using the steps from this blog we can take a look into the logs and get a feel for what is going on. Its not a perfect world, but we really don’t have anything better to view these with. What we are looking for is the last few lines and what they are telling us. Look for time zone info or anything that looks like a calendar appointment. The last case I worked with this, the bottom four lines were the same 2 individuals. In 200 log files those 2 names were mentioned over 4 million times! That was only the bottom 4 lines, there were many many more listings for the users. When we went to open the calendar item on one of the users mailbox, their Outlook locked up and became unusable. We had to go into the mailbox with MFCMapi to delete calendar item. We had to do this on the other calendars where this meeting showed up.
2. ESE 623 events “The version store for instance…has reached its maximum size of…It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size.” These events tell us that there is a long running transaction that is causing the store to stop responding to requests. These events are not exclusive to modified meetings. The only way we can tell is by getting 3 consecutive store dumps about 3 minutes apart. This will show us what we are waiting. In one case I worked with this, the EE that was reading the dump came over and asked me why the user was sending out a meeting request to 500 users. I started looking over their findings and started to see the same names over and over again. That is when we put 2 and 2 together. We got the originator on the phone and asked them about this meeting. The meeting only had a handful of users, but we were processing the same attendees over and over again and there were definitely attachments. That was when the user told me that they modify the meeting on a weekly basis.
Learning what user behavior went a long way in solving these cases. My first questions was why are we modifying a recurring meeting so many times? Doesn’t that defeat the purpose? I think of a recurring meeting that happens for a specific period of time and during that time, it never changes, but that is me. Some of the answers to these questions make sense, but are what leads us to our problem.
“I update the meeting agenda on a weekly basis. Its just easier to do it here”
“I need to send out the weekly sales statistics so that everyone is prepared for the meeting”
“This is just a place holder for that block of time, the meeting place changes each week”
See, it makes their life easier. They just don’t understand the consequences of their actions. Here are some good best practices when it comes to recurring meetings:
1. A recurring meeting should have an end date. That end date should be no further out then a year to two years. Think about it, do you know where you are going to be in a year? Will you still have the same job, the same company, the same boss even? Setting up a never ending recurring meeting with your boss doesn’t ensure that you will have a job next year.
2. If you need to add an agenda to your meeting, send it in a separate email. Simply copy and paste the attendee list into a new email and send that.
3. If you need to send an attachment, send a link to where that data can be found. Make sure it is a file share that everyone can access and this way any changes to past and present documents are located in the same place. Now everyone can see the changes and we do not fill a mailbox with documents
4. Force the users to set end dates on their meetings. This doesn’t prevent them from setting end dates that are 10-15-20 years out, but it makes them stop and think about it. Hopefully most of the users will follow your recommendation (1-2 years). You can set the following registry key DisableRecurNoEnd.
For Outlook 2003: https://support.microsoft.com/kb/952144
For Outlook 2007: https://support.microsoft.com/kb/955449
For other great office tips, see the following link:
Outlook meeting requests: Essential do’s and don’ts:
https://office.microsoft.com/en-us/help/HA011276781033.aspx
~JC