Tuesday, September 27, 2011

Changes to the distribution list membership cannot be saved


If you are in the middle of a migration from Exchange 2003/2007 to Exchange 2010 (or already finished) and your users are complaining that they can no longer manage distribution lists they own, please note that this is RBAC working as expected.

I will not go through the explanation of why and all the steps involved to fix it as that would be rewriting this excellent post: How to Manage Groups that I already own in Exchange 2010?

Just be aware of this before you actually start migrating users across!

Thursday, September 22, 2011

Exchange 2010 Calendar Repair Assistant Behaviour


After enabling the new Calendar Repair Assistant (CRA) in Exchange 2010, I got a complaint from a user saying items were being re-created on her calendar.

After some troubleshooting and a few tests, I realised that when a user accepts a meeting request and later on deletes it without sending an update, Exchange will put it back in the calendar. This is by design and as expected. According to Understanding Calendar Repair, one of the conflicts the CRA fixes is:

“An attendee accepted the organizer's meeting request or recurring meeting request, but the meeting isn't on the attendee's calendar.
The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response. If the assistant can't determine that the meeting item was intentionally deleted by the attendee, the assistant creates the meeting request again. If the assistant determines that the attendee intentionally deleted the meeting request, no further action is taken.”

Note that is says “The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response”. However, in all my tests, I deleted the appointments after accepting them, and Exchange always puts them back... So, not sure how it detects if the appointment was “intentionally deleted by the attendee”...


Update: Please check Part 2 regarding this issue!


After I deleted the appointment test03 – delete future recur meeting, Exchange put it back in my calendar the following day (I have CRA scheduled to run every night for all servers and users) and I received the following e-mail:




If we have a look at the CRA log for this instance:

<Meeting Subject="test03 - delete future recur meeting" MeetingType="Occurrence" StartTime="09/21/2011 15:00:00" EndTime="09/21/2011 15:30:00" Organizer="mizan.khan@parliament.uk">
      <InternetMessageId>&lt;63EB2801FB9F52428B3363279474E765A2FCF2@MMEM011.parliament.uk&gt;</InternetMessageId>
      <GlobalObjectId>040000008200E00074C5B7101A82E00807DB091520B3C92CAF77CC01000000000000000010000000547C7BEC0F87214789D7CF8FB5727D96</GlobalObjectId>
      <CleanGlobalObjectId>040000008200E00074C5B7101A82E0080000000020B3C92CAF77CC01000000000000000010000000547C7BEC0F87214789D7CF8FB5727D96</CleanGlobalObjectId>
      <OwnerAppointmentId>-189491237</OwnerAppointmentId>
      <Attendees>
        <Attendee EmailAddress="motan@parliament.uk">

          <ConsistencyChecks>

            <ConsistencyCheck Type="CanValidateOwnerCheck" Result="Passed">
              <Description>Checks whether the counterpart user can be validated or not.</Description>
            </ConsistencyCheck>

            <ConsistencyCheck Type="ValidateStoreObjectCheck" Result="Passed">
              <Description>Calls Validate() on the base calendar item.</Description>
            </ConsistencyCheck>

            <ConsistencyCheck Type="MeetingExistenceCheck" Result="Failed">
              <Description>Checkes whether the item can be found in the owner's calendar or not.</Description>
              <Inconsistencies>
                <Inconsistency Owner="Attendee" ShouldFix="True" Flag="MissingItem">
                  <Description>Could not find the matching meeting in attendee's calendar. Error: [21/09/2011 05:00:51(UTC)] FindMatchingItem: Could not find calendar item, exception = Microsoft.Exchange.Data.Storage.OccurrenceNotFoundException. </Description>
                </Inconsistency>
              </Inconsistencies>
            </ConsistencyCheck>
          </ConsistencyChecks>

          <RUMs>
            <RUM IsOccurrence="False" Type="Update" Sent="True" Time="09/21/2011 05:00:51">
              <Flags>
                <Flag>MissingItem</Flag>
              </Flags>
            </RUM>
          </RUMs>
        </Attendee>
      </Attendees>
</Meeting>


We can see all the tests CRA performs in between <ConsistencyChecks> and what it checks for (I have included some more that weren’t part of this check but that CRA normally checks as well):
  • CanValidateOwnerCheck - Checks whether the counterpart user can be validated or not;
  • ValidateStoreObjectCheck - Calls Validate() on the base calendar item;
  • MeetingExistenceCheck - Checke whether the item can be found in the owner's calendar or not;
  • MeetingCancellationCheck - Checks to make sure that the meeting cancellations statuses match;
  • TimeZoneMatchCheck - Checks to make sure that the attendee has correct recurring time zone information with the organizer;
  • MeetingPropertiesMatchCheck - Checks to make sure that the attendee has the correct critical properties for the meeting;
  • RecurrenceBlobsConsistentCheck - Checks to make sure that the recurrence blobs are internally consistent;
  • RecurrencesMatchCheck - Checks to make sure that the attendee has the correct recurrence pattern.



From the <Inconsistencies> section, we can see why Exchange put it back in my calendar:

<Inconsistency Owner="Attendee" ShouldFix="True" Flag="MissingItem">
    <Description>Could not find the matching meeting in attendee's calendar. Error: [21/09/2011 05:00:51(UTC)] FindMatchingItem: Could not find calendar item, exception = Microsoft.Exchange.Data.Storage.OccurrenceNotFoundException. </Description>
</Inconsistency>


Basically Exchange detected the meeting in the organizer’s calendar and that I had previously accepted it but it wasn’t in my calendar (because I deleted it without sending a notification)!
If, however, I had rejected it afterwards (or deleted and sent a notification) the organizer would have received a cancellation from me and Exchange wouldn’t check my calendar for that meeting.


To summarise, when a user receives an appointment and:
  • rejects it – Exchange doesn’t put it back;
  • accepts it, later on declines it - Exchange doesn’t put it back;
  • accepts it, later on deletes it and sends an update - Exchange doesn’t put it back;
  • accepts it, later on deletes it and doesn’t send an update - Exchange puts it back.
Update: Please check Part 2 regarding this last issue!

Hope this helps!

Wednesday, September 14, 2011

Exchange Server 2010 SP1 Help

A new version of the Exchange Server 2010 SP1 Help chm file has just been released last week!

Follow this link to download it.

Sunday, September 4, 2011

OWA 2010 cannot open 2007 mailbox


As you know, as long as you have the proper permissions you can access another users’ mailbox using OWA.
However, if you are in the middle of a migration from Exchange 2007 to 2010 and you have deployed Update Rollup 1 for Exchange 2007 Service Pack 3 you will find that a user in 2010 cannot open a 2007 mailbox even though he/she has Full Access permissions to it...

When I login to OWA using my Nuno account (in 2010) and try to open the Mota mailbox (in 2007) I get the following error:



This is because Rollup 1 introduces the following “fix”:
976100 - Shared calendar items are shown incorrectly in the server time zone instead of the time zone of an Exchange Server 2007 user who is accessing the shared calendar

“Consider the following scenario:
User A and User B are Exchange Server 2007 users;
User B shares a calendar with User A;
User B grants User A read access permission to the calendar;
User A accesses the shared calendar of User B by using Outlook Web Access (OWA).

In this scenario, the shared calendar items are shown in the time zone of the server instead of the time zone of User A. However, if User A has full access permission to the shared calendar of User B, the calendar items are shown in the time zone of User A.

This problem occurs because the time zone information is stored in a configuration message that is in the root of the mailbox. A user who does not have full access permission to a shared calendar, cannot access the time zone information. Therefore, the server time zone is used.”


After this Rollup is installed, you can control the time zone at the Organization level by running the Set-OrganizationalSetting cmdlet together with the SharedCalendarTimeZone parameter. Principal, Delegate and UserConfigured are the three values for the SharedCalendarTimeZone parameter which, by default, is set to UserConfigured.
If the parameter value is set to Principal, the time zone is shown in the principal’s time zone. If set to Delegate, the time zone is shown in the Delegate’s time zone. If set to UserConfigured, the user can follow these steps to change the time zone to the delegate’s time zone or to the principal’s time zone:
Log on to OWA, and navigate to the Options page;
Check the default value for the shared calendar time zone;
Select the value for the "When viewing a shared calendar, show items in:" drop-down list to Delegate Time Zone or to Principal Time Zone.

Note: when you configure the SharedCalendarTimeZone parameter to either Principal or to Delegate by using the Set-OrganizationalSetting cmdlet, the option to configure the time zone in OWA is disabled.


Resolution
To fix this issue, all you have to do is run the following command from a 2007 server to set the SharedCalendarTimeZone to Principal (which is the only option that fixes this issue):

Set-OrganizationalSetting –SharedCalendarTimeZone Principal

Note: Please test this change before deploying it to your live environment as it might confuse users if they are spread across different time zones!


Hope this helps!

Saturday, September 3, 2011

550 5.7.1 Submission has been disabled for this account


If you are migrating from Exchange 2007 to Exchange 2010 and 2007 users are getting the following error when e-mailing 2010 users:
   The following recipient(s) could not be reached:
   Nuno
   (…)
   nuno@letsexchange.com
   HTCAS1.letsexchange.com #550 5.7.1 Submission has been disabled for this account # #
   (…)


and you see the same error on the 2007 Transport Logs for that e-mail:
    Source:          SMTP
    EventID:         FAIL
    Recipients:      {nuno@letsexchange.com}
    RecipientStatus: {550 5.7.1 Submission has been disabled for this account}
    (...)


be aware that this is (most likely) due to a bug (not confirmed with Microsoft) with Exchange 2010...


If your 2007 users have the following set for their mailboxes:
    UseDatabaseQuotaDefaults: True
    ProhibitSendReceiveQuota: 0KB
    ProhibitSendQuota:        0KB


This is what’s causing the issue! Although they are still able to e-mail 2003 and 2007 users, they can’t send e-mails to 2010 users due to the way Exchange 2010 checks the user’s quotas, even though they are set to use the database defaults!...


To check if this has already happened to any of your users, run the following command to check your transport logs for the error message mentioned before:
Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "01/09/2011" -EventID FAIL | ? {$_.RecipientStatus -match "550 5.7.1 Submission"} | Select *, {$_.Recipients}, {$_.RecipientStatus} | Export-Csv D:\Nuno\550.csv -NoTypeInformation

To see if you have any users with 0KB quotas:
Get-Mailbox -ResultSize Unlimited -Filter {UseDatabaseQuotaDefaults -eq $True} | ? {$_.ProhibitSendReceiveQuota -eq 0KB -or $_.ProhibitSendQuota -eq 0KB} | Select Alias, ProhibitSendReceiveQuota, ProhibitSendQuota, UseDatabaseQuotaDefaults

and to correct them, run the following:
Get-Mailbox -ResultSize Unlimited -Filter {UseDatabaseQuotaDefaults -eq $True} | ? {$_.ProhibitSendReceiveQuota -eq 0KB -or $_.ProhibitSendQuota -eq 0KB} | Set-Mailbox -ProhibitSendQuota unlimited -ProhibitSendReceiveQuota unlimited


Note: 2010 users with 0KB quotas and using the database quota defaults are still able to e-mail 2010 and 2007 users!


Hope this helps!

“Insufficient access rights to perform the operation error” when moving mailbox to Exchange 2010

When moving mailboxes to Exchange 2010, you might come across the following error:


Or when using the EMS, you might find some move operations with a state of Failed or Queued for hours.

When you try to suspend/resume these queued move requests, you get a similar error:

[PS] C:\>Resume-MoveRequest "Nuno Mota"

Active Directory operation failed on dc1.letsexchange.com. This error is not retriable. Additional information: Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150A48, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
    + CategoryInfo          : NotSpecified: (0:Int32) [Resume-MoveRequest], ADOperationException
    + FullyQualifiedErrorId : 2851DFD3,Microsoft.Exchange.Management.RecipientTasks.ResumeMoveRequest


Since Exchange 2000 every version of Exchange has a massive dependency on Active Directory. What is happening here is that whenever a move request is issued, the Mailbox Replication Service (MRS) needs to update several attributes in the user object. These attributes are used by the MRS to keep track and report the progress of the move. Using ADSIEdit you can see all these attributes under msExchMailboxMove*:
   msExchMailboxMoveBatchName
   msExchMailboxMoveFlag
   msExchMailboxMoveRemoteHostName
   msExchMailboxMoveSourceMDBLink
   msExchMailboxMoveStatus
   msExchMailboxMoveTargetMDBLink

These attributes are populated when the move request is issued and cleared when the move request is deleted with the Remove-MoveRequest cmdlet (or from the EMC). Because the MRS needs to be able to update these AD fields, the move will fail if it can’t. And this is what is happening here.


So, all you have to do is fix the permissions for the affected user. To do this:
  1. go to Active Directory Users and Computers
  2. click on View and select Advanced Features (so you have access to the Security tab of AD objects)
  3. find the affected user, right-click on it and go to Properties
  4. Select the Security tab and then click on Advanced
  5. Tick the Include inheritable permissions from this object’s parent box
  6. Click OK

This should fix it! You can now suspend/resume the Queued move request or issue a new move request if the first one failed.


This seems to only affect highly privileged user objects that were created before the deployment of Exchange 2010. But why? Exchange 2010 system components are granted access to AD through the Exchange Trusted Subsystem, which has privileged and powerful access to AD. However, it can’t deal with cases where the Access Control Entries (ACEs) that Exchange depends on are not stamped into user objects. In these situations, any attempt by Exchange to update the object is declined by AD, like the problem with the Move Request.

Hope this helps!