IT tutorials
 
Technology
 

Microsoft Exchange Server 2013 : How the Managed Folder Assistant implements retention policies (part 2) - Retention date calculation

11/21/2014 2:56:34 AM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

Retention date calculation

Date calculation is a very important part of the work the MFA does when it processes items. The MFA has to understand the date that should be used to calculate the age of the item (when the item first appears in the mailbox) and either the date when the item will expire or the date when the MFA has to take the action the retention policy requires (deleting the item or moving it into the archive).

Given the nature of email, most items enter a mailbox when they are delivered in the Inbox or are sent and stored in Sent Items. Items often stay in these folders for much of their lifetime and, if they do stay, will probably come under the control of either a folder tag (if defined for the folder) or a default tag (that applies to untagged items in the mailbox). The exception, of course, occurs when a user explicitly applies a personal tag to an item in the Inbox or Sent Items.

When the MFA runs, it examines items in the mailbox and determines what processing is required. Assume that an Inbox item exists that was delivered on 1 April 2013 and that a folder tag that requires items to be deleted and allow recovery after 30 days is applied to the Inbox. MFA stamps this item with a start date of 1 April 2013 by updating the PR_START_DATE_ETC property. It then calculates the expiration date by adding 30 days to the start date; 1 May 2013 is the result. This date is then stamped on the item by updating the PR_RETENTION_DATE property. On or after 1 May 2013, the MFA returns to the item and discovers that its retention period has expired. (If you view the item by using Outlook before the MFA returns, you’ll see the item marked as Expired.) When the MFA processes an expired item, it takes the retention action defined in the tag. In this case, it moves the item into the Recoverable Items folder, where it will remain until the retention period for the mailbox expires, at which time the MFA will remove the item permanently from the database.

This is the simplest kind of processing the MFA is called on to perform, but it happens for a large percentage of items because many users leave messages in the Inbox and Sent Items folders. People who let items accumulate in these folders are often called pilers because they create piles of messages and then rely on client search facilities to locate specific items when required.

Broadly speaking, the other kind of user behavior is represented by the filers, or people who move items from the Inbox and Sent Items into more appropriate folders in which the items form collections that represent important categories of work (or play) as viewed by the user. Or indeed the user attempts to keep the Inbox and other folders under some form of control by deleting unwanted items on a regular basis.

Assume that your user receives a message, reads it, and then comes back to the message a week or so later when its content is no longer required, perhaps because he has acted on a request that was contained in the message. Because the item has been in the mailbox for more than a day, the MFA should have already processed it and stamped its properties with a start and an end date for retention purposes. The user now deletes the message as part of his cleanup effort, and the client moves the item into the Deleted Items folder.

You now have a different retention context because the item has moved out of the sphere of control exerted by the folder tag placed on the Inbox. Retention policies usually include a folder tag to control the Deleted Items folder and, if so, the MFA now must apply the instructions contained in that tag. Otherwise, the MFA will apply the instructions contained in the default tag.

Assume that the folder tag assigned to Deleted Items requires items to be removed from this folder (using Delete And Allow Recovery) after seven days. The MFA examines the item and discovers that its start date is 1 April 2013 and that it should now be removed on 8 April 2013. If the user moved the item into Deleted Items before 8 April 2013, the item is kept until 8 April 2013 and then removed. However, if the MFA processes the items on 8 April 2013 or after, it knows that the expiration date for the item is already past and therefore immediately executes the retention action and moves the item into the Recoverable Items folder, where it will remain until the deleted items retention period specified for the database elapses. The default deleted items retention period for newly created databases on an Exchange 2013 server is 60 days. However, this period is calculated based on the item’s deletion date rather than its creation date, so it will be held for another 60 days to allow the user to recover the item during this period. (For example, if an item is deleted on 2 April 2013, the MFA will purge it on 1 June 2013.) Some companies use an extended deleted items retention period of up to a year to ensure that users can recover deleted items themselves without involving administrators, a useful practice that costs a little more disk space for databases while releasing administrators from the tedium of having to restore databases to recover a now-important item deleted some months in the past.

Calendar and task items pose some particular difficulties for the MFA when it comes to calculating their expiration date, which is why Microsoft took some time to find the best way for the MFA to proceed and implemented only the processing from Exchange 2010 SP2 RU4. Calendar items are either nonrecurring or recurring and will be either in the Calendar folder or in Deleted Items. It is possible that calendar items might turn up in other folders, but this happens very rarely in practice; if it does, the MFA deals with these items as if they are in the Calendar folder. The following rules are observed:

  • Nonrecurring items in the Calendar folder expire according to the end date of the appointment or meeting. For example, if you create a calendar entry for a trip that lasts from 1 June 2013 to 10 June 2013 and the folder tag for the Calendar folder specifies a retention period of two years, the item will expire on 10 June 2015.

  • Recurring items in the Calendar folder expire according to the end date of their last occurrence. For example, if a series of meetings is scheduled from 1 May 2013 to 1 September 2013, the item expires on 1 September 2015. If a recurring event has no end date, it will never expire.

  • Calendar items in the Deleted Items folder expire based on their message-received date. If this property is not populated (for instance, for an item the user created in his own calendar and never sent to anyone else), the MFA bases its decision on the message-creation date. If neither of these dates is populated, the MFA ignores the item.

Task items receive similar care when the MFA calculates their expiration. The following rules are used:

  • Nonrecurring (simple one-off) tasks stored in any folder other than Deleted Items expire based on the message-received date. If this property does not exist, the MFA uses the message-creation date.

  • Recurring tasks expire based on the date of their last occurrence. A recurring task with no end date will never expire.

  • A regenerating task (a special form of recurring task that generates a specified time after the preceding instance of the task is completed; see Figure 3) never expires. Only the most dedicated of users who understand how to make maximum use of tasks create these items!

    This screen shot is taken from Outlook 2013 and shows how an automatically regenerating task is created. In this case, the Regenerate New Task button is marked to indicate to Outlook that a new task should be auto-generated. The selected interval is 1 week, so the completion date for the new task is one week after the current task is completed.

    Figure 11-21. Specifying a regenerating task

  • Tasks that have been placed in the Deleted Items folder expire based on their message-received date. If this property does not exist, the MFA uses the message-creation date. If neither date is available, the task never expires.

As explained in the previous section, you can use MFCMAPI to validate the dates the MFA uses to calculate item expiration.

 
Others
 
- Microsoft Exchange Server 2013 : How the Managed Folder Assistant implements retention policies (part 1) - Behind the scenes with the MFA
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups (part 4) - Assigning New Visitor, Member, and Owner Groups at Site Creation
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups (part 3) - Creating a New Group, Deleting a Group
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups (part 2) - Removing Users from a Group, Group Settings and Permissions
- Sharepoint 2013 : Security and Policy - SharePoint Security Groups - Adding Users to a Group
- Microsoft Exchange Server 2013 : Messaging records management (part 7) - Setting a retention policy on a folder
- Microsoft Exchange Server 2013 : Messaging records management (part 6) - Customizing retention policies for specific mailboxes, User interaction with retention policies
- Microsoft Exchange Server 2013 : Messaging records management (part 5) - Applying a retention policy to mailboxes
- Microsoft Exchange Server 2013 : Messaging records management (part 4) - Creating a retention policy
- Microsoft Exchange Server 2013 : Messaging records management (part 3) - Naming retention tags, Creating retention tags
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.