Mailhelp

This is a part 2 of blog posts on this subject, you can read part 1 here.

Within the first part of this post, I showed you had to remove the Reply-All functionality via GPO. At its core the process is relatively straight forward (obtain Outlook ADM templates, define policies, link and deploy it). However you have to take some things within this article at "face value". Specifically, the values I provided for the Command Bar ID as well as the values for disabling the keyboard shortcuts within the respective policies.

At this point I wanted to take some time to show you how to verify these for yourself. The benefit being that you would be able to leverage a number of the techniques presented here to successfully disable other shortcuts and/or command buttons should and when you so desire.

Prior to getting started it is worth noting that two separate approaches need to be utilized to obtain the appropriate command and shortcut IDs. Out on the Internet there seems to be a lot of confusion on how to best determine the Command Bar IDs, so I'm going to start with that first as it seems to be giving the most people difficulty.

Determining Command Bar IDs:

In retrospect there are a number of different techniques that could be utilized to obtain the valid Command Bar IDs in Outlook.

• MSKB 1736004 ((http://support.microsoft.com/kb/173604), actually has a complete list for Outlook 97. I don't know about you... but that is a bit old for my taste, although obviously most of the Command-IDs will stay the same for backwards compatibility, etc. Nevertheless a simple review of that document will show that the Command ID for "Reply All" is = 355.

CommandBar                      Control ID
------------------------------------------
Compose Reply to All               355

• You could also use a tool like Outlook SPY. Once you become proficient with it the Command IDs will be easily ascertained.

How I did it:

A very easy way to do this is to use Outlook Visual Basic Editor. So the first thing you need to do is enable the VBA Editor if you are not already doing so (most people don't).

To Enable:

• Open Outlook.
• Select the Tools menu, and then select Options.
• Select the "Other" tab.
• Select Advanced Options.
• Under "In all Microsoft Office Programs" section select "Show Developer tab in the Ribbon".
• Select OK.
• Then Apply and OK on the Options page.
• Restart Outlook.

Once Outlook has been restarted, you can now use Visual Basic for Applications to determine the Command Button ID for Reply-All.

The code to follow is loosely based on the sample provided in MSKB 173604 with some subtle changes. First this code when executed will create a file on the root of the d:\ named OLIDS.txt. So, if you don't have a d:\ you will need to adjust the code as appropriate to reflect a valid path. However once properly executed you will have an output file in text format with all the valid Command IDs for Outlook.

Steps:

• Open Visual Basic in Outlook.
• Add a reference to the Microsoft Scripting Runtime Library (From the Tools menu in the VBA Editor, select References, and then add the Microsoft Scripting Runtime). Once located, select OK to return to the VBA Editor:

• Paste the following code into your project:

Sub GetIDsForInspector()
      ' The Outlook object library must be referenced.
      Dim objOL As New Outlook.Application
      Dim objCommand As Object
      Set cb = objOL.ActiveExplorer.CommandBars
      ' We will Create a new Text document.
      Dim objtxt
      Dim txtfile
      Set objtxt = CreateObject("Scripting.FileSystemObject")
      Set txtfile = objtxt.CreateTextFile("D:\OLIDs.txt", 8)
         ' 3500 is the maximum # of Controls Outlook has defined.
         For I = 1 To 3500
            Set lbl = cb.FindControl(, I)
            If lbl Is Nothing Then
               ' Do nothing.
            Else
               ' Insert CommandBar name, Command name, and ID.
               txtfile.WriteLine (lbl.Parent.Name & Chr(9) & lbl.Caption & Chr(9) & I)           
            End If
         Next
      End Sub

• Run the Form. Once done you will notice a text file has been created on the d:\ named OLIDS.txt. Open this file in notepad. You will notice that the Standard Menu Bar has a Command ID of 355 for Reply to All:

Standard     Reply to A&ll 355

Note:

If you didn't care about compiling an entire list of all Command IDs but only wanted to get the value for Reply All, you could substitute the above code with what I have below. This script will simply throw the value into a message box:

Sub GetIDsForInspector()
      ' The Outlook object library must be referenced.
      Dim objOL As New Outlook.Application
      Dim objCommand As Object
      Set cb = objOL.ActiveExplorer.CommandBars
      ' Create a new Text Document.
      Dim objtxt
      Dim txtfile
      Set objtxt = CreateObject("Scripting.FileSystemObject")
      Set txtfile = objtxt.CreateTextFile("D:\ \OLIDs.txt", 8)
         ' 3500 is the maximum # of Controls Outlook has defined.
         For I = 1 To 3500
            Set lbl = cb.FindControl(, I)
            If lbl Is Nothing Then
               ' Do nothing.
            Else
               ' Insert CommandBar name, Command name, and ID.
'Uncomment next 2 lines if you want all Outlook CMD Ids
               'txtfile.WriteLine (lbl.Parent.Name & Chr(9) & lbl.Caption & Chr(9) & I)
               If (InStr(lbl.Caption, "Reply to A&ll")) Then
                MsgBox lbl.Parent.Name & Chr(9) & lbl.Caption & Chr(9) & I
                Exit For
                End If        
            End If
         Next  
   End Sub

So this is where the value of "355" came from in the "Disable Command Bar Buttons and Menu Items Policy" (from Part 1 of this post). Screenshot again:

Determining the Short Cut Key IDs and Modifiers:

As evident from above, the shortcut key consists of two independent numbers separated by a ",". The first number is the actual shortcut key (R in this scenario). To get the proper value you need to convert the ASCII character to a decimal value. This is easy enough to do by simply looking it up in an ASCII table (http://www.asciitable.com/).

As you can see the capital "R" character equates to 82 in Decimal Notation:

So this is how the first number set is defined for the shortcut pair.

The second set of numbers (in this case 12) is determined by the fact that the CTRL + SHIFT modifiers must be used in (conjunction with the R key), to issue the short cut.

The numerical equivalent for the shortcut modifiers:

Alt = 16

Ctrl = 8

Shift = 4

When multiple modifiers are used (as in this case), the numerical values must be added together. So in the case of a Reply All keyboard shortcut that uses (CTRL + SHIFT + R)

CTRL = 8

Shift = 4

Total: 12

This is why we needed to add the value of 82,12 to the Key and Modifier to Disable entry on the Disable Command Bar Buttons and Menu Items Policy. Screenshot again (see Part 1 of this post):

As I mentioned earlier in the post you can apply this knowledge to other Outlook Command IDs and shortcuts rather easily. After deciding on what Outlook Command Button(s) or Short-Cut(s) you want to disable, you simply perform the conversions and add them to the now in-place Custom GPO.

For reference these are some additional Command IDs and shortcuts that should prove as a decent guide for double-checking your understanding of how the conversions are performed:

Item:	Command Bar ID:	Short-cut Pair:	Actual Outlook Short-cut:
New Mail:	1757	78,8	CTRL+N
Send Email:	2617	83,16	ALT+S
Forward Email:	356	70,8	CTRL+F
Print:	4	80,8	CTRL+P
Delete:	478	68,8	CTRL+D
View GAL:	353	66,12	CTRL+SHIFT+B
Move to Folder:	2278	86,12	CTRL+SHIFT+V

Conclusion:

The combination of techniques described in this post provides an easy, legitimate way of disabling Reply-All functionality within the Outlook client (no DCR required!), should and when it be called for. Additionally these techniques can be "massaged" to fit other potential needs with an Active Directory/Exchange/Outlook environment.

I hope you found the post interesting and useful. If you did, please share your thoughts with me by leaving some feedback comments (I do read them!).

Happy Trails!

- Eric Norberg

Just recently I was speaking to a Microsoft Premier Field Engineer (PFE) who had just returned home from a rather arduous onsite dispatch. While onsite he was tasked with unwinding a phenomenon commonly referred to as a "Reply-All" storm (defined below). This task had been so tedious that he half-jokingly mentioned that he was thinking about submitting a formal Design Change Request to the Exchange/Outlook Product Groups with a proposal to remove Reply-All functionality from within Outlook. Well this got me thinking... "could the removal of Reply-All functionality actually be done with the tools at an Administrator's immediate disposal today"? Eventually curiosity got the best of me and I started performing some basic research on the issue. Throughout the course of this research I found a jumbled set of different articles and blog posts that appeared rather half baked in scope to me. That being said, what did become abundantly clear was that there were a significant number of administrators (as well as standard users) who have expressed interest in this functionality and have actually been looking for it for some time.

Presto: Blog idea.

To be clear there are a number of different approaches for achieving the goal of disabling Reply-All in Outlook. The most common technique would appear to be the creation and deployment of custom Outlook toolbars. Far more infrequent are macros in Outlook as well as custom Group Policy Objects (the primary topic of this post). Additionally, while future versions of Exchange will include features to deal with this problem much better (read about Exchange 2010 Conversation View here) - I wanted something that people can use now, with versions of software they currently have.

As previously noted, this post is going to focus on the use and deployment of a custom Group Policy to disable the Reply-All functionality in Outlook. This post will not focus on disabling Reply-All in OWA (which would require modifications to the ASP Pages) and will also not cover disabling this functionality in Windows/Outlook Mobile.

My hope is that you will find this post interesting; that it helps clear up some of the confusion on the subject; and that you learn some new skills along the way. Should and when you choose to deploy a scenario like this, I hope this document serves to aid you in increasing the stability of your messaging environments and networks as a whole.

As you will soon see, this post has a little bit of everything, Exchange, Active Directory, Group Policies, Outlook and even some "old/new school" VBA.

I hope you enjoy it and learn something new in the process!

Back Story:

Nearly every user within a corporate messaging environment has at one time or another been the unfortunate chance victim of a "Reply-All Storm".

It starts out innocently enough:

• Typically a formal communication it sent out to a large internal distribution list.
• A member of the distribution list strays off course or asks to be "taken off the distribution list".
• A series of people start replying "ME TOO" via a Reply-All.
• Another member of the list, "Replies All" to the request, and asks everyone to "PLEASE DO NOT REPLY ALL !!!!@!!@!!!".
• Cycle perpetuates itself over and over.
• Users come into the office and notice literally hundreds of emails all with the same subject sitting in their inbox.
• They read the most recent thread, whisper to themselves (geez...not this again), then proceed to delete the entire thread and possibly miss the actual intention of why the original mail was sent out in the first place.

Not only is this extremely annoying, but obviously has larger corporate and financial implications as well:

• Loss of productivity for client base.
• Potential service interruptions for a variety of different reasons.
• Storage implications on the Exchange Back-End.
• Puts unnecessary strain on Exchange, Active Directory and network links.
• A host of Administrative implications ranging from increased backup times, etc.
• Loss of credibility (if say an external contact was a member of the list or even your immediate manager or "higher ups", etc.)

Upon first read this may seem funny but it is actually a very serious problem. For a blow by blow of the infamous "BEDLAM DL3" issue that occurred internally here at Microsoft several years ago I suggest a review of the following post: http://msexchangeteam.com/archive/2004/04/08/109626.aspx. The issue is definitely real and varying degrees of the problem are most likely occurring somewhere in the world at this very second.

Before Getting Started:

I want to stress that the steps outlined below are not going to resolve an immediate Reply-All storm. However, it is very possible that they may help reduce or mitigate a future problem from occurring once your user base learns (either by word of mouth or "the hard way") that there are potential consequences for perpetuating one. Again, I'm talking about helping to bring about positive educational change in your user base over time.

The steps outlined below will effectively remove a user's ability to use the Reply-All functionality in Outlook via creation and deployment of a custom Group Policy Object (GPO). The examples presented below will target a dedicated Active Directory Organizational Unit. This OU will ultimately become the target for the deployment of the GPO as well as the container where user objects that have Reply-All removed will be homed in the Active Directory. That being said, the techniques presented here could be adapted to a broader environmental context based upon the discretion/desire of the administrator.

Thus to perform the steps here you will need at your immediate disposal:

• Access to the Active Directory.
• The ability to create a dedicated Organizational Unit.
• The rights to move members of your user base to said Organizational Unit.
• The ability to modify and/or create a new custom GPO.
• The ability to link/deploy said GPO.

Hypothetical Scenario and Steps:

You come into the office and your immediate manager mentions that the messaging group has been tasked with removing Reply-All ability for all users who participated in a recent Reply-All storm that impacted a large internal distribution list. Upper management has made a decision to not implement bulk message restrictions to the Distribution List itself (e.g. limiting who can send or reply to messages on the DL), but to simply remove Reply-All ability for all users who played a part in perpetuating the storm. The removal of this functionality will be accomplished via deployment of a GPO as opposed to leveraging other potential options.

Step-1:

Obtain and review the most recent thread in the Reply-All storm and build a list of all individual user accounts that either caused or played a part in perpetuating the storm. Build a master list of these users and denote the current location of their user objects within the Active Directory. Once done, receive "buy-off" from management that these users can and will eventually be moved into a dedicated Organizational Unit that will have a GPO applied that prevents the Reply-All button from being active within Outlook.

Step-2:

Once you have obtained buy-off, build a new Organizational Unit with an obvious clear name. To do so, go into Active Directory Users and Computers, right-click a user container, then select New, Organizational Unit, then provide it with a clear name.

In the examples to follow my OU will be titled: "Users who have Reply All Removed"

Step-3:

Move the users into the new" Users who have Reply All Removed" organizational unit via Active Directory Users and Computers (or your favorite LDAP tool) created in Step-2.

Step-4:

If not already available proceed to download the appropriate Office Administrative Template files. In my scenario all my users can be assumed to be using Outlook 2007 Service Pack 2. The template files can be downloaded here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=73d955c0-da87-4bc2-bbf6-260e700519a8&displaylang=en

Legacy Office Administrative Template Files can be downloaded from Office Online. So if your client base is running Outlook 2003, go here: http://www.microsoft.com/office/orkarchive/2003ddl.htm

Step-5:

Extract the Administrative Template files by running AdminTemplates.exe. Once extracted you should have 3 folders created (ADM, ADMIN, and ADMX):

Step-6:

Build a new Group Policy that links users of the "Users who have Reply All Removed" organizational unit. To do so:

• In Active Directory Users and Computers get Properties of the "Users who have Reply All Removed" organizational unit.
• Select the Group Policy Tab.
• On the Group Policy Tab, select New and give the policy a clear and applicable name such as "Remove Reply-All Ability"
• Once named, select Edit.
• The Group Policy Editor (GPE) opens.

Step-7:

Add the Office/Outlook Administrative Templates

In Group Policy Editor:

• Navigate to User Configuration\Administrative Templates.
• Right-Click Administrative Templates and select Add/Remove Templates.

• On the Add/Remove Templates page select: Add
• Browse to the Outlook Administrative Template and Select Open (in my case I uncompressed the file to my desktop so the path was: c:\Documents and Settings\ericnor\Desktop\OLK2K7 Admin Templates\ADM\en-us\outlk12.adm):

If performed successfully you should now see that the Microsoft Office Outlook 2007 Administrative Template files have been added in Group Policy Editor:

Step-8:

Once you have successfully added the Outlook Administrative Template, you need to properly define and enable the necessary policies. To successfully block "Reply All" functionality we need to enable and define two specific policies in the Administrative Template:

• A policy to disable the actual command button as well as the menu option.
• A policy to disable the keyboard shortcut.

To accomplish:

• In Group Policy Editor navigate to the following path: User Configuration\Administrative Templates\Microsoft Office Outlook 2007\Disable Items in User Interface\Custom.
• Once here you will notice 2 policies that will currently show as "Not Configured":

• Disable Command Bar Buttons and Menu Items.
• Disable ShortCut Keys.

To disable the Command Bar Reply-All button we need to select the Disable Command Bar Buttons and Menu Items Policy.

• Once the policy is open set the State of the policy to Enabled then select the "Show..." button.
• Any and all Outlook Command Bar Buttons that are currently disabled will be present here in a numerical context (although presumably this would be the first time working with the template so you would not see any numerical values present). Click Add, and in the "Enter the Item to Be Added" field, type 355. Once done click OK. You will be returned to the Show Contents page which should now resemble the following. Click OK:

(It's worth making a note here: All command buttons and menu options are referenced by their numerical Command IDs. I will show you how to determine these values in a follow-up post, so that you can apply what you have learned to other command buttons and short-cuts should you desire).

• Back on the Disable Command Bar Buttons and Menu Items policy page, select Apply and OK.
• The "state" of the policy should now show as Enabled.

Now we need to disable the keyboard shortcut for Reply All. To do so, we need to open the Disable Shortcut Keys policy, configure our settings and enable it. To do so:

• Select and open the"Disable Shortcut Keys" policy.
• Select Enable, and then click the "Show..." button.
• This will bring up the Show Contents page.
• Select Add.
• In the Add Item Window type the following: 82,12
• Click OK which will shift the focus back to the Show Contents pane. Your value should look like this:

(Short-cut keys are always distinguished via the decimal representation of their ASCII character value. In addition the keyboard modifier (e.g. the keyboard combination used to activate the short-cut) needs to be converted to decimal notation and referenced here. As previously noted, I will detail how these values are calculated and converted in a follow-up post).

• Back on the Disable Shortcut Keys property pages, select Apply and OK.
• Back in Group Policy Editor, both policies should now show as Enabled:

• At this point both of your policies are enabled and configured.
• Close Group Policy Editor.
• You will be returned to the Group Policy tab for the "Users who have Reply All Removed" Organizational Unit. Click Apply then Close.

Step-9:

Provide "The List" to Help Desk.

You should inform the Help Desk that there is a very high probability that users on "the list" will be calling in to complain that their Reply-All functionality no longer works. Your Help-Desk personnel should know why.

Step-10:

Create a Distribution List then and add all members of "the List". Send an informational to all users informing them that their "Reply-All" functionality has been removed due to misuse and for "x" amount of time. Once the GPO has been applied to the user workstation, these users will notice that the "Reply to All" button is disabled. If one of these users were to hover their mouse over the disabled button they will be presented with the following information:

They will also notice that the menu option for Reply-All is now disabled:

If the user attempts to issue the keyboard shortcut for Reply-All (CTRL + SHIFT + R), nothing will happen.

I will cover additional related "Techy stuff" on this process in a follow-up post!

Happy Trails!

- Eric Norberg

Microsoft Outlook now has its very own fan page on Facebook, which means you now have an easy way to get free tips about your favorite program, share ideas about the ways you use Outlook, and get answers to Outlook-related questions that you’ve always wanted to ask.

The nice thing about joining the Outlook fan page is that it integrates nicely with Facebook’s existing news feed and notification system. You can choose to see Help & How-to tips in your Facebook news feed automatically or read them only when you want to. Similarly, if you post something on the fan page, you can choose to be notified whenever someone responds to you.

Here’s a quick walkthrough of how the Microsoft Outlook fan page on Facebook works:

Join the Outlook fan page (it’s free!)

If you already have a Facebook account, sign in, and then follow these simple steps:

1. Visit http://www.facebook.com/pages/Microsoft-Outlook/82443952619
2. Near the top of the page, click .

Now you’ll be able to keep in touch and receive updates directly through your newsfeed. See you there!

- The Microsoft Outlook Team

Introduction

Users often delete data from their mailboxes that they later want recovered. Recovery of these deleted items is the most common reason for IT admins to recover data from traditional point-in-time backups today.

With previous versions of Exchange Server, administrators implemented two solutions to enable single item recovery, dumpster and restores.  Both had their issues, unfortunately. 

Exchange 2010 aims to reduce the complexity and administrative costs associated with single item recovery.

Terminology

The following definitions may be useful for understanding the content within this article:

• Store Soft Delete - this is when an item has been deleted from the Deleted Items folder and placed within dumpster.
• Store Hard Delete - This is when an item has been marked for purging out of the store.
• Hard Delete via Outlook (Shift-Delete) - This is when the end user performs a shift-delete on an item.  This results in the item bypassing the deleted items folder and being directly placed in dumpster.

Single Item Recovery in Previous Versions of Exchange

The end user single item recovery functionality was enabled through the store via the store dumpster.  Administrators configured the dumpster setting on a per database or per mailbox basis.  The default deleted item retention window in Exchange 2003 is 7 days, while with Exchange 2007 the default is 14 days. 

The end user recovery process worked typically like this (see figure 1):

1. User receives message.
2. User deletes the message.  The message is moved to the Deleted Items folder.
3. The user empties the deleted items folder (or an automated process like Managed Folders or Records Management deletes items out of the deleted items folder on a scheduled basis).
4. The user then realizes he requires the previously deleted item.  Using Outlook the user accesses Recover Deleted Items. 
5. Assuming the deletion timestamp of the deleted item is still within the deleted item retention period, the user has two choices:

1. The user can recover the item.  The recovered item is placed back in the Deleted Items folder.
2. The user can purge the item from recover deleted items.  This results in the deletion of the message permanently from the user's mailbox.

Figure 1. Dumpster in Previous Versions

If the item's deletion timestamp is beyond the deleted item retention period, then the item is not available for end user recovery.  Instead, the user must call Help Desk and request recovery of the item.  This involves:

1. The user knowing when he deleted the item.
2. The Exchange administrator locates a backup that contains the item in question.
3. The Exchange administrator successfully restores the database to a recovery storage group.
4. The Exchange Administrator extracts the deleted item and provides it back to the user. This of course assumes that there is a policy that allows for single item restoration and that this process isn't a really low priority for the Exchange administrator.

If the backup is invalid, or if there is no backup for the time period in question, then the deleted data is unrecoverable.

The other issue that needs highlighting is the fact that in previous versions of Exchange there is no way to prevent the end user from purging the data from the Recover Deleted Items view.  This poses a significant legal risk for organizations that must ensure compliance requirements are met.

Dumpster Changes

In previous releases of Exchange Server, dumpster is essentially a view stored per folder.  Items in the dumpster (henceforth known as Dumpster 1.0) stay in the folder where they were soft-deleted (shift-delete or delete from Deleted Items) and are stamped with the ptagDeletedOnFlag flag.  These items are special-cased in the store to be excluded from normal Outlook views and quotas.  In addition, data with this flag cannot be searched or indexed.

Note: Users can perform a shift-delete and cause a message to bypass the Deleted Items folder and go straight to dumpster. Prior to Outlook 2007, the Recover Deleted Items tool, by default, only exposed the dumpster view for the Deleted Items folder. By setting the DumpsterAlwaysOn registry key (http://support.microsoft.com/kb/886205) you can enable the Recover Deleted Items tool for all folders in the mailbox and thus expose dumpster data for any folder in the Exchange 2003 or Exchange 2007 mailbox.

One of the key architectural changes in Exchange 2010 is to truly enable a litigation hold experience for customers that have legal compliance requirements.   As a result, Exchange 2010 must meet these requirements:

• Exchange has to ensure that dumpster data moves with the mailbox.
• Dumpster data must be indexed and discoverable.
• Dumpster must have a quota.
• Exchange has to prevent purging of data from dumpster.
• Exchange has to track edits of certain content.
• Dumpster should be per mailbox and not per folder.

In order to facilitate these requirements, Dumpster was re-architected.   Unlike Dumpster 1.0, Dumpster 2.0 is no longer simply a view.  Dumpster in Exchange 2010 is implemented as a folder called the Recoverable Items and is located within the Non-IPM subtree of the user's mailbox (note that this is a hidden section of the mailbox and is not exposed to the end user through any client interface).  The folder has three sub-folders:

1. Deletions
2. Versions
3. Purges

The Deletions folder replaces the ptagDeletedOnFlag view that was displayed when a user accessed the Recover Deleted Items tool.  When a user soft deletes or performs an Outlook hard delete against an item, the item is moved to the Recoverable Items\Deletions folder.  When the user accesses Outlook/OWA Recover Deleted Items, the RPC Client Access service translates the request and returns the Recoverable Items\Deletions folder view.

The Versions and Purges folders will be covered in the Single Item Recovery in Exchange 2010 section.

By architecting Dumpster to be a folder, three of the requirements are immediately met:

• Dumpster data is now indexed and discoverable.
• Dumpster data can now be moved with the mailbox.
• Dumpster data is now stored on a per-mailbox basis rather than a per folder basis. From an end-user perspective, this means that deleted data is now easier to recover because Recover Deleted Items tool will now expose deleted data across the entire mailbox.

To ensure that Denial of Service attacks by placing large quantities of data into dumpster are prevented, Dumpster 2.0 has configurable quota settings.  These settings can be configured per database and per mailbox:

• RecoverableItemsWarningQuota - Sets the soft limit that defaults to 20 GB.  When the Recoverable Items folder reaches that size, the Exchange administrator will be notified via an event log alert.  This alert should fire at the time the mailbox reaches the limit and once daily afterward.  By default, the mailbox is not configured with this property, meaning that database-level limits are used. At this limit items will begin to be deleted from the dumpster using the first-in / first-out (FIFO) principle - essentially, the oldest items in the dumpster are deleted first. For example, consider a mailbox that has a dumpster that is 20GB in size and the user deletes an additional 50MB worth of data. In this case, the oldest 50MB worth of data is deleted to make room for the new 50MB worth of data.
• RecoverableItemsQuota - Sets the hard limit that defaults to 30 GB. At that limit, soft deletes will fail.  The Exchange administrator will be notified via an event log alert.  This alert should fire at the time the mailbox reaches the limit and once daily afterward.  By default, the mailbox is not configured with this property, meaning that database-level limits are used.

Note: Exchange 2010 includes capability for each mailbox to also maintain an archive mailbox as well.  There is a dumpster for both the primary mailbox and the archive mailbox. Data deleted in the primary mailbox is placed in the primary mailbox dumpster, while data deleted in the archive mailbox is placed in the archive mailbox dumpster.

Single Item Recovery in Exchange 2010

But how does Exchange 2010 meet the other two requirements, ensuring data is not either accidentally or maliciously purged and that versions are tracked?  Exchange 2010 now includes two mechanisms to meet those requirements:

1. Short-term preservation of data
2. Long-term preservation of data

Short-Term Preservation of Data

Exchange 2010 includes the ability to ensure that data within the mailbox is preserved for a period of time.  This feature can be enabled enabled on a per mailbox basis by running the following cmdlet: 

Set-Mailbox <identity> -SingleItemRecoveryEnabled $true

Note: When enabling this feature, you will be notified that it could take up to 60 minutes for single item recovery to take effect. This is an approximation due to Active Directory replication. Be sure to evaluate your Active Directory replication topology with respect to administering recipients to understanding how Active Directory replication may impact changes in your environment.

The time period by which the deleted data is maintained is based on the deleted item retention window.  The default time period is 14 days in Exchange 2010 and is configurable per database or per mailbox. The following cmdlets let you alter this behavior:

For the mailbox database: Set-MailboxDatabase <identity> -DeletedItemRetention <Number of Days>

For the mailbox: Set-Mailbox <identity> -RetainDeletedItemsFor <Number of Days>

Note: Regardless, of whether you have Single Item Recovery enabled, calendar items are maintained in the Recoverable Items folder structure for 120 days. Long-term data preservation via litigation hold will disable the expiration of the items.

At this point you may be thinking, how is this any different than in previous versions of Exchange?  With short-term preservation deleted items will still be moved into the Recoverable Items folder structure.   However, the data cannot be purged until deletion timestamp is past the deleted item retention window.  Even if the end user attempts to purge the data, the data is retained.  Consider this example by a malicious user:

1. User sends or receives a message that is legally incriminating.
2. User deletes the message.  The message is moved to the Deleted Items folder.
3. The user empties the deleted items folder.
4. The user accesses the Recover Deleted Items functionality in Outlook or OWA.
5. The user then selects the item and deletes the item.  At this point the user believes he has removed the incriminating evidence.  And this is a key strength in this work flow as the end user's actions are not interrupted or prevented; in other words, the end user's work flow is not impaired with single item recovery enabled.

However, the message was not purged from the mailbox store.  Instead the message was moved from the Recoverable Items\Deletions folder to the Recoverable Items\Purges folder.  All store hard-deleted items end up in this folder when single item recovery is enabled.  The Recoverable Items\Purges folder is not visible to the end user, meaning that they do not see data retained in this folder in the Recover Deleted Items tool.

When the message deletion timestamp has exceeded the deleted item retention window, Records Management will purge the item. See Figure 2 for a visual representation of this behavior.

Figure 2. Dumpster 2.0

Not only does short term preservation prevent purging of data before the deleted item retention window has expired, but it also enables versioning functionality.  Essentially when an item is changed, a copy-on-write is performed to preserve the original version of the item.  The original item is placed in the Recoverable Items\Versions folder.  This folder is not exposed to the end user.   What triggers a copy-on-write?

• For messages and posts (IPM.Note* and IPM.Post*), copy-on-write will capture changes in the subject, body, attachments, senders/recipients, and sent/received dates.
• For other types of items, copy-on-write will occur for any change to the item except for moves between folders and read/unread status changes.\
• Drafts will be exempt from copy-on-write to prevent excessive copies when drafts are auto-saved. 

The data stored in the Recoverable Items\Versions folder is indexed and discoverable by compliance officers.

Long-Term Preservation of Data

Customers sometimes require mechanisms by which data is maintained for longer periods of time, say indefinitely.  This is typically due to litigation hold that occurs when the organization is undergoing a lawsuit.  With Exchange 2010, litigation hold can be enabled via the Exchange Control Panel or by setting the property LitigationHoldEnabled via the Set-Mailbox cmdlet.

Note: When enabling this feature, you will be notified that it could take up to 60 minutes for single item recovery to take effect. This is an approximation due to Active Directory replication. Be sure to evaluate your Active Directory replication topology with respect to administering recipients to understanding how Active Directory replication may impact changes in your environment.

When litigation hold is enabled, records management purging of dumpster data ceases.  Consider the following four cases:

1. When the end user deletes an item from the "Deleted Items" folder or shift-deletes Outlook/OWA from any folder (soft delete), the item is moved to Recoverable Items\Deletions folder, where it can be recovered in the Outlook /OWA "Recover Deleted Items" view.
2. If the end user purges data from the "Recover Deleted Items" view (hard delete from the Recoverable Items\Deletions folder), the item will be moved to the Recoverable Items\Purges folder.
3. When records management purges data from the Recoverable Items\Deletions folder (due to the deleted item age limit being reached), the item will be moved to the Recoverable Items\Purges folder. 
4. When an end user modifies an item, a copy of the original item is placed in the Recoverable Items\Versions folder based on the criteria discussed in the Short-Term Preservation of Data section.

Also, when litigation hold is enabled, the properties RecoverableItemsWarningQuota and RecoverableItemsQuota (defined either on the mailbox database or mailbox) are ignored. In other words, since litigation hold is enabled, the dumpster quota is not enforced, thereby ensuring that data is not purged or data is prevented from being stored within the dumpster.

Recovering Purged Data

Data that is stored in the Recoverable Items\Purges folder is not accessible or discoverable by the end user.  However the data is indexed and discoverable for those that have the proper access role in the Exchange organization role.  Role Based Access Control (RBAC) provides the Discovery Management role to allow secure search access to non-technical personnel, without providing elevated privileges to make any operational changes to Exchange Server configuration.  Compliance officers or other Exchange administrators with the Discovery Management role can leverage the Exchange Control Panel (ECP) to perform discovery searches using an easy-to-use search interface.

When a single item recovery request is received by help desk, the following actions can be taken:

1. Either Help Desk or a member of the Discovery Management role utilizes the Exchange Control Panel to target a search against the user's mailbox to locate the data in question.  The framework to perform the search allows the administrator to use Advanced Query Syntax.  The recovered data is then extracted and placed in the Discovery Mailbox in a folder that bears the user's name and the date/time that the search was performed.
2. The administrator then opens the Discovery Mailbox via OWA or Outlook and verifies that the content recovered is the content requested by the end user.
3. The administrator then leverages the Exchange Management Shell to perform an export-mailbox against the discovery mailbox targeting the end user's mailbox.  The data is then placed back into the end user's mailbox.
4. Help Desk can close the ticket.

Backups and Single Item Recovery

Naturally after understanding the features included in Exchange 2010, a logical follow up question is "Do I still need backups for single item recovery?"  The answer depends on your backup requirements and your capacity planning.

Today many customers minimize the deleted item retention window, yet they maintain long backup retention time periods (from 14 days to several months to years). 

Let's consider a customer that currently maintains backups for 90 days and only retains deleted items within Exchange for 5 days. This customer is performing backup restores on a weekly basis to recover deleted items for end users.  If the customer moved to Exchange 2010 they could move that process into Exchange by simply increasing their mailboxes capacity for dumpster:

• Users send/receive 100 messages per work day and have an average message size of 50KB
• Single Item Recovery is enabled and the deleted retention window is configured to be 90 days
• 10% of items are edited
• Mailbox capacity calculations

• 5 work days * 100 emails = 500 emails / week
• For Purges:

• 500 emails / week * 13 weeks = 6500 emails / retention period
• 6500 emails * 50KB ? 318MB

For Versions:

• 500 emails / week * 13 weeks = 6500 emails / retention period
• 6500 emails * .1 = 650 emails
• 650 emails * 50KB ? 32MB

Total Space Required per mailbox: 350MB

By increasing each mailbox's capacity by a minimum of 350MB, backups are no longer needed for single item recovery.  Single item recovery can be maintained and performed within Exchange.

But let's not stop there.  What if the requirement is that items must be recoverable for 1 year?  Assuming the same assumptions used in the previous example with the exception that deleted item retention is now configured for 365 days, each mailbox needs an additional minimum 1.4GB of space.

Ultimately, if the storage subsystem is planned and designed appropriately and mailbox resiliency features are leveraged, traditional point-in-time backups can be relegated to a disaster recovery mechanism, if they are even needed at all.

Conclusion

Exchange 2010 introduces the concept of single item recovery.  Single Item Recovery prevents purging of data and provides versioning capability (the ability to retain the unaltered form of the item).   By default this data is retained until the age of the deleted item has exceeded the deleted item retention window.  In addition, Exchange 2010 enables long-term preservation of data for litigation hold scenarios by preventing the purging of data all together.   The following table summarizes the behavior in Exchange 2010:

Feature State	Soft-deleted items kept in dumpster	Modified (versions) and store hard-deleted items kept in dumpster	User can purge items from dumpster	MRM automatically purges items from dumpster
Single item recovery disabled	Yes	No	Yes	Yes, 14 days by default and 120 days for calendar items
Single item recovery enabled	Yes	Yes	No	Yes, 14 days by default and 120 days for calendar items
Litigation hold enabled	Yes	Yes	No	No

- Ross Smith IV

We are interested in hearing feedback on your experience deploying and/or managing Unified Messaging in Exchange. We are conducting research to understand users' pain points and frustrations around deployment and management of unified messaging. Please take 5-10 minutes to answer the survey questions. This type of feedback directly impacts product decisions and we would appreciate your valuable feedback.

The survey can be found here.

Thank you for your time!

- Brendan Reeves
(User Experience Researcher)

ContactCopy creates Outlook contacts from text containing contact information (like email signatures, contact data on websites, etc.) ContactCopy recognizes addresses and phone numbers from the USA and more than 20 European countries.

copy2calendar automatically converts text containing appointment information into Outlook calendar entries. It recognizes date and time specifications in 13 languages and can be configured to handle virtually any existing date/time format. copy2calendar can be used from any Windows application.

A common problem with email searches is that they can return too many results. For example, entering someone’s name may return matches where the name appears in parts of the message’s body even though you meant to look for messages from that person. It can be also hard to enter other criteria to help narrow your search, such as whether it has an attachment or that it has a particular category applied. Wouldn’t it be great if you could specify these parameters easily and get a better set of results - finding what you want even faster? Outlook 2010 makes it easy!

Outlook 2010 makes searching your mailbox more efficient with two new features: the Search Contextual Tab in the Ribbon and the Search Suggestion List.

 

Search Contextual Tab

The Search Contextual Tab is displayed each time you click into the search box. It allows you to filter your search results using a variety of parameters, including:

· Sender’s name

· Subject keywords

· Presence of attachments

· Categories

· Sent date

· Flagged messages

· The recipient’s name in the TO or CC fields

· Importance

· Read/unread status

· … and many more!

You can use this tab to help you find messages quickly and easily. For example, suppose you are searching for a message with the phrase “Food Blog”, but more than 100 items return matching that query. Let’s suppose you also remember that this message has an attachment. Now you can instantly narrow down the results to a much smaller set to find what you are looking for by clicking the Has Attachments button in the Search Contextual Tab:

And that’s just one of the many filters available in the Search Contextual Tab!

 

Search Suggestion List

The vast majority of searches contain a combination of keywords, along with the names of the sender or a known phrase in the subject line. Restricting results to a specific sender is a powerful filter that often helps narrow down results quickly.

In Outlook 2010, you will see a list beneath the search box when you begin a query. You can just type and then arrorw down to limit your search to mail from someone or with a specific subject. The results returned will be only those that show a match in the name (or subject) fields against your query!

This is just a taste of the new powerful search capabilities built into Outlook 2010. We hope you enjoy this new experience and that it will help you be more productive each time you need to find a message in your mailbox.

Nelson Siu
Outlook Program Manager

By now you may have read or heard that the /PrepareDomain operation in the Exchange 2010 Release Candidate (RC) applies certain Access Control Entries (ACEs) on the AdminSDHolder object within Active Directory. In particular, /PrepareDomain grants the Exchange Windows Permissions universal security group (USG) the ability to modify the members attribute, the ability to change and reset passwords, and the ability to modify the permissions of any object protected by the AdminSDHolder role.

Note: For those unfamiliar with the AdminSDHolder role, it is a special role within Active Directory that evaluates, on an hourly basis, the Access Control List (ACL) of certain security groups and the members of those groups (known as protected groups, e.g., Enterprise Admins) and resets the ACL with specific ACEs if the ACL doesn't match the AdminSDHolder role ACL. For more information, please see http://support.microsoft.com/kb/232199 and http://support.microsoft.com/kb/318180.

By default, no user accounts are members of the Exchange Windows Permissions security group. In fact the only member of this group is the Exchange Trusted Subsystem security group, which contains only Exchange 2010 server computer objects. The majority of permissions applied within Active Directory via the Exchange 2010 RC Setup process are for these two security groups.

However, as a result of the ACEs applied on AdminSDHolder, a malicious administrator could elevate their privileges and thus gain control of the Active Directory forest. In particular, the malicious administrator must grant themselves membership in the Exchange Windows Permissions security group. A malicious administrator could either be a person that simply has local administrative rights to log on to an Exchange 2010 RC server, or be a person that is a member of the Exchange Organization Management role. Once the malicious administrator is a member of the Exchange Windows Permissions security group, the malicious administrator can elevate themselves to domain administrator or enterprise administrator.

In previous versions of Exchange we relied upon setting ACEs within Active Directory for administrators to be able to manage objects within the domain partition. Beginning with Exchange 2010, we are providing a new authorization layer inside of Exchange, known as Role Based Access Control (RBAC), instead of relying upon applying ACEs for every account that requires the appropriate permissions. Exchange administrators are granted the ability to perform certain operations within a specific scope through RBAC. The Exchange server, in turn, executes the authorized actions on behalf of the administrator or users via the permissions granted within Active Directory through the Exchange Windows Permissions and Exchange Trusted Subsystem security groups. For more information on RBAC, please see http://technet.microsoft.com/en-us/library/dd298183(EXCHG.149).aspx.

As its name implies, RBAC provides access to administrative functions via roles. Out of the box, Exchange 2010 ships with several default roles. In order to provide an Exchange administrator a holistic experience, roles like Organization Management and Recipient Management provide the ability to create accounts and to manage the mail-related and GAL-related properties of those accounts.

The ACEs being applied are at the domain partition level. However, groups and accounts that are protected via AdminSDHolder do not inherit permissions. Instead they receive their own defined set of permissions that are specified on the AdminSDHolder container within the domain partition. The same permissions that are applied to the domain partition are also currently applied to the AdminSDHolder container to allow customers to mail-enable protected accounts and manage them, should they wish to do so. However, as some have correctly pointed out, that enables an elevation of privilege scenario that is unacceptable in any environment.  Microsoft agrees with this assessment and concurs that Exchange 2010 cannot ship with the permissions assigned to the AdminSDHolder role that allow for Active Directory forest privilege elevation.  The Exchange Product Group has evaluated several ways to remove this privilege elevation scenario while still ensuring that we provide customers the flexibility they need to manage mail-enabled recipients within Active Directory.

To that end, the released to manufacturing (RTM) version of Exchange 2010 includes the following changes with respect to the ACEs applied by Exchange within the domain partition:

1. /PrepareDomain no longer applies ACEs granted to Exchange Windows Permissions USG on the AdminSDHolder container.  If /PrepareDomain detects the ACEs granted to Exchange Windows Permissions USG on the AdminSDHolder container, /PrepareDomain will remove them.
2. /PrepareDomain no longer applies the extended right ACE User-Change-Password to the Exchange Servers USG on the AdminSDHolder container.  If /PrepareDomain detects this ACE granted to Exchange Servers USG on the AdminSDHolder container, /PrepareDomain will remove it.
3. /PrepareDomain no longer applies the extended right ACE User-Change-Password to the Exchange Servers USG on the domain partition.  If /PrepareDomain detects this ACE granted to Exchange Servers USG on the domain partition, /PrepareDomain will remove it.
4. /PrepareDomain no longer applies an unscoped DeleteTree and WriteDACL ACEs on the domain partition.  Instead, these ACEs are replaced by scoping them specifically to user and inetOrgPerson class objects.

Due to the permission changes described above:

• Members of Exchange Windows Permissions USG will not be able to alter the membership of the Enterprise Admins or Domain Admins security groups.
• Members of Exchange Windows Permissions USG cannot change or force the password reset of an account protected by AdminSDHolder.
• The permission structure of any account or group protected by AdminSDHolder cannot be altered by members of Exchange Windows Permissions.
• Exchange administrators will not be able to create/delete AdminSDHolder protected accounts.

This change ensures parity with previous versions of Exchange Server which allows customers to mail-enable accounts protected by AdminSDHolder. Please note, however, that this is not a best practice and we do not recommend that you do so. Exchange, like Windows, recommends customers follow best practices and maintain separate accounts: one account for administration of Active Directory, and one account for regular day-to-day use (including email).

If you have any questions, please let us know.

- Ross Smith IV 

Share this post :

Many Exchange Server customers have reported issues logging on to Exchange using iPhone devices older than iPhone 3GS. iPhones support Exchange ActiveSync (EAS), the same protocol supported by Windows Mobile devices, and licensed by many other mobile device manufacturers.

Exchange Server 2007 SP1 and later support many additional policy settings. Two policy settings that are of interest here are:

1. Require device encryption: When you enable this policy, mailbox data synchronized and stored to a mobile device is encrypted.
   
   
   Fig 1: Exchange ActiveSync policy requiring device encryption
   
   
2. Allow Non Provisionable Devices: You can disable this setting (default) to prevent provisioning of devices that can't fully apply Exchange ActiveSync policies.

The iPhone 3GS supports device encryption, and is the first version to do so. Previous iPhone models, including the iPhone 3G, do not support device encryption. Additionally, before iPhone OS 3.1, these devices did not communicate their policy status correctly, resulting in the devices being able to connect to Exchange Server, even if your Exchange ActiveSync policy required device encryption and did not allow non-provisionable devices.

iPhone OS 3.1 correctly reports its policy status. As a result, if your policy requires device encryption and doesn't allow non provisionable devices, previous models of iPhone which don't support device encryption are prevented from accessing the mailbox.

After considering your organization's security policy, if you need to allow older iPhone devices to connect, you can modify the Exchange ActiveSync policy to either allow non provisionable devices, which will still enforce device encryption on devices that do support it, or you can disable device encryption. You can also create another policy which does not require device encryption, and apply it only to mailbox users with devices that do not support device encryption.

For more details about Exchange ActiveSync policies, see Understanding Exchange ActiveSync Mailbox Policies in Exchange 2007 documenation.

-Bharat Suneja