RSS Subscription 168 Posts and 2,769 Comments

Archive for April, 2010

Exchange 2010 Databases and the RPCClientAccessServer Database Parameter

When you create an RPC Client Access Array AFTER you have created Exchange 2010 databases, you need to go back to those existing databases and stamp them with the RPC Client Access Array FQDN.  That way, clients will use that RPC Client Access Array.  Otherwise, they won’t.  On the other hand, if you create the RPC Client Access Array FQDN before you create your Exchange 2010 databases, nothing else is needed on your part.

There’s a bug with Outlook 2007 and Outlook 2010 that prevent the RPC Endpoint from updating.  This is similar to the bug in which Outlook 2007 will not update its Outlook Anywhere Endpoint which was fixed in Outlook 2010 Beta 2.  Because of this bug, it is very important that you get the RPCClientAccessServer database parameter configured correctly prior to moving users to Exchange 2010.  If you make this mistake and have the RPCClientAccessServer Database Parameter incorrectly and Outlook users are already hosted on Exchange 2010, once you modify the RPCClientAccessServer parameter for those clients, those clients can do an Outlook Profile Repair to get the updated change.  I will update this article in the future when this issue gets fixed.

So before you move users to Exchange 2010, please make sure that you either:

  1. Create the RPC Client Access Array before creating your databases OR
  2. Go back on the databases and stamp those databases by running the following command:
  3. Set-MailboxDatabase -Identity “DatabaseName” –RPCClientAccessServer array.domain.com

The reason why #1 works making #2 not necessary is the way Exchange assigns the RPC Client Access Array property to a database.  It does this in 3 different ways:

  1. If there is no RPC Client Access Array and you create the database on a server that hosts the MBX and CAS role, it will choose itself, always.
  2. If there is no RPC Client Access Array and you create the database on a server where the CAS and MBX are not collocated on the same server, it will randomly pick a CAS in the same site to set as the RPCClientAccessServer.
  3. If there is an RPC Client Access Array in that site, it will automatically set the FQDN of the CAS Array for the RPCClientAccessServer.

Autodiscover will see the database the user lives on and will assign the user’s Exchange Server (RPC Endpoint) to what the RPCClientAccessServer parameter is.  That is why it’s important to make sure this setting is right before a user is moved to Exchange 2010.

Share

Exchange 2010 SP1 Retention Policies

Exchange 2010 RTM introduced Retention Policies as the successor to the Message Records Management (MRM) technology introduced in Exchange 2007.  MRM was the successor to Mailbox Manager Policies in Exchange 2003.  Message Records Management is called MRM 1.0 and Retention Policies is being called MRM 2.0 for short. MRM 1.0 as well as MRM 2.0 are both available in Exchange 2010 but MRM 1.0 is being deprecated in Exchange 2010 SP1.

I won’t go into MRM 1.0 a whole lot but will show you the capabilities of Retention Policies in Exchange 2010, how it ties in with Outlook 2010, and how you can create Retention Policies via the Exchange Management Console in Exchange 2010 SP1.

Important: Please keep in mind that the screenshots below are not final as this article is based off of SP1 Beta software and may change by the time Exchange 2010 SP1 ships.

Retention Policy functionality

Default Policy Tag

A Default Policy Tag is the default Tag that is chosen for a Exchange specific folder such as Inbox, Calendar, Deleted Items, etc.  It affects all subfolders and subitems within that folder.  It is essentially the default policy/tag assigned to a specific folder. An example of a Default Policy Tag is when you enable a Personal Archive Mailbox for a user they are assigned a Default Policy Tag which says that all mailbox data will be moved to the archive after 2 years and it applies to all folders within an Exchange Mailbox.  Alternatively, you can also specify a specific part of the mailbox to be used for the Default Policy Tag instead (such as your Inbox, or Calendar, etc.)

Policy Tags

Policy Tags are the options available for a user to select on a Personal folder which are essentially any user created items which include a subfolder off of the Inbox, items created on your calendar, a user created task, and so on. This Policy Tag which is assigned to a Personal Folder is there to allow a user to override the Default Policy Tag.  It is essentially a way for a user to override the Default Policy (Default Policy Tag) set on a folder or a specific item or subfolder under the main folder that the Default Policy Tag is assigned to. So let’s say we enabled a Personal Archive Mailbox for a user and they have a Default Policy Tag for All Folders in a Mailbox for 2 years to be  pushed down to their Personal Archive Mailbox.  This Default Archive Policy also has a few Policy Tags that allow a user to select a folder or a specific item and choose the following options:

  • 1 year
  • 5 years
  • Never

By selecting 1 year, we are using the Retention Policy Tag that allows the user to select 1 year.  If we select User Folder Policy, we are essentially reverting back to the default setting which let’s the Default Policy Tag (2 years) to govern when that specific item gets moved to the archive.  So think of the Default Policy Tag as the default permission whereas a Policy Tag is a way for a user to override the Default Permission (the Default Policy Tag).

Retention Policy

A Retention Policy contains a Default Policy Tag and Policy Tags.  You assign this Retention Policy to a user.

A Walkthrough of Creating a Retention Policy in the Exchange Management Console

Microsoft is moving away from MRM 1.0.  In fact, in the Exchange 2010 SP1 Exchange Management Console, Managed Folders and Custom Managed Folders which were MRM 1.0 functionality has been removed.  The Exchange Management Shell still has MRM 1.0 functionality.  As you can see by the following image, there’s no Managed Folders or Custom Managed Folder tabs.  But, there is a Retention Policy Tags and a Retention Policies Tab.

The Scenario

Let’s say we have a MRM 1.0 policy that does the following: When an item is moved to Deleted Items, after 14 days it will be deleted with the ability to recover that deleted item.  In MRM 1.0 we couldn’t create any user configurable options.  But with Exchange 2010, we can use Policy Tags to allow our users to override the default we give them. We want to create a similar policy in Exchange 2010 SP1 (RTM did have Retention Policies but not the ability to create them in the Exchange Management Console).  We also want to take advantage of the Default Policy Tag to take care of the 14 day deletion but also provide additional Policy Tags to allow users to be able to choose a different time limit such as 7 days and 21 days.  Let’s go ahead and create a Default Policy Tag to Delete Items after 14 days.

So to recap the goals of our Retention Policy:

  • Default Policy Tag to delete all items in the Deleted Items folder after 14 days
  • Policy Tag to allow users to override the Default Policy Tag and be able to select 7 days for individual folders and/or items
  • Policy Tag to allow users to override the Default Policy Tag and be able to select 21 days for individual folders and/or items

So let’s create our first Retention Policy Tag which will become our Default Policy Tag because we are assigning it to a folder that Exchange creates, the Deleted Items folder.

We then want to allow the user the ability to select 7 days and 21 days. We will assign the Tag Type to Personal Folders which essentially makes it into a Policy Tag rather than a Default Policy Tag and will allow the users in Outlook 2010 to select 7 days or 21 days to override the Folder Policy (Default Policy Tag).

Let’s go ahead and create our 7 day Retention Tag.

Let’s go ahead and create our 21 day Retention Tag.

We can now see the Retention Tags and the Default Policy Tag.

So let’s go over to the Retention Policies Tab and create a new Retention Policy that includes all three of our Retention Policy Tags.

During the Policy creation we can specify mailboxes to associate the policy to; which I did.  After assigning the policy and running the Managed Folder Assistant (Start-ManagedFolderAssistant) to expedite the process of assigning the policy to the mailbox, I launched Outlook 2010 with this user’s account profile.

If we take a look at the Inbox Policy, it just says to use the Parent Policy.

But if we look at the Deleted Items Folder in which we created the Default Policy Tag for, we can see our Default Policy Tag at work.

Share

Exchange 2010 SP1 Personal Archive Mailboxes on Separate Databases

Exchange 2010 introduced the ability to move your personal archive mailbox to a separate mailbox database. This was a common request due to the limitations in Exchange 2010 RTM where the personal archive mailbox would be housed on the same database as the user mailbox.  This would of course limit the ability to use a tiered storage model.

In order to move the personal archive mailbox, we would need to ensure both the user mailbox as well as the archive mailbox are on SP1.  So if you are in a multi-server environment where some mailbox servers are RTM and SP1 and you have moved the user to SP1 and want to then split off the personal archive mailbox to a separate database, make sure that server that you move the personal archive mailbox to contains SP1. Should you decide to move the mailbox back to RTM, you must move both the user mailbox and the personal archive both to an RTM Server.

So let’s go through two scenarios.  The first, we will move an existing user’s personal archive to a separate database.  The second scenario we will create a new user with a personal archive and have the personal archive live on a separate database.

Important: Please keep in mind that the screenshots below SP1 Beta softwareand even the statement about Microsoft Support are not final as this article is based off of SP1 Beta software and may change by the time Exchange 2010 SP1 ships.

Scenario 1 – Moving an existing Personal Archive Mailbox to a Separate Database

So let’s take a look at a test mailbox I created, Frodo Baggins. We can see that both the user mailbox as well as the personal archive mailbox live on the same database.

So let’s move the personal archive to a separate database, MDB2.

To check the status of the Move Request, we can run the following command:

Now that we see the move has been Completed, we can check again to see what mailbox our user mailbox and our personal archive mailbox are located on. As you will see, our user mailbox and our personal archive will be housed on separate databases.

Let’s say we want to then move the Personal Archive Mailbox to MDB1.  But this time, let’s use the Exchange Management Console. We can see the existing database that both the User Mailbox and the Personal Archive Mailbox lives on.  We can also choose to move only the Personal Archive Mailbox.  We will choose MDB1.

We will then go ahead and verify again that the personal archive has successfully been moved to MDB1.

Scenario 2 – Creating a new User and separating their user mailbox and personal archive mailbox to separate databases

Microsoft has also updated the GUI so that when you create a new user, you can specify what database the user mailbox will live on as well as what database the personal archive mailbox will live on.  Let’s go ahead and create a new Active Directory user and assign this user an Exchange Mailbox as well as a Personal Archive Mailbox.

We will specify the User Mailbox to live on MDB3.

We will specify the Personal Archive Mailbox to live on MDB2 which is different from the User Mailbox which will live on MDB3.

We can then verify in the Exchange Management Shell to see if our User Mailbox is properly in MDB3 while our Personal Archive Mailbox is in MDB2.

A note about Microsoft Support

One important thing to note, is that in order to have support for personal archive mailboxes being on separate databases, both mailbox databases must be located within the same Active Directory Site.  The only time a personal archive will be supported on a database in a separate Active Directory Site is during a failover scenario where the database copy fails and activates on a separate server located in a separate Active Directory site.  But for normal operations, the user mailbox and personal archive mailbox database should be in the same Active Directory Site.

Share