Scott Feltmann's Blog

I was at a client site yesterday in the process of moving them off a NetApp Storage array and onto EMC Storage.  My colleague and I ran into a very interesting problem and have no idea why it was happening.  If anyone has any ideas please, do share.

The setup was two Windows 2008 Servers with Exchange 2007 CCR split between two datacenters.  The servers were using Snap Manager for Exchange and Snap Manager.   There were four LUNs from the NetApp presented, three for databasae and one for the logs.  The LUNs were attached via iSCSI. 

Since the Exchange CCR environment was running in the HQ Datacenter we started by getting the EMC agents installon the the Server in the DR Datacenter.  The iSCSI LUNs from the NetApp were presented via Drive letters, there were four, three for the database and one for the logs.  If you’re not familar with deploying EMC apps the first app to deploy is the EMC NaviHostAgent.  When I installed the agent the server requested for a reboot.  This is where things got really funky.  When the server came back from a reboot the iSCSI disk drives from the NetApp were gone!  No idea why.  We scratched our heads and couldn’t figure out what happened.  According to the NetApp management console the LUNs were presented.  When we tried to remap the LUNs via Snap Manager it would state that the volume was already mapped to a drive on the server, but the Server could not see them!  This was odd.  We backed out the EMC NaviHostAgent and the LUNs reappeared but the drives were off line.  I brought the drives back on line and everything worked again.

We then started by reinstalling the EMC NaviHostAgent, no reboot was required this time and installed the EMCPowerPath application.  When we came back from a reboot the drives from the NetApp were off line again, I brought them back on line and had both the EMC and the NetApp storage provisioned.  Great, this is nice.  We presented the EMC LUNs as mount points and started up replication again from the HQ Exchange Server.  Once replication was caught up moved the cluster to the DR server to begin the same process on the HQ server thinking we had a fluke.

Well, the exact same thing happened!  When we installed NaviHostAgent no reboot was required.  We then installed PowerPath, Had to reboot the server and the NetApp LUNs vanished!  WTF right?  Not again!  We did the same procedure I mentioned above, removed PowerPath, removed NaviHostAgent, rebooted the Server in HQ.  When it came back the NetApp LUNs were gone!  No drive letters, no detection.  Checked the iSCSI Initator configuration, and it was perfect, it was seeing the iSCSI targets for both the NetApp and the EMC.  From the NetApps perspective the LUNs were provisioned.  What in Windows 2008 was preventing the LUNs from being seen?  I checked the Network settings via IPCONFIG and there was a “Local Area Connection 9″ that was there along with a Prod network and a iSCSI network.  Looking at the network configuration only two NICs were active for the machine.  No idea where the third NIC was coming from and by this time I was too tired to try to figure it out.  Anyone out there have thoughts on that one? 

Anyway, after troubleshooting for about 5 hours between the two servers I proposed a Plan B.  Since we had the NetApp storage (Thank God) and the EMC storage on the DR server I could create new Storage Groups and Databases on the DR server to the new EMC LUNs.  Create new EMC LUNs on the HQ Exchange Server to reflect what was in DR and let CCR take care of the rest.  Once the Storage Group and Databases were created I enabled replication only for the EMC Storage Groups (since the NetApp was off line on the HQ Server I couldn’t re-enable CCR) and started moving mailboxes.  This worked fine, disaster averted. 

I was glad Plan B worked, but more complexing is why did the NetApp LUNs disappear?  Anyone have an idea what may have happened with it?  Again this was a Windows 2008 Server with Exchange 2007.  The iSCSI network was correct, the NetApp was presenting the LUNs, when going into snap manager the LUNs said they were mapped.  I tried to do a rescan of disks, nothing.  Tried to take away the LUN and remap the LUN via NetApp management console and nothing worked.  The Windows Firewall was turned off, disabled AV Software, nothing worked.  Nothing would bring those LUNs back to the Windows 2008 server.  Has anyone seen anything like this?  Anyone have an idea on what happened?  Please do share!

Thanks,

The Microsoft Exchange Team has announced the release of Update Rollup 2 for Exchange Server 2010.  For the announcement go here: http://msexchangeteam.com/archive/2010/03/05/454155.aspx

Some key fixes are: 

For more information on the Hotfix you can go to the page at http://support.microsoft.com/?kbid=979611.

Enjoy!

I recently performed an Exchange 2007 upgrade for a client who was moving from Exchange 2003.  As part of their compliance with some regulations they are required to journal the activity of certain mailboxes within their organization.  Journaling in this situation was enabled on the database level so all users in the database will have all emails sent and received forwarded to an external 3^rd party mail server.  This was done through a send connector to the 3^rd party’s domain. 

The problem the client was experiencing in Exchange 2007 was that all outbound emails originating internally were being sent to the external journaling provider however, all inbound emails were not being forwarded to the journaling provider. 

The client contacted the Journaling provider and from a conversation it was determined that when an inbound message arrived to the Exchange Mailbox Server, it would be forwarded to the journaling provider from the original sender, the original sender being someone from outside the organization.  This immediately put up a red flag in my head.  I started to think, Exchange receives an email to send to a 3^rd party, from a person outside of this trusted organization.   Exchange was refusing to send the message!  So, the thought came into play, how to configure this thing to allow it to relay to the 3^rd party email server.  Anyone?  Anyone?  Ok, the solution was actually quite simple and once I understood what was happening it was easy to figure out.  I simply setup an Internal Relay!  Yup, that’s it.  The Internal Relay will allow Exchange 2007 to receive emails for a specific domain, query Active Directory for the mailbox and deliver the mail for that domain if it is found internally.  If the mailbox is not found internally Exchange will then Relay the email for the 3^rd party mailbox server specified in the Send connector which was already configured above!  Walla, problem solved!

For more information on what an Internal Relay Domain is click here.

Have a great day!

The MS Exchange Team has a nice post (http://msexchangeteam.com/archive/2010/02/22/454051.aspx) on their site explaining the history of Single Instance Storage (SIS) and where it went!

Reading the article I couldn’t help think that many clients are still concerned about space on their SANs and fear the idea of placing anything on local disk.  The idea in the article is placing your production mailboxes on Cheap Disk.  The only time a client or anyone should consider this is where you are using Database Availability Groups and have at least three servers in the DAG.  This will allow you to go backupless but also have all bases covered in your environment surrounding performance and recoverability. 

My only other beef though is Archiving.  The biggest question I get from clients is, “can I have my production mailboxes on one database and put the archived mail on cheap disk?”  Currently in Exchange 2010 an archived mailbox is stored on the exact same database as the users’ production mailbox. I have heard rumors that this is being looked into for future releases but nothing concrete.   What this means is that using SAN space which is typically RAID 10 or RAID 5 requires expensive disk for the production mailbox, which by default (if leveraged) archiving is also placed on expensive disk.   Explaining to clients that they can use local disk, have HA, but need at least three mailbox servers isn’t easy.  Not to mention that if you want multiple CAS in your environment with WNLB you need separate machines.  This is due to WNLB and MS Clustering cannot run on the same server.

Otherwise, given the way Exchange is deployed these days it is an enterprise solution.  There are times where departments will be included in a single database and other times where users are stored based on their last names.  I do love what they have done with Exchange 2007 and then what they have also done with Exchange 2010.  I just felt that I had to put in my 2 cents on the SIS discussion since I felt the post was a bit misleading.  While the applications are true, we have to consider real life usage and still address client concerns. 

So, an interesting call came to me last week regarding a client who was having some issues with Voicemails from Cisco Unity (I believe it was 7.0) transporting voice mails to Exchange.  Their Exchange 2007 instance was moved from W2K8 to W2K8 R2 due to an issue they had with the W2K8 server.  Not realizing that Unity (or Exchange) was not compatible with Windows 2008 R2 they started to have problems.

Basically the problem they were having was when a voice mail was left for a user, it was not being delivered to the user.  Voicemails would pile up on the Unity server.  The recommendation was to reinstall Exchange 2007 on a W2K8 server WITHOUT R2.  The client decided to take a path to resolve the issue but I am not certain what they did.

On another note Exchange 2007 is not supported on Windows 2008 R2 yet, however I have heard rumors that if you install Exchange 2007 SP2 on Windows 2008 R2 if you run the install in Windows Vista Compatibility mode the install will work.  When will Exchange 2007 officially support Windows 2008 R2?  Well, Exchange 2007 SP3 will allow support for Windows 2008 R2.   Exchange 2007 SP3 should be released some time this year (2010). 

Moral of the story, do not put Exchange 2007 on W2K8 R2, and do not use Unity with Windows 2008 R2. 

I also understand that Cisco Unity does not support Windows 2008 R2 domain controllers.  Exchange 2007 SP2 will support Windows 2008 R2 domain controllers.  So, take your pick, but you can’t use Unity to query W2K8 R2 DCs. 

I hope this helps some people out there!  Thanks for visiting.

So, yesterday I was out at a client site to review their Exchange 2007 deployment.  In my previous post I talked about how the Subnet the Exchange 2007 servers were in did not have the IP subnet associated with an AD site.  Well, I did come across another interesting issue that was a bit more troublesome.

The client is deploying an Exchange 2007 SP2 environment leveraging a Single Copy Cluster (SCC) and two CAS/HUB servers. 

While testing the failure over process of the SCC we came to the point where using the manage clustered mailbox command in the Exchange Management Console or the Exchange Management Shell would not work.  We were receiving an error message that the Database failed to initialize.  The error log was huge, errors on creating the D drive (where the database was located), errors opening the database, mounting the database, it just wasn’t working!

I then suggested to go back and use the MS Failover Cluster Management tool.  We took a node off line, and failover worked.  How Odd!  This appeared to be an issue with permissions on the servers.  Something was prevent Exchange from performing the failover.  We then tried another failover vial the managed clustered mailbox command and I noticed that the shared disk drives were attempting to fail over to the passive node but they couldn’t!

We then proceeded to check permissions into the Windows Cluster and Exchange Cluster, adjusted a few settings but nothing worked.  Well, I then asked, is there a Group Policy blocking any time of assignment to “Manage auditing and security log”, he said no.  We checked Group Policy to be certain and there was nothing configured.  I then asked him to take a look at the local security policy on the system, sure enough, only the Administrators were in the group Manage auditing and security log.  Once adding the Exchange Servers to this group on each system the Single Copy Cluster was able to fail over with no problems! 

I am not certain as to why the Exchange Servers did not get added to the local security policy, there was nothing in group policy or anything on the system to over write this to my knowledge.  But none the less, it is very important to make sure the Exchange Servers do have access to the security setting.

Either way it was quite an interesting day at my client site, a few more issues came up but nothing as notable as the ones discussed here. 

Hope you have a great day!

So, I was out at a client site yesterday to review the work they have completed so far on their Exchange 2007 deployment.  There were two issues that we came across that were unique that I thought I would mention to the population out there.  Hopefully this information will be able to help someone.

The first problem I noticed was the error message that stated Exchange was not part of an active directory site.  This caused me to think, why would an error come up like this.  My first instinct was to do a Gpresult /r (Windows 2008) which listed out all the information about the computer and user.  The Computer said it belonged to the site Default-First-Site-Name.  Ok, so the server was recognizing that it was a member of the AD Site, but why was exchange balking at the issue?  Well, I asked the IT Admin to open up Active Directory Sites and Services and took a look in there.  Looking over AD Sites and Services I noted the client had only one site configured, Default-First-Site-Name.  Thinking a little bit more about the situation I asked to see what subnets were configured for the site.  Well, upon review the site only had two subnets assigned to it.  Neither one of these Subnets included the subnet Exchange 2007 was in.   Talking to the Admin about this I learned that they had the same issue on the Hub Transport Servers and had to manually configure AD using ADSIEdit to insert the proper site name for the server to use!  Eww, not sure how this will impact their environment in the long run but when installing Exchange this should all be done automatically.  So, I had the admin add the Subnet to the AD Sites and Services and rebooted the mailbox servers, error gone, problem solved! 

The moral of the story above?  Make sure that you have your AD Sites and Services properly configured prior to deploying Exchange.  Oh yea, don’t forget, you need to have a domain Controller in the same AD Site as Exchange.  How the client ever got Exchange working is beyond me.  The workstation was seeing the AD Site but Exchange was not, hence the error. 

In my previous post I talked about the Exchange 2010 Archiving and Retention Tags.  This post continues on from that previous post.

In order to enable Archiving in Exchange 2010 the exchange administrator needs to be familiar with Retention Polices and Retention Tags.  My previous post talked about Retention Tags and how to create a retention tag focused on archiving data in the entire mailbox.  Once this Retention Tag has been created it will need to be linked to a Retention Policy.  Once the Retention Policy has been created it will need to be linked to a user or users who have archiving enabled on their account.  First let’s talk more about Retention Policies.

Retention Policies are use retention tags to apply to mailboxes.  You can have one or multiple retention tags applied to a Retention Policy which are then assigned to a user or group of users.  The retention policy can have the following retention tags:

• One or more RPTs for supported default folders
• One DPT of type All (this is typically the best option for archiving)
• Any number of personal tags

It should be noted that you cannot have more than one RPT configured for the same folder applied to a Retention policy.  This means that if you have one RPT called users configured for the inbox, and another RPT called Finance configured for the inbox, that these to RPTs cannot be assigned to the same Retention Policy. 

In order to create a Retention Policy the Admin will need to use the EMS.  The EMC is not supported for creating retention policies.  To create a retention policy we will use the New-RetentionPolicy command.  This command is pretty straight forward.  In order to create a new policy and link it to our RPT we created in the previous post we will simply type:

New-RetentionPolicy “Users-RP” –RetentionPolicyTagLinks “Users-RPT”

This command will give us a new Retention Policy called “Users-RP” and link it to our DPT we created in the previous post called “Users-RPT”.  We created the DPT in order to create a default policy to all folders capable of being archived in the user’s mailbox. 

Say for example we only want to create the retention policy but not assign any tags to it.  No Problem!  We can simply add retention policy tags at a later time.  (Note: It is not recommended to have blank retention policies in your exchange environment.  If you have an empty one it is suggested you link your RPTs to it sooner rather than later.)  Pretend in the example above we did not specify the –RetentionPolicyTagLinks command and just left the command New-RetentionPolicy “Users-RP”.  In order to add a RPT to a Retention policy type the following:

Set-RetentionPolicy –Identity “Users-RP” –RetentionPolicyTagLinks “Users-RPT”

If you like you can add additional RPT but separating them with a comma, i.e. –RetentionPolicyTagLinks “Users-RPT”, “More-RPTs”, “HR-RPT”     or whatever you would like to call them….

Once we have our Retention Policy we now must enable archiving for our users.  Locate the users you wish to enable for archiving using the EMC under Recipient Configuration and Mailbox, highlight their names and from the action menu select Enable Archive.  You will get prompted if you would like to continue and simply click Yes.  The user will now have an archive mailbox.  You will notice this because the icon will appear differently in the EMC. 

Once the user has been configured for archiving we will need to apply our Retention Policy we created above to the archive mailbox.  We can apply that retention policy by performing the following command:

Set-Mailbox “Username” –RetentionPolicy “Users-RP”

This command will then apply the Retention Policy we created above with the RPT we created in the previous post.  The user’s content of their mailbox will then archive anything older than 30 days.

Keep in mind that you can create multiple Retention Policies and Retention Tags for different business units in your organization.  Some may want to have a retention policy of 1 month (30 days), 3 months (90 days), six months (180 days), or a year (365 days), or ten years (3653 days).

So, once archiving is enabled we will now see a new archiving mailbox in our folder list.

Before Archiving:

After Archiving:

Now, you may be asking yourself “What!  I enabled archiving for the users but there is no content in the archive mailbox!”  Well, no worries friend!  This is because the Managed Folder Assistant has not run its scheduled maintenance.  By default this process will run between 1am – 4am daily.  This process will need to run prior to any items being archived into the archive mailbox.  The good news is this process can be ran manually.  Open your EMS and type “Start-ManagedFolderAssistant”.  Since this process runs on the Exchange Server, and the production mailbox and the archive mailbox reside on Exchange 2010 the users do not need to be logged in for the archiving to occur, unlike the old Auto Archive feature in Outlook!

So, now we have a mailbox folder list like below.  Note the additional folders created also appear in the Archive!

Once Archiving is in place we have to consider the Archiving warning quota and archive quota.  By default the archive warning quota and archive quota are set to Unlimited.  The trick to configuring these quotes is that we need to meet the user’s requirements.  Some users may need very little space for an archive while others need a great deal of space.  If you choose to leave the quota’s as unlimited then I would keep a close eye on your storage usage for the database because it can grow rather quickly as some users will keep everything.  If you do set the archive quota, once it is reached, messages will no longer be moved into the archive and a warning message will be sent to the mailbox user.  Either way, it can be difficult to determine the proper sizing for the archive.  Each user or department will likely have different requirements. 

Either way, to configure the warning and archive quota’s you should use the EMS.  The EMC can be used to configure the archive warning quota but not the archive quota.

To configure the archive quota and warning quota perform the following:

Set-Mailbox –Identity “Scott” –ArchiveQuota 2GB –ArchiveWarningQuota 1750MB

This will in essence give the user Scott an archive quote of 2GBs.  The system will issue me a warning once I get to 1.75GBs.  Again, the current setting is unlimited.  So if you have the disk space, or if the information archived is that important I would leave it at this setting and monitor your space usage.  The figures above are just examples, I am not saying you should set your archive quota to 2GB.  You can set it to whatever you like.  Keep in mind that the recommended DB size for Exchange 2010 is up to 16TBs.  You’ll be crazy to go that high, not to mention 2TB is the recommended max in a DAG and 200GB non DAG. 

Well, this concludes my posts on Enabling Exchange 2010 Archiving.  I hope you were able to learn something from these posts and thanks for visiting!

Next post will talk about disabling archive and what happens to an archive mailbox in that situation so stay tuned!

In my previous post I talked about the Exchange 2010 Archiving and what it does.  This post continues on from that previous post.

In order to enable Archiving in Exchange 2010 the exchange administrator needs to be familiar with Retention Polices and Retention Tags.

First let me start out on Retention Tags.  Retention Tags are used to apply retention settings to folders and individual items such as messages, notes, and contacts. These settings specify how long a message remains in a mailbox, and the action to be taken when the message reaches the specified retention age. When a message reaches the specified retention age, it’s moved to the personal archive, deleted, or flagged for user attention.  If you recall in my previous post there are five different actions that can be taken on a mailbox item when it reaches the retention age.  Again, those actions are: move to archive, move to deleted items folder, delete and allow recovery, permanently delete, or mark as past retention limit. 

Now when considering a RPT keep in mind that you can create RPT’s to the following default folders:

• Deleted Items
• Drafts
• Inbox
• Junk Mail
• Outbox
• Sent Items
• RSS Subscriptions
• Sync Issues
• Conversation History

To note you can not include more than one RPT for the same folder type in one retention policy.  This means that if you have a retention policy with a RPT for the inbox, that you cannot add another RPT configured for the inbox to that retention policy.  You will need to create another retention policy and assign that RPT to that retention policy. 

The next type of Retention Tags is the Default policy tags (DPTs).  DPTs are created to apply retention settings to untagged mailbox items. Untagged items are mailbox items that don’t have a retention tag applied to them either by inheritance from the folder they are located in, or applied explicitly by the user. DPTs are created by specifying the type All. A retention policy shouldn’t contain more than one DPT.  The DPT gives the Exchange Admin the ability to specify a retention policy to all objects in the users mailbox (except Calendar, Contacts, Journal, Notes, and Tasks).  By specifying a DPT the admin is able to control all contents of the mailbox.  What about custom folders that users create in their Exchange mailbox you ask?  Well, those items can be archived as well!  While you can create a RPT to specify a default folder you can also create the DPT that will act as a default policy tag.  This default Policy tag will then perform the specified action assigned to the Retention Policy on all folders in the mailbox.  This even includes folders created by the user to store mail data, i.e. a client’s folder containing email only specific to that client either as a sub folder to the inbox or a new folder under the root. 

The final type of Retention Tag is the Personal tags.  Personal tags are retention tags available to users as part of their retention policy. Users can apply personal tags to folders they create or to individual items. For example, you can create a personal tag to allow users to tag messages that are business critical, that have a higher message retention age of three years, and use the MoveToArchive retention action to move the messages to the user’s archive mailbox after three years.

From the perspective of Archiving however the best course would be to use the Default Policy tags.  What the Default Policy tag will do is create a retention policy that is applied to all users assigned the Retention Policy.  Perhaps in your organization you are not looking for a default policy, but rather one that applies strictly to the inbox, that’s great, but when coming to archiving you want to get all folders possible.  Think from a perspective where you have users who create another folder for certain clients, or filter items in another folder based on a month.  If you simply apply a RPT to the inbox, those items will not be included in the archiving process and risk being lost.  The same idea can be applied to an area where you want to delete items after x days.  You don’t want to miss anything!

So, how do we create the new tag that will be later applied to a policy?  Well, in the effort to archive you will want to leverage the command New-RetentionPolicyTag.  Basically what this command does will create a new retention policy tag.   Anyway, in effort to archive everything in the mailbox that is possible you will want to use the following command at the EMS.  Please note, you cannot use the EMC to create or delete retention policies. 

The command to use is:

New-RetentionPolicyTag “Users-RPT” -Type All -Comment “Items older then one month will be moved to Archive” -RetentionEnabled $true -AgeLimitForRetention 30 -RetentionAction MoveToArchive

What this command will do is create a new RPT called Users-RPT.  The key to this is the –Type.  By specifying the Type “All” it creates a DPT which will then include all folders capable of being archived in the users mailbox.  Comment I simply added what this policy does.  For the Age Limit I added 30 days.  Keep in mind the default setting for this is setting is in days, not years or months.  Finally the action we have is MoveToArchive.  This will archive the content of the users mailbox to the users archive mailbox which by current standards is stored in the same mailbox database as the users production mailbox. 

As a result of the command we now have a new retention policy tag which is configured to archive all content in the users mailbox except Calendar, Contacts, Journal, Notes, and Tasks. J 

In my next post I will talk about the Retention Policy and how to connect the Policy Tags to the Retention Policy and apply it to users or a group of users.

One of the new features of Exchange 2010 is the ability to perform archiving on user mailboxes that reside on the Exchange 2010.  With the combination of Outlook 2010 users now have the ability to have a primary mailbox which will host their Exchange 2010 production data and an Archiving mailbox which will store mail items based on the users preference or organizational Retention Policies.  I say Outlook 2010 because as I write this Outlook 2007 is not able to support the users archive mailbox.  Microsoft’s idea on archiving is to reduce the number of items and the size of a users production mailbox thus improving the performance on that production mailbox, while the archiving mailbox will retain the users old mail and will have a slower level of performance users will still be able to be search for material.  The other benefit to the Archiving piece in Exchange 2010 is that it is included with Exchange 2010!  Basically small organizations will not need to buy another solution to perform archiving.    Please note however, that in order for a user to benefit from Exchange 2010 Archiving an Outlook 2010 Enterprise CAL is required. 

So, from a user perspective the way archiving works is that a user is presented with two mailboxes (similar in Outlook 2007 where a user opens their mailbox and another user’s mailbox in the folder list).  Their folder list has two mailboxes, their primary mailbox and an archiving mailbox.  The advantage to using the archiving feature is that now all legacy mail items are stored on the exchange server where they can be properly backed up and managed by IT.  The shortfall to the Microsoft version of archiving is that the users archiving mailbox is stored in the same database as the users production mailbox.  I have heard rumors that storing the production mailbox and archive mailbox in the same database will change in the future, but no time frame has been released for this.  Depending on what you’re using for a storage platform that archiving data could reside on expensive disk, which would rather be used for production data.  Another thing to note is that archiving does not support the calendar!  I actually found this rather surprising being that many people (including myself) will want to go back and look at their calendar to figure out what they were doing say a year ago.  While this data resides on the calendar in the production mailbox it would still be nice to off load some of this data to the archive. 

Now, going back to archiving, technically it can be considered records management.  The reason I say this is because an organization is managing what to do with the data stored in the users mailbox.  Records Management has a number of options that can be configured through Retention Policy Tags.  The data in the mailbox can be moved to archive, move to deleted items folder, delete and allow recovery, permanently delete, or mark as past retention limit.

The MoveToArchive action moves a message to the user’s archive mailbox. Messages are moved to a folder in the archive mailbox with the same name as the source folder in the user’s primary mailbox.

The MoveToDeletedItems action moves messages to the Deleted Items folder. This emulates the behavior experienced by users when they delete a message. Items in the Deleted Items folder can be moved back to the Inbox, or any other mailbox folder. Depending on the user’s mailbox settings in Microsoft Office Outlook Web App or Microsoft Outlook, the Deleted Items folder may be emptied when the user logs off Outlook Web App or closes Outlook. You can also create an RPT for the Deleted Items folder to take the required action on messages in the folder after a certain period.

The DeleteAndAllowRecovery action emulates the behavior when the Deleted Items folder is emptied or the user hard deletes a message. When this happens, and deleted item retention is configured for the mailbox database or the user, messages move to the Recoverable Items folder. The Recoverable Items folder, also known as the dumpster, provides the user another chance to recover deleted messages.

The PermanentlyDelete action permanently deletes a message. When this action is applied to a message, it’s purged from the mailbox. This action is like a deleted message being removed from the Recoverable Items folder. After this happens, the user can no longer recover the message.

The MarkAsPastRetentionLimit action marks a message as past the retention limit. Supported Outlook clients (Outlook 2010 and Office Outlook 2007) display messages that are past their retention limit using strikethrough text. Users who use a supported client notice the changed display and recognize the message as expired, and they can be encouraged to take further action, such as deleting the message or moving it to the archive mailbox. This action is intended to make expired messages noticeable, which encourages users to follow the organization’s messaging policies, and makes an action such as deleting the message unnecessary. This can be used as the initial step to create awareness about MRM.

Since I’m focusing on archiving I will stick with that angle.  I should point out however organizations like to retain items for legal reasons or like to delete items for legal reasons.  Either way the records management included in Exchange 2010 can perform both.

In my next post I will discuss the steps required to enable archiving.