Introduction to Windows Azure Active Directory “Premium”

Windows Azure Active Directory (WAAD) “Premium” is a paid offering that unlocks additional features of WAAD. It is currently in preview and can be unlocked in the Azure Preview Portal.

[Update: WAAD reached General Availability on April 8, 2013 whereas WAAD Premium was available in Preview in December 2013, and GA sometime later [please post a comment if you have the GA release date of Premium]

WAAD Premium adds these features:

  • User self-service password reset –Give your end-users the ability to reset their password using the same sign in experience they have for Office 365.
    For more information, see Enable self-service password reset for users.
  • Group-based application access – Use groups to assign user access in bulk to SaaS applications. These groups can either be created solely in the cloud or you can leverage existing groups that have been synced in from your on-premises Active Directory.
    For more information, see Group management.
  • Company branding – Add your company logo and color schemes to your organization’s Sign In and Access Panel pages (including localized versions of the logo for different languages).
    For more information, see Add company branding to your Sign In and Access Panel pages.

    Additional security reports – View detailed security reports showing anomalies and inconsistent access patterns.

    Once you unlock this feature in the Preview Portal, then you sign into your Azure tenant and browse to the directory that you want to enable for Premium.

    image

    image

    This gives you the ability to customize branding. The branding is shown when users access webmail via outlook.com/contoso.com or mail.contoso.com. For more information on branding see Alex Simon post here: http://blogs.technet.com/b/ad/archive/2013/12/16/custom-branding-support-in-azure-ad-now-in-preview.aspx

    SNAGHTML6cee805

    Note: During the previous period, users will need to Opt-In by clicking on this link to view customized branding https://login.microsoftonline.com/optin.srf 

    The Advanced Reports seem like they would be relevant for most security administrators to review periodically.I predict what feature request is coming next: Alerting or scheduled emails of these reports =)

     

    image

     

    And it also unlocks the password reset feature. Right now this is an all or nothing toggle, however, the technet page for this feature says that the ability to enable this for specific users is coming soon.
    image 
    image 

     

    To perform a self-service password reset

    1. Go to a page that uses an organizational account. For example, go to portal.microsoftonline.com and click Can’t access your account link.
      image

    2. On the Reset your password page, enter the user ID and captcha
      image

    3. If the account is on-premise only (ADFS) then the following message will appear:
      image

    4. Otherwise, for cloud accounts then the user will receive notification.

    image

  • 802.1x Wireless Authentication differences in Windows 7 and Windows

    Rolling out WPA2/Enterprise and all Windows 8 clients could connect fine but Windows 7 clients could not connect. Client side errors in event viewer logged Event 8002 (Reason Code 16)  “authentication failed due to a user credentials mismatch” and on the Windows NPS Server Event 6273 “Authentication failed due to a user credentials mismatch.”

    Both errors are bogus because the username and password are correct.

    Client computers can be configured to validate server certificates by using the Validate server certificate option on the client computer or in Group Policy. If this box is unchecked, then Windows 8 clients honor that and they will not inspect the NPS server’s certificate. However, Windows 7 clients are either more strict or there is a bug because they will not authenticate if the subject name field is blank in the NPS server’s certificate, even if this check box is unchecked.

    The fix was to roll out the RAS and IAS Server template in Certificate Authority per this technet article: http://technet.microsoft.com/en-us/library/cc754198.aspx 

    This is because other certificate templates might get deployed that use Server authentication in the EKU which makes it seem like the cert should work fine for NPS but the problem is they may lack a value in the subject name field of the certificate. This is what generates the bogus errors about username and password mismatch. It would have been nice if the errors had said “hey, the SSL cert on your server is missing a subject name. go fix that!”

    A few helpful netsh commands to troubleshoot wireless:

    netsh wlan show profiles

    netsh wlan show profile <profile name>

    netwsh wlan set tracing mode=yes   (try to reproduce the issue then issue the same statement with =no)  This will create a .CAB file with tons of good information, especially the report.html file inside the .CAB file

    How to Manage Azure with On-Premise Active Directory

    When you sign up with a Windows Azure account, by default it creates an instance of Active Directory that resides in Windows Azure only called Windows Azure Active Directory (WAAD).  This is the same exact infrastructure that underlies Office 365. This blog post describes how to change Azure to leverage your existing Office 365 WAAD Instance.  You can then take advantage of your existing DirSync and ADFS servers to sign into the Azure Management Portal rather than using a Microsoft Account (Formerly Windows Live ID).

    This is ideal for large enterprise customers who desire to have all authentication performed from Active Directory, so that if administrators leave the organization, they have one place to disable the account rather than multiple places.

    For a quick 10 minute video overview of how this works, I recommend watching ”What is Windows Azure Active Directory”

    The first step is to sign into the Windows Azure Management Portal:

    https://manage.windowsazure.com

    Then click on Active Directory from the left navigation menu,  and then click Add.

    SNAGHTML10bff2d

    You then choose ‘Use existing directory’

    image

    Then check the box ‘I am ready to be signed out now’

    image

    You will then be directed to a login page to sign in with your Office 365 organization ID (which should authenticate you with ADFS if you have that enabled).

    If you are managing your Windows Azure Subscription with a Microsoft Account (Formerly Windows Live ID) rather than an Organizational ID, then you will be prompted for confirmation that you are okay granting your Microsoft Account (Formerly Windows Live ID) with Organizational Admin rights over your Office 365 directory.

    The next step is to click on the Settings icon on the left navigation pane in the Azure Management Portal.

    image

    Then click on the subscription you want to change the directory to the new o365 WAAD directory.

    image

    You can then change the directory

    image

    Note: The behavior of this screen is a little different than what you may expect. For example, in the drop-down box I was expecting to see a list of all my directories and then I could select the one I wanted. Instead, it assumes you don’t want to select your existing directory and so that option won’t be listed.

    Adding an Administrator

    Adding an administrator is the same as before but now you have the option of selecting the Organizational ID as an option.

    SNAGHTML1a45539

    That’s it – you can now sign in using ADFS to manage Azure.

    Configuring Windows Azure Active Directory for 3rd Party Single Sign-On

    You can add 3rd party applications like Yammer, Twitter, Skype, etc to be enabled for Single Sign-On using WAAD integrated through your on-premises Active Directory. Users can access these applications through the new Azure Access Panel.

    Windows Azure AD supports two different modes for signing onto 3rd party applications:

    • Federation using standard protocols
    • Password-based single sign-on

    Federation-based single sign-on

    Configuring Federation-based single sign-on enables the users in your organization to be automatically signed in to a third-party SaaS application by Windows Azure AD using the user account information from Windows Azure AD. In this scenario, when you have already been logged into Windows Azure AD, and you want to access resources that are controlled by a third-party SaaS application, federation eliminates the need for a user to be re-authenticated. Federated SSO is available for end user browsers which support JavaScript and CSS.

    In this release of WAAD, the following applications support Federation-based SSO:

    Box

    Citrix GoToMeeting

    Google Apps

    Salesforce

    Workday

    Office 365 Exchange Online and SharePoint Online

    Password-based single sign-on

    Configuring password-based single sign-on enables the users in your organization to be automatically signed in to a third-party SaaS application by Windows Azure AD using the user account information from the third-party SaaS application. When you enable this feature, Windows Azure AD collects and securely stores the user account information and the related password.

    Password-based SSO relies on a browser extension to securely retrieve the application and user specific information from Windows Azure AD and apply it to the service. Most third-party SaaS applications that are supported by Windows Azure AD support this feature.

    For password-based SSO, the end user’s browsers can be:

    • IE 8, IE9 and IE10 on Windows 7 or later
    • Chrome on Windows 7 or later or MacOS X or later

      

    Testing out Yammer with Password-based single sign-on

    To try it out, I am going to add Yammer to the Active Directory applications. In this release of WAAD, Yammer only supports ‘Password-based single sign-on’ and not Federation-based SSO.


    Note: If you already have ADFS on-premise, that is the recommended SSO integration for Yammer, as that is a better end-user experience than Password-based SSO. For information on configuring Yammer with your on-premise ADFS, see the Yammer SSO Implementation guide here: http://success.yammer.com/wp-content/uploads/2012/06/SSO-Implementation-Guide.pdf 

      

    The first step is to add Yammer to my Applications. So within Azure, click on the Active Directory icon from the left navigation pane

    Then click on the Directory that you just added.

    Then click on the Applications tab

    Then click Add

    Select ‘Add an application for my organization to use’

    Click on the Social Category and select Yammer

    After adding Yammer, the next step is to assign which users will be assigned this application for SSO on their Access Panel.

    As of this writing I am not aware of any powershell cmdlets for automating the assignment of users to applications. I checked the WAAD Powershell reference, which is where I would have expected to find those commands. Please email me at Joe.Stocker AT CatapultSystems.com if you are aware of cmdlets to manage this and I will update this post. thanks!

    http://technet.microsoft.com/en-us/library/jj151815.aspx#BKMK_sso 

      

    After highlighting a user(s) click the Assign button at the bottom of the screen

    You will be prompted with an option of entering their Yammer credentials on their behalf. Otherwise the user will have the option of entering their password themselves later.

    Note: The Access Panel is a web-based portal that allows an end user with an organizational account in Windows Azure Active Directory to view and launch cloud-based applications to which they have been granted access by the Windows Azure AD administrator. For more information about the Access Panel see http://technet.microsoft.com/en-us/library/dn308586.aspx

    During the preview period for Access Panel, the following URL must be distributed to all users who will be signing into applications integrated with Windows Azure AD.

    https://account.activedirectory.windowsazure.com/applications

    For example, for my user account, I have access to Exchange Online, SharePoint Online and Yammer. Therefore I see all three applications on my Access Panel.

    I can then click on the settings icon in the bottom-right of Yammer to configure my current Yammer username and password.

    When clicking Update Credentials I am then prompted to install some software.

    This will prompt the user to download ‘Access Panel Extension.msi’ (1.53MB)

    You are then brought to a Post Installation screen to insure you enable the add-on when prompted.

    In my case, running Internet Explorer 11 on Windows 8.1, I had to manually enable the Add-on.

    Now when I go back to step 1 to store my Yammer credentials, it allows me to do so.

    Now when I click on the Yammer Icon, I am brought right into Yammer with no prompts.

      

    Note: If a user’s credentials change in a Password-based single sign-on application like Yammer, the user must update their credentials in the lower-right of the application tile, and select “update credentials” to re-enter the username and password for that application.

    The RMS Sharing Application (Preview) in 3 steps

    The RMS Sharing Application is now generally available (As of November 19th)! still in preview as of this writing but you can evaluate it now. It is expected to be released in Q4 2013.  It allows you to share any file on any computer or mobile device.

    This blog article walks you through the easy steps to get started with RMS Application Sharing.

    Step 1 – Browse to https://portal.aadrm.com

    After signing in with your existing Office 365 tenant username and password, you can then select the setup program to download based on the device type you want to install this application on.

    For this blog, I clicked on the Windows icon.

    This downloads a 50 MB zip file named “Microsoft Rights Management sharing application x64.zip”
    Simply unzip and run setup.exe, and step through a 1 step setup program to configure RMS Application Sharing.

    You must restart your computer after the installation before you can begin protecting content.

    The installation installs four components into Programs and Features.

    After a restart, you can now right-click on any file on your computer and either protect it in-place, or you can immediately share it with anyone [with a business email account].  Currently you can only share files with a business email account. Consumer email accounts should be available soon.
    http://technet.microsoft.com/en-us/dn467883

    For example, you can right-click on a PDF file and select ‘Share Protected’ from my Windows Explorer context window.

    This brings up the common API for Application Sharing that will be consistent on any computer or mobile device since it all connects through the same SDK.

    It then creates an email message with the file name appended with a .pfile extension.

    If you send a file that is not able to be opened with an application that is RMS aware, then the notification that the recipient receives is that they are essentially under the honor system. For example, Adobe Reader doesn’t have the ability to manage the rights that the sender of the file is requesting.

    So it seems that the potential of the new RMS capability is limited by the applications vendors that embrace and adopt the new RMS SDK. Right now that would be Microsoft Office 2010, 2013 and Foxit PDF Reader. The Foxit RMS Plug-in to the Foxit Enterprise Reader requires a paid license to integrate Foxit Enterprise Reader with AD RMS.
    http://officepreview.microsoft.com/en-us/sharepoint-help/sharepoint-compatible-pdf-readers-that-support-microsoft-information-rights-management-services-HA102925502.aspx

    Reference:

    http://blogs.technet.com/b/rms/archive/2013/08/29/the-new-microsoft-rms-is-live-in-preview.aspx

    Microsoft Information Protection Viewer User’s Guide
    http://go.microsoft.com/fwlink/?LinkId=302325

    Microsoft Information Protection Viewer Administrator’s Guide http://go.microsoft.com/fwlink/?LinkId=302329

    http://www.foxitsoftware.com/landingpage/2012/07/Reader-Ads-RMS/?action=success&language=en-us

    Enable AADRM in Exchange Online in 2 easy steps

    On November 5th, 2013 Microsoft announced the general availability of a hosted version (SaaS) of Rights Management, called Windows Azure AD Rights Management (AADRM).

    Azure RMS is now included in Office 365 E3, E4, A3, A4, plans, or you can purchase Azure RMS as a standalone subscription.

    To license a user for AADRM, just assign an Office 365 license as you would an Exchange Online license.

    I have previously written about the new AADRM in August, and I just finished a post about enabling it for SharePoint Online.

    In this post, I will show you how simple it is to enable AADRM for your Exchange Online tenant. It is assumed that IRM has been activated in your tenant, if not, follow the first step in the post referenced above for SharePoint Online.

    1. Connect to your Exchange Online account by using Windows PowerShell. View the reference links below if you need help with this step. Better yet, stop here if you are not sure how to do this step.

    2. Run the following commands to enable Rights Management within Exchange Online (Pre-requisite – Azure RMS Admin Tool)

     

    That’s it! IRM is now enabled for Exchange Online!

     

    Recommendation

    As a best practice, it is a good idea to run a get command before you run a set command so that you can validate that the set command made the change you wanted, and to have a reference in case  you need to roll back. Here are the results of the get command I ran for get-IRMConfiguration prior to running the set command.

    Before RMS is enabled, the Outlook Web App interface does not allow a user to protect content within OWA.

    After RMS is enabled through the powershell command above, the user who has been granted the RMS license through the o365 portal will now see the following within Outlook Web App. Note: This can take several hours before it will appear.

     

    Reference

    http://blogs.technet.com/b/rms/archive/2013/11/11/office-365-information-protection-using-azure-rights-management.aspx

    Introducing Windows Azure AD Rights Management (AADRM)

    Organizations that are interested in taking advantage of the Rights Management features available in volume licensed versions of Microsoft Office have a new deployment option available:

    Windows Azure AD Rights Management (AADRM).

    Release Date

    AADRM is already available through the Office 365 portal for organizations that are already using Online Services such as Exchange Online and SharePoint Online. The Office 365 E3 SKU is required, and the Office Professional Plus SKU must be used to right-protect content with RMS.

    AADRM “stand-alone” is expected to be generally available in the early fall of 2013 and will enable organizations to deploy a highly available RMS infrastructure without the infrastructure or implementation costs of standing it up on premise. It will feature a connector that allows you to connect it with on-premise Exchange and SharePoint servers even if you do not use any other Office 365 service.

    Pricing

    Pricing is set at $2/user/month for users who need the ability to protect content. It is free to view content that has been RMS protected.

    Features

    There are at least two major benefits that I can tell from AADRM:

    1) Organizational sharing is implied among all Office 365 tenants. If you use RMS to protect a document and you send it to another organization who also uses Office 365, they can view that document. This is an advantage over on-premise RMS which requires an ADFS trust.  Eventually, AADRM will allow you to share with Google IDs (CY14).

    2) At GA release in the fall of 2013, AADRM will allow for any type of document to be protected by RMS, not just Office documents.

    Limitations

    AADRM will not be a perfect fit for all organizations.

    1. Companies that still have Windows XP, Vista, or versions of Office prior to 2010 will need to use AD RMS on-premises and then perhaps migrate to Azure RMS later when their clients have been upgraded.
    2. AADRM is limited to two templates that cannot be customized (“Company Confidential” and “Company Confidential Read Only”). If you need to create custom templates, you need to deploy AD RMS on-premises.

    In any case, whether you deploy to the cloud or on-premise, all scenarios require a volume licensed copy of Office. The OEM SKU  (“professional”) that comes bundled from the hardware manufacturer cannot create RMS content.

    Mobile Client Support
    • Windows 7.5 and 8 devices natively support RMS
    • Android and iOS devices can support RMS through Nitrodesk Touchdown 7.3
    • Blackberry devices can view RMS content with RMS Viewer
    OSX Support

    Max OSX v10.5 (Leopard) or later and Office for Mac 2011 Volume License. Non-volume license copies can read RMS but cannot protect content.

    RMS Concepts

    http://blogs.technet.com/b/rms/archive/2012/04/16/ad-rms-infrastructure-concepts-part-1.aspx

    RMS Whitepaper (July 2013)

    http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-58-79-43/Microsoft-Rights-Management-_2D00_-English-_2800_July-2013_2900_.docx

    Azure RMS Pricing

    http://blogs.technet.com/b/rms/archive/2013/07/16/azure-rms-pricing-and-availability.aspx

    RMS Prerequisites

    http://technet.microsoft.com/en-us/library/dd772659(v=ws.10).aspx

    RMS Team Blog

    http://blogs.technet.com/b/rms/

    Azure RMS on Technet

    http://technet.microsoft.com/en-us/library/jj585024

    How RMS protects documents

    http://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-how-ad-rms-protects-and-consumes-documents.aspx

    RMS Best Practices Guide

    http://technet.microsoft.com/en-us/library/jj735304.aspx

    IRM Deployment Guide in Office for Mac 2011

    http://www.microsoft.com/en-us/download/details.aspx?id=20825

    RMS Forum

    http://social.technet.microsoft.com/Forums/en-us/rms/threads

    RMS Troubleshooting Guide

    http://social.technet.microsoft.com/wiki/contents/articles/13130.ad-rms-troubleshooting-guide.aspx

    Linux runs faster on Windows Azure than Amazon or Rackspace Openstack!

    I recently reviewed a detailed comparison of the top 5 IaaS cloud providers and it listed Windows Azure as having the best overall value (both in cost and performance).

    The interesting thing about the comparison is they used a benchmarking tool called Unixbench running on Ubuntu linux.

    The irony of a Linux distribution running better on a Windows cloud platform than Rackspace Openstack which itself uses linux is just too awesome not to highlight and draw attention to!!

    The full article is here and I highly recommend it.

    http://www.cloudspectator.com/cloud-server-performance-a-comparative-analysis-of-5-large-cloud-iaas-providers-3/

    Microsoft Office 365 Federation Metadata Update Automation Installation Tool

    What is the Microsoft Office 365 Federation Metadata Update Automation Installation Tool?

    This tool automates an otherwise manual process, which if not performed, would prevent all users from signing into Office 365 when the token signing certificate expires (once per year). This tool is a PowerShell script that creates a scheduled task to tell Office 365 to trust the self-signed certificate.
    Get the tool:
    http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc 

    [Update 2/15/2013]
    It turns out that it is still necessary to restart the internal ADFS service after the token signing certificate has been issued.

    Who needs the tool?

    All Office 365 customers that have implemented Single-Sign-On with ADFS 2.0 must update their token signing certificate every year otherwise users will be unable to sign in. They would all benefit from this tool, otherwise they have to predict when the cert expires, then follow a manual process to trust the new cert.

    What if the tool is not installed? What is the manual process?

    I welcome this tool. Last year, I blogged about the manual steps to predict when the token signing certificate must be installed.
    http://blogs.catapultsystems.com/IT/archive/2012/03/07/cannot-sign-on-to-office-365.aspx
    Fixing the problem is not too difficult, however, preventing the problem from occurring is actually somewhat confusing. So I highly recommend all customers to use this tool!
    If you do not want to run the tool, here is what you must do:

    1. Find out when your existing token signing cert will expire.

    2. Subtract 20 days from the expiration date.

    3. From that date, ADFS will automatically issue a new certificate that will co-exist with the primary certificate for 5 days (this is the default period, but it can be configured to be a longer period). At the end of that 5 day period, the new token signing certificate is made primary, and this actually disrupts service until someone takes manual action to run a PowerShell command to force Office 365 to trust the new cert. This is necessary because it is a self-signed certificate and therefore, o365 needs to be informed by someone (or an automated task) that the cert has changed. This is exactly what the tool above helps automate, so that if someone does not predict the date correctly, it will avoid an outage.

    For example, this is what you will see when you are in the 5 day period when the new cert has been automatically issued but it has not yet been made the primary cert. The old is ‘IsPrimary’ = True, and the new one is there but it is not yet the Primary.
    Launch Powershell.
    Type the following:
    Add-PSSnapin Microsoft.Adfs.PowerShell
    Get-ADFSCertificate –CertificateType token-signing

    What happens if I ignore the expiration date of the token signing cert?

    You’ll find out – your users will call you when they are unable to sign into Outlook, or Outlook Web Access. They will get an error “There was a problem accessing the site. Try to browse the site again.”

    What does the tool require?

    • You must make sure that you have installed the latest version of the Microsoft Online Services Module for Windows PowerShell
    • You need to have a functioning AD FS 2.0 Federation Service
    • You need to have access to Global Administrator credentials for your Office 365 tenant
    • You need to have at least one verified domain in the Office 365 tenant must be of type ‘Federated’
    • This tool must be executed on a writable Federation Server
    • The currently logged on user must be a member of the local Administrators group
    • The Microsoft Online Services Module for Windows PowerShell must be installed. You can download the module from http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx
    Running the tool

    After you download the tool (aka powershell script) onto your internal ADFS server, you need to right-click on it and unblock it. Otherwise you will get errors like “the script is not digitally signed. The script will not execute on the system.”

    Also, if you get an error that “Failed MSOL credential validation.” it is because you are running the script in the regular Windows Powershell or ADFS PowerShell module.  You need to make sure you run this in the window “Microsoft Online Services Module for Windows PowerShell” that looks like this on the desktop:

    Then just change directory to the location of where you saved the script and run the script.

    Verifying it worked

    Launch Task Scheduler. You will see the new task has been scheduled to run at midnight every day.

    Recommendation: Because the scheduled task will run under the account that you were logged in with, you will need to remember to update this scheduled task whenever you change your password, or run the tool with a service account with a non-expiring password (best bet!/recommended!). It would totally defeat the purpose of going to all this effort only to have the script not run when you are counting on it because the password was changed and the scheduled task failed.

    How to recover missing emails in Office 365

    When an email is deleted, where does it go? It goes to the Deleted Items folder.
    When the deleted items folder is emptied, where does it go? It goes to a hidden folder called deletions. The duration that deleted items remain in this folder is based on the deleted item retention settings configured for the mailbox database or the mailbox. By default, a Exchange 2010 mailbox database is configured to retain deleted items for 14 days, and the recoverable items warning quota and recoverable items quota are set to 20 gigabytes (GB) and 30 GB respectively. These are configurable settings with Exchange on-premise:
    http://technet.microsoft.com/en-us/library/ee364752.aspx
    With Exchange Online, Plan 2, you can increase this from 14 to 30 days. The Recoverable Items folder does not count against the user’s primary mailbox.
    http://jorgerdiaz.wordpress.com/2012/07/19/office-365-changes-legal-hold-and-single-item-recovery/
    Note: These items can still be recovered by the end-user by highlighting the folder and clicking ‘Recover Deleted Items.’

    When this recoverable items folder is purged, where do those emails go?
    It depends on whether single-item recovery has been enabled on the mailbox. When Single-item recovery is enabled on a mailbox and the recoverable items folder is emptied, these items remain in a hidden folder that the user cannot alter in any way: Recoverable Items\Purges.
    Two mechanisms can be used to configure Single Item Recovery in Exchange 2010:

    • rolling legal hold = Time limited safeguarding of data where the items are stored in the Recoverable Items folder based on a predefined retention period. In this case, the retention period is set per mailbox (or the mailbox database defaults will apply if a specific value is not set for the mailbox).
    • litigation hold = Unlimited safeguarding of data -where Items in the recovery folder will never be purged. Retention period and quota limitation set on a “litigation hold” mailbox will be ignored. This would ensure that deleted mailbox items and record changes won’t be purged.

    The following example assigns a 7 year rolling legal hold on a mailbox. It is important to note the mailbox won’t be on Legal Hold for 7 years, this is actually a tag stating any new message will be retained for 7 years once created or received by the mailbox. So a message that arrives on 2.6.2013 will be kept until 2.6.2020.

    Set-Mailbox –identity [email protected] –LitigationHoldEnabled $True –LitigationHoldDuration 2555

    With Single Item Recovery enabled, items will remain in the Recoverable Items\Purges folder even if the mailbox owner deletes items from their inbox, empties the Deleted Items folder and then purges the contents of the dumpster. These items can then be searched for by a compliance officer if required, as the items are both indexed and discoverable. Additionally, these items will move with the mailbox if the mailbox is moved to a different mailbox database.
    Why not always enable single item recovery?
    1. You need to make sure you plan for the additional disk space required. See this article for more information on planning for single item recovery.
    http://www.msexchange.org/articles-tutorials/exchange-server-2010/high-availability-recovery/single-item-recovery-part2.html

    2. You have to enable it on each individual mailbox, you can’t set a policy that says “all mailboxes will always have it enabled.” It would be awesome if newly created mailboxes could automatically be enabled for single item recovery, but that is not how Exchange currently works.

    But what if you want to move those items out of the Recoverable Items\Purges and back into the user’s mailbox?

    Recovering items from this hidden Purges folder can only be performed by an Exchange or Office 365 Administrator.
    There are three options for restoring items from the Purges folder. My favorite is Option 3 (MFCMAPI) because it can restore the items back to the user’s deleted items folder.

    Option 1: You can use powershell
    http://technet.microsoft.com/en-us/library/ff660637.aspx

    Option 2: You can use the Exchange Control Panel’s eDiscovery search
    Create an In-Place eDiscovery Search

    or

    Option 3: Use MFCMAPI

    Instructions for using MFCMAPI to restore items from the Purges folder.
    1. Download MFCMAPI (use this tool at your own risk!)

    http://mfcmapi.codeplex.com/releases/view/97321

    2. Follow the screen-shots on my older post that I have not yet migrated the pictures to this blog:

    http://blogs.catapultsystems.com/IT/archive/2013/02/06/how-to-recover-missing-emails-in-office-365.aspx

    Summary

    While this tool is very powerful, it can also be very destructive (just like Regedit) so this author is not responsible for any damages caused by misuse of this tool. This post is for educational purposes only, use at your own risk!

    References

    Achieving Immutability with Exchange Online and Exchange Server 2010
    History of MFCMAPI
    Additional things you can do with MFCMAPI