Exchange Server 2010 SP2 and Support for Hosting Exchange


With the release of Exchange Server 2010 SP2 later this year, we will add a new feature known as Address Book Policies. Following this addition, hosters who wish to deploy the standard on-premises configuration of Exchange and use ABP will be supported.

As you may have read in a recent post over on the Exchange Partner Marketing blog, our view on whether to host Exchange using Hosting Mode or the standard on-premises configuration is changing in response to feedback we’ve had from both hosters and customers. We recognize that the Hosting Mode configuration of Exchange we released as part of SP1 provides a more robust multi-tenant solution, but lacks some of the features available in the standard on-premises configuration. Many of these are key features which customers are asking for, like Exchange Unified Messaging. We want to enable our hosting partners to offer the same rich feature set that our on-premises customers are used to. As such, with the release of SP2 for Exchange Server 2010, we intend to broaden our support stance to include hosting the on-premises configuration of Exchange in a multi-tenant environment.

To be eligible for support, hosters will need to adhere to a few configuration guidelines; a framework we will publish in conjunction with SP2. The framework will outline the configuration challenges of hosting Exchange in a multi-tenant environment which need to be solved, and provide general direction for developing solutions in the most supportable way. Let’s consider a couple of examples:

  • As I mentioned earlier, the Address Book Policy feature is a key reason that we will be able to support hosters using the on-premises configuration if they are using SP2. The framework will specify that directory segmentation should be done using Address Book Policies, not by a series of Allow/Deny ACE’s on Address List objects.
  • For provisioning, the framework will specify that the creation of objects (such as a tenant organization or a mailbox) in Active Directory and Exchange should use our standard built-in tools, PowerShell cmdlets, and documented APIs. Code should not be written to create objects directly in Active Directory or Exchange, bypassing these standard tools.

An automation vendor or a hoster, should they choose to, will be able to build their own automation tools using this framework. The easiest and quickest route to support for most hosters, though, will likely be through engaging with a hosting automation vendor whose solution adheres to the guidelines. In order to help service providers quickly find the right automation software, in the SP2 timeframe we will publish a list of solutions which follow the framework (and thus are eligible for support). These solutions will be validated by Microsoft in much the same way that we currently validate load balancing solutions. I’ll hasten to add that this will not be a formal certification process, but instead will be an assurance to our customers that we have worked with the vendor and are satisfied that it conforms to the framework.

So, what does this mean for you today if you want to use the on-premises configuration of Exchange to host mailboxes for your customers in a multi-tenant environment?

  • If you need to deploy prior to SP2, we recommend that you work with an automation vendor and use their solution. Your vendor of choice will be your only source of support. Your vendor will hopefully have plans to update their solution for SP2 per the soon-to-be-published framework, at which time you will have a path to being supported by Microsoft once you’ve upgraded your infrastructure.
  • If you plan to deploy post SP2, and you intend to use an automation solution from an automation vendor, you should ensure your chosen vendor is working with us to validate their solution and deploy when that solution is ready.
  • If you plan on building your own solution using the standard on-premises configuration of Exchange, you should consider waiting for SP2 to ship and then develop your solution following the framework to ensure you receive the best level of support from Microsoft.

We hope this announcement is good news for those hosting Exchange, as it provides you with more options in your deployment and will help you obtain support when you need it.

We look forward to hearing your feedback and as you know, we do act on it.

Source: MSExchange Team

Exchange Server Deployment Assistant now includes a “Cloud Only” scenario


For many companies, the robust messaging and calendaring features offered by Office 365 for enterprises presents an opportunity to transition all messaging functionality from the on-premises organization into the cloud. Office 365 for enterprises includes a full suite of e-mail migration tools.

However, there are dependencies and restrictions on the migration tools that you may be able to use with Office 365. Variables such as your on-premises Exchange Server version, the number of mailboxes you want to move, and how you want to handle user identity will dictate the tools and processes you can use to migrate to the cloud.

Screenshot: Cloud-only scenario in Deployment Assistant
Figure 1 : A screen shot from the new "Cloud Only" scenario in the Deployment Assistant

To help you sort through the available options and plan your migration to the cloud, we’re happy to announce the “Cloud Only” option in the latest release of the Exchange Server Deployment Assistant. Like the other scenarios in the Deployment Assistant, the “Cloud Only” option allows you to step through a wizard that asks you questions about your current infrastructure and your migration goals. The Deployment Assistant will provide a migration solution that is based on your answers.

Your feedback is very important for the continued improvement of this tool. Give us your feedback on this new scenario and any other area of the Deployment Assistant. Feel free to post comments on this blog post, provide feedback in the Office 365 community migration and coexistence forum, or send an email to edafdbk@microsoft.com via the ‘Feedback’ link located in the header of every page of the Deployment Assistant.

Source: MSExchange Team

Prevent archiving of items in a default folder in Exchange 2010


In Exchange 2010, you can use Retention Policies to manage message retention. Retention Policies consist of delete tags, i.e. retention tags with either Delete and Allow Recovery or Permanently Delete actions, or archive tags, i.e. retention tags with the Move To Archive action, which move items to the user’s archive mailbox.

Depending on how they’re applied to mailbox items, retention tags are categorized as the following three types:

  1. Default Policy Tags (DPTs), which apply to untagged items in the mailbox – untagged items being items that don’t have a retention tag applied directly or by inheritance from parent folder. You can create three types of DPTs: an archive DPT, a delete DPT and a DPT for voicemail messages.
  2. Retention Policy Tags (RPTs), which are retention tags with a delete action, created for default folders such as Inbox and Deleted Items. Not all default folders are supported. You can find a table showing the default folders supported for RPTs in Understanding Retention Tags and Retention Policies. Notably, Calendar, Tasks and Contacts folders aren’t supported.
  3. Personal Tags, which are retention tags that users can apply to items and folders in Outlook 2010 and Outlook Web App. Personal tags can either be delete tags or archive tags. They’re surfaced in Outlook 2010 and OWA as Retention policies and Archive policies.

To deploy retention tags, you add them to a retention policy and apply the policy to mailbox users.

In Exchange 2010 SP1, we added support for the Notes folder. In Exchange 2010 RTM, items in the Notes folder aren’t processed. After you upgrade to SP1, if the user’s retention policy doesn’t have a RPT for the Notes folder, the DPT from the user’s policy will apply to items in that folder.

In existing deployments, your users may not be used to their notes being moved or deleted.

To prevent the DPT from being applied to a default folder, you can create a disabled RPT for that folder (or disable any existing RPT for that folder). The Managed Folder Assistant, a mailbox assistant that processes mailbox items and applies retention policies, does not apply the retention action of a disabled tag. Since the item/folder still has a tag, it’s not considered untagged and the DPT isn’t applied to it.

Screenshot: Creating a disabled retention policy tag for the Notes folder
Figure 1: Create a disabled Retention Policy Tag for the Notes default folder to prevent the Default Policy Tag from being applied to items in that folder

Note: You can create a disabled RPT for any supported default folder.

Why are items in the Notes folder still archived?

If you create a disabled RPT for the Notes folder, you’ll see items in that folder are not deleted, but they do continue to be moved to the archive! Why does this happen? How do you prevent it?

It’s important to understand that:

  • A retention policy can have a DPT to archive items and a DPT to delete items. Both apply to untagged items.
  • The move and delete actions are exclusive of each other. Mailbox folders and messages can have both types of tags applied – an archive tag and a delete tag. It’s not an either/or proposition.
  • If you create a disabled RPT for the Notes folder to not delete items, the archive DPT for the mailbox would still apply and move items.
  • When it comes to archiving, there’s only one archive policy that administrators can enforce – the DPT with ‘Move to archive’ action. You can’t create a RPT with the ‘Move to archive’ action. This rules out using the disabled RPT approach to prevent items from being moved.
  • Users can apply a personal tag to a folder or messages to move items sooner or later than the default archive policy for that mailbox.
How do you prevent items in a default folder from being archived?

There’s no admin-controlled way of doing this, short of removing the archive DPT from a retention policy. However, removing the archive DPT would result in messages not moving to archive automatically unless the user applies a personal tag to messages or folders.

The workaround is to have users apply the Personal never move to archive personal tag (displayed as Never under Archive Policy in Outlook/OWA) to a default folder. The tag is included in the Default Archive and Retention Policy created by Exchange Setup. You can also add this tag to any Retention Policies you create.

Screenshot: Applying Never archive policy to a folder in Outlook 2010
Figure 2: Users can apply the Never archive policy to a default folder to prevent items in that folder from being archived

Note: You can’t use Outlook 2010 to apply an archive policy to the Notes default folder or individual notes items. Users wanting to apply an archive policy to the folder must use OWA.

Source: MSExchange Team

OFFICE 365 SEMINAR


Office 365 builds on Microsoft’s strong foundation with their Business Productivity Online Suite (BPOS) and is much more than an upgrade. It’s a new approach to Cloud applications altogether. It brings Office desktop software and Office Web Apps to Microsoft’s business Cloud services for the first time, and it introduces a variety of new packages designed to meet the needs of organization’s of all sizes.

This seminar will give you an introduction to Microsoft’s Cloud solution with Office 365. It is designed to ensure customers have the information they need to make their transition to the Cloud and get the most from Office 365’s significant new capabilities.

OFFICE 365 SEMINAR

Exchange Server and SP1 for Microsoft Office Filter Pack 2010


Starting with Exchange 2007, installation of the current version of Office Filter Packs is a prerequisite. For Exchange 2007 and Exchange 2010 RTM, the pre-req was 2007 Office System Converter: Microsoft Filter Pack. In Exchange 2010 SP1, this was updated to Office 2010 Filter Packs. The filters are used by Exchange Search to index email attachments on Mailbox servers and by the transport rules agent to scan attachments on transport servers. The filters are also important for discovery searches in Exchange 2010 – Multi-Mailbox Search uses content indexes generated by Exchange Search.

In Exchange 2010 RTM and Exchange 2007, you need to register the IFilters with Exchange Search (for Exchange 2007, see ‘KB 944516 How to register Filter Pack IFilters with Exchange Server 2007′). In Exchange 2010 SP1, IFilters included in the Office 2010 Filter Pack are automatically registered by Exchange Setup. You must register any third-party filters you install.

An updated filter pack, Service Pack 1 for Microsoft Office Filter Pack 2010 (KB2460041) 64-bit Edition is now available on Download Center. The Filter Pack has been tested with Exchange 2010 and Exchange 2007. The updated filter pack doesn’t have any fixes or updates that impact Exchange scenarios or functionality. If you have the RTM version of Office 2010 filter packs installed, you can update it but it’s not required. For new installs, we recommend going with the current versions.

Source: Bharat Suneja