Exchange 2010 SP1 Password Reset Tool

Now that SP1 for Exchange 2010 is released, it is time to start exploring some of the new features.  The first in line is the newly release password reset tool (this was also included in Exchange 2007 SP3). 

This has been a long awaited feature since OWA has been in use.  For users that primarily use OWA for email access or are primarily remote access users, administrators have always struggled with resetting user’s password that will force users to change at first logon.  Also users have struggled with remembering to reset their passwords through OWA before the password expired since their was no warning integrated with OWA.

The following is the setting within the user account that forces the user to change their password at next logon:

When a user tried to login to OWA with an expired password or configured to change their password at next logon, the user would see the following error: “The user name or password you entered isn’t correct. Try entering it again”

The Password Reset Tool feature is not active by default.  To activate this feature within Exchange 2010 SP1 (or Exchange 2007 SP3), all that is needed is one registry key:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Create DWORD: ChangeExpiredPasswordEnabled with value: 1

After creating the registry entry, an IISReset must be performed.  Now under the same scenario, if a user is configured to change their password at next logon or if their password has expired, the user will see the new message: “Your password has expired and you need to change it before you sign in to Outlook Web App.”

Now the user can change their password before logging into OWA:

But that is not all…If a user’s password is set to expire within 14 days, a user will see a warning while they are logged into OWA and will have the option to reset their password:

I think we can all agree that this is a much anticipated feature that has been missing since the inception of OWA!

Exchange 2010 SP1 released!

After months of anticipation and beta testing, SP1 has released and you can get it HERE!
Here are some additional links:

• For a list of “What’s New” in SP1
• Please see the required Windows Server hotfixes and system prerequisites for installing SP1.
• Release Notes for SP1
• SP1 UM Language Packs

Also note that SP1 can be installed as a new installation.  No need to install RTM before installing SP1.

Real Cisco Unified Communications

I originally saw this video posted on VoIPNorm’s blog.  It was just too good not to repost.

Click Here if you can’t see the embedded video in your browser.

Exchange 2010: “Insufficient access rights to perform the operation”

Have you see this error yet?  If you haven’t, you will.  This is one of the most common errors and can be seen while performing a variety of functions within Exchange 2010.  I continue to see this issue pop up so I decided to write a post on it.  Most recently I saw this while trying to attach a disconnected mailbox to an existing AD user account.  I have seen this same error pop up during the following functions (not full list):

• Reconnect mailbox
• Move mailbox to another database    
• Enable user for Unified Messaging
• Creating an Outlook profile

Here is the exact message:

“Active Directory operation failed on SERVERNAME.  This error is not retriable.  Additional information: Insufficient access rights to perform the operation…..The user has insufficient access rights.”

And on a database move operation:

How can this be?  I am a Domain Administrator and an Exchange Organization Administrator.  How is it that I do not have the right access?  Well, it is not that you do not have the right access on the object, it is that Exchange does not have the right access on the object.

So how do we solve this issue?  It is actually quite simple.  If we open up AD Users and Computers and take a look at the object’s security, we will find that Exchange does not have the proper access.

After opening AD Users and Computers, make sure that “Advanced Features” is selected in the menu.  This will enable the Security tab on AD objects.

Open the user’s AD object and select the Security tab.  This will show the current security configuration on the object. 

If we examine the list and compare to a user that does work properly we will notice that certain Exchange permissions are either missing or different.  In order to fix this, click on the Advanced button.  Then select the check box that reads “Include inheritable permissions from this object’s parent”.

That’s it!  Exchange needs specific rights on AD objects that it manages.  If it doesn’t, then all sorts of issues will arise.  Not only does this check box need to be checked for the user object, but also for the OU container that holds the object.

Using Retention Policies in Exchange 2010

Since a lot of folks are now taking the upgrade plunge to Exchange 2010, I have decided to write a series of posts on creating/replacing “like for like” functionality from Exchange 2003 to 2010. 

Managing mailbox sizes were a big part of Exchange 2003 since performance and capacity were at a premium.  Because of this, a lot of companies implemented Mailbox Management Recipient Policies.  Of course these no longer exist in Exchange 2010, so how do we handle that scenario now?  Before we get into that, let’s take a look at what tools were used in regards to mailbox management over the last few versions of Exchange.

As I just mentioned, Exchange 2003 utilized Recipient Policies to create Mailbox Manager settings.  The following screenshot shows a typical policy that would delete items in the Deleted Items and Sent Items folder that are older than 90 days.

Exchange 2007 does not support the old Exchange 2003 Recipient Policies and introduced Managed Folders.  This worked great as a replacement, but proved to be inflexible.  With Managed Folders, you can specify retention settings for default folders such as Inbox, Deleted Items, and Sent Items, or create custom managed folders with their own retention settings.  Managed folders rely on users to classify messages for retention and move the messages to the appropriate managed folders based on retention requirements.

Exchange 2010 still supports Managed Folders for backward compatibility, but is moving toward Retention Policies as a replacement.  Right now Managed Folders can be found in the EMC and Retention Policies must be managed via the command shell, EMS.  When Exchange 2010 SP1 rolls out, this behavior will flip-flop and Retention Policies will be available in the EMC and Managed Folders will only be available through the EMS.  So my advice is to start using Retention Policies for all mailbox management needs going forward.

The idea of this post is to not go into every detail about retention policies, but to show you how to handle replacing your old Exchange 2003 recipient policies with retention policies.  Retention policies are very powerful and more information can be found HERE.

Step 1 – Create Retention Tags

Retention Tags are used to apply retention settings to messages and folders in Exchange 2010.  In our example, we will create two Retention Tags: Delete items older than 90 days for the Deleted Items folder and Delete items older than 90 days for the Sent Items folder.  The following are the commands that we will run.  The output of the Retention Tag for the Deleted Items folder is shown.

New-RetentionPolicyTag “AllUsers-DeletedItems” –Type DeletedItems –Comment “Items older than 90 days are deleted” –RetentionEnabled $true –AgeLimitForRetention 90 –RetentionAction PermanentlyDelete

New-RetentionPolicyTag “AllUsers-SentItems” –Type SentItems –Comment “Items older than 90 days are deleted” –RetentionEnabled $true –AgeLimitForRetention 90 –RetentionAction PermanentlyDelete

Step 2 – Create Retention Policies

Retention policies are used to group together Retention Tags that can be applied to mailboxes.  In our example, we will create a retention policy by running the following command from EMS:

New-RetentionPolicy “AllUsersPolicy” –RetentionPolicyTagLinks “AllUsers-DeletedItems”,”AllUsers-SentItems”

Step 3 – Apply Retention Policies

Retention policies are applied to mailbox users.  Different sets of users can have different retention policies.  In our example, we will apply the “AllUsersPolicy” to a single mailbox.  I have also included some additional commands to show applying the retention policy to all members of a distribution group or a database.  The following EMS commands will apply the “AllUsersPolicy” retention policy:

Set-Mailbox –Identity TestUser1 –RetentionPolicy “AllUsersPolicy”

Get-DistributionGroupMember –Identity "DG-Finance" | Set-Mailbox –RetentionPolicy "AllUsersPolicy"

Get-Mailbox –Database “DatabaseName” | Set-Mailbox –RetentionPolicy “AllUsersPolicy”

Step 4 – Managed Folder Assistant Runs

The Managed Folder Assistant is a process that runs on all Mailbox servers.  During this nightly job, the mailboxes are processed, retention settings are applied, and specific retention actions are taken.  If you are like me and want instant gratification, you can manually kick off the Manage Folder Assistant by running the following command from EMS:

Start-ManagedFolderAssistant

Step 5 – Mailbox Processed

After the mailbox has been processed by the Managed Folder Assistant, retention settings can be viewed within Outlook 2010 and OWA 2010.

And there you have it!  As mentioned earlier, Exchange 2010 SP1 will bring managing Retention Policies to the EMC.  Here is a screenshot:

User Message Delivery Reports in Exchange 2010

In my last post, I discussed a current bug in the Exchange 2010 transport layer that disabled correct read receipt processing.  So I was wondering if there was any other way to handle this situation.  That pointed me to a new feature in Exchange 2010 that enables users to perform message tracking on their own to gather basic information.

End user message tracking is built into Exchange 2010 and the Outlook and OWA 2010 clients.  Actually, all message tracking is viewed through the Exchange Control Panel (ECP) which is a website hosted on the CAS server.  If a user opens OWA and selects Options, the ECP is opened.  On the Organize E-Mail node, the Delivery Reports tab can be selected.

To view Delivery Reports of a specific message from Outlook 2010, open the Sent Item, click on File from the menu and select Open Delivery Report:

To view Delivery Reports of a specific message from OWA 2010, navigate to Sent Items, right-click on message and select Open Delivery Report:

Once Open Delivery Report is selected the ECP will launch and take you directly to the Delivery Report for that message.  The user will have to log in just as if they were logging into OWA.

From this view the user can see if their message was successfully delivered or not.  Now this really doesn’t help out the read receipt issue as we have discussed before.  Note that delivery and read tracking status is not tied to email delivery and read receipts in any way.  This information is available whether or not the sender selects delivery/read receipt or not when creating the email. 

Read tracking status is disabled by default and can be enabled by running the following command:

Set-OrganizationConfig –ReadTrackingEnabled $true

This will enable read status tracking for everyone in the organization.  If this is unacceptable for a few users, those specific users can be disabled individually for read status tracking by running the following command:

Set-Mailbox “user” –MessageTrackingReadStatusEnabled $false

Now when we select Open Delivery Report, the following is shown.  Now we can tell that the message has been delivered, but has not been read:

Once the other user reads the email, the information in the Delivery Report is updated:

So what happens when the message is deleted?  The following status will be displayed:

These reports are quite useful and hopefully can help fill the gap in the read receipt processing issue that is currently in Exchange 2010.

BUG: Exchange 2010 Read Receipt Processing

It was recently brought to my attention by a client that was just migrated to Exchange 2010 that their read receipts were not processing correctly.  I decided to reproduce this issue, and sure enough I had the same problem.  The reason I say this is a bug with Exchange 2010 is that I have tested this scenario on Exchange 2003, Exchange 2010 (with RU4), and Exchange 2010 SP1 Beta.  I have also tested with Outlook 2007 and 2010 clients. 

This issue is common to email that flows through an Exchange 2010 HUB server, regardless of what Outlook client is used.  If the mailboxes are homed on Exchange 2010 SP1 Beta and the email flows through an Exchange 2010 (with RU4) HUB server, this issue persist.  If the mailboxes are homed on Exchange 2010 (with RU4) and the email only flows through an Exchange 2010 SP1 Beta HUB server, the receipts are processed normally.  Now let’s look at the issue in detail.

When sending an email, a user has the option to request a delivery receipt and a read receipt.

After the delivery and read receipt appear in my Inbox, I should be able to go look at the original message in the Sent Items and view the tracking information.

Expected behavior and what we see with Exchange 2003 mailboxes: Behavior with Exchange 2010 mailboxes:

So how does this tracking information get tracked and processed by Exchange?  When a user tags the original message to request a delivery and read receipt, a property tag gets attached to the message: PR_REPORT_TAG.  This property tag is used to match the original message and the receipts and update the tracking information in Outlook and should exist in all related messages (original, delivery receipts, and read receipts).  We can use a tool like MFCMAPI, to view the properties of the different messages.

Original message:

Delivery receipt:

Read receipt:

Just so that you believe me that property tag should exist in the Read receipt, here is the property view from the Exchange 2003 read receipt:

Read receipts are generated by Exchange and for some reason the Exchange 2010 HUB is removing the PR_REPORT_TAG property from the read receipt during transport.  Again, if the PR_REPORT_TAG is not in the message, it will not update the tracking information in the original message.  The tag must be present and the value match between all of the related messages.

Note: Again, I have tested this scenario on Exchange 2010 SP1 Beta and it works as expected.  Not sure if Microsoft will release a patch for Exchange 2010.

I will talk about a “workaround” in by next blog post about end-user Message Tracking and Delivery Reports.