Saturday, October 29, 2011

"Changes to the distribution list membership cannot be saved" - Part 2

One of my first posts was regarding Distribution Groups Managers, how they work and how to set them up both through Active Directory and through PowerShell.

Recently, I wrote another post regarding the “Changes to the distribution list membership cannot be saved” error that Exchange 2010 users might receive when trying to manage Distribution Lists (DLs).

In this new post, again about DLs, I will talk about another scenario where users are not able to manage their DLs even if you followed the instructions on the previous two posts and if you transitioned from an Exchange 2003 environment.


If you still have users experiencing the following error whenever they try to add or remove a member from a DL they manage, check if the DL’s scope is set to Global:


If you can’t remember what the differences are between Group Scopes, here’s a quick (and simplified!) overview:
  • Universal Group: can include accounts, global groups and universal groups from any domain of the same forest. Can be assigned permissions in any domain or forest;
  • Global Group: can include accounts and global groups from the same domain. Can be assigned permissions in any domain;
  • Domain Local: can include accounts, global groups and universal groups from the any domain (can also include other Domain Local groups but only from the same domain). Can be assigned permissions only in same domain.


If you look in the EMC, these DLs will most probably be greyed out and showing as Mail Non-Universal Group, which are not supported by Exchange 2010, thus causing the problem...


E-mails are still delivered to their members but you will not be able to manage or change them.

To check the Group Scope, the easier way is to use AD Users and Computers. In the following picture we can see that the DL HP-SSL-VPN is a Global DL:



To fix this issue, all you have to do is convert these DLs to Universal. You can easily do this using the EMC by sorting your DLs by Recipient Type Details, selecting the DLs you want to convert (you can select/convert multiple at a time!) and then clicking in Convert to Universal Group:



Alternatively, you can use PowerShell with the following cmdlet:
Import-Module ActiveDirectory
Get-ADGroup -Filter {(mail -like "*") -and (GroupScope -eq "Global")} | Set-ADGroup -GroupScope Universal -WhatIf

WARNING: Just make sure you want to convert all of them or update the cmdlet to only convert the ones you want to!



Exchange Server 2003
In the beginning of this post I mentioned that this might happen if you transitioned from Exchange 2003. This is because Exchange 2003 used different DL types.


To check the version of a DL, run the following cmdlet in the EMS:
Get-DistributionGroup HP-SSL-VPN | Select Name, ExchangeVersion

Name                   ExchangeVersion
----                   ---------------
HP-SSL-VPN             0.0 (6.5.6500.0)

From the output, we can see that the Exchange version of this DL is 6.5 (Exchange 2003).


You can use the same command to see the versions of all the DLs in your environment to check exactly how many you have that are still 2003 or, possibly, 2007:
Get-DistributionGroup | Select Name, ExchangeVersion | Sort ExchangeVersion


Or if you want to group and count them:
Get-DistributionGroup | Group ExchangeVersion

Count   Name
-----   ----
  207   0.0 (6.5.6500.0)
   12   0.10 (14.0.100.0)
   45   0.1 (8.0.535.0)



For these ones, if you try to add a Manager to it, you will get the following warning:



If you click Yes, Exchange will automatically convert the DL to Exchange 2010 so you can edit it.

The easiest way to convert all your DLs from Exchange 2003/2007 to Exchange 2010 is by using the 2010 EMS and simply running the following cmdlet:
Get-DistributionGroup | Set-DistributionGroup

Which will ask you the following:
To save changes on object "HP-SSL-VPN", the object must be upgraded to the current Exchange version. After the upgrade, this object cannot be managed by an earlier version of the Exchange Management Tools. Do you want to continue to upgrade and save the object?


Hope this helps!

Monday, October 10, 2011

Exchange 2010 Calendar Repair Assistant Behaviour (Part 2)


In my previous post Exchange 2010 Calendar Repair Assistant Behaviour I discussed some of the behaviour of the new Calendar Repair Assistant [CRA] functionality of Exchange 2010. Namely, I mentioned the following issue:

“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”...


What I forgot to mentioned is that this happened with Outlook 2007. When I tested the exact same scenario with Outlook 2010 and OWA 2010, this didn’t happen! Which means that the assistant does indeed check if the attendee deleted the appointment on purpose or not.   :)

So why does it work for Outlook 2010 and OWA 2010 but not for Outlook 2007? We all know Outlook 2010 has better integration with Exchange 2010, but I wanted to know. To try to find out why, I turned to MFCMapi and compared two appointments: one deleted in Outlook 2007 and one deleted in OWA 2010 (both without sending a notification to the organiser).

Besides some obvious differences in some properties such as subject, times, etc., here is the big difference (look at the value tags):


Outlook 2007
<property tag = "0x80630003" type = "PT_LONG">
      <ExactNames>0x80630003</ExactNames>
      <NamedPropGUID>{11000E07-B51B-40D6-AF21-CAA85EDAB1D0} = PSETID_CalendarAssistant</NamedPropGUID>
      <NamedPropName>id: 0x0015=21 = PidLidClientIntent, dispidClientIntent</NamedPropName>
      <Value>0</Value>
      <AltValue>0x0</AltValue>
</property>



OWA 2010
<property tag = "0x80630003" type = "PT_LONG">
      <ExactNames>0x80630003</ExactNames>
      <NamedPropGUID>{11000E07-B51B-40D6-AF21-CAA85EDAB1D0} = PSETID_CalendarAssistant</NamedPropGUID>
      <NamedPropName>id: 0x0015=21 = PidLidClientIntent, dispidClientIntent</NamedPropName>
      <Value>32</Value>
      <AltValue>0x20</AltValue>
</property>



The PidLidClientIntent property indicates what actions the user has taken on a Meeting object.

According to the MSDN website 2.2.2.4 PidLidClientIntentProperty a value of 0x20 (32 in decimal or 0010 0000 in binary) means that the ciDeletedWithNoResponse property is set which proves the user deleted the Meeting object with no response sent to the organiser.


So basically, OWA 2010 and Outlook 2010 set the PidLidClientIntent property correctly and, as such, the CRA knows that the user deleted the appointment on purpose and doesn’t put it back.
Because Outlook 2007 doesn’t set this property to 0x20, CRA doesn’t know the user deleted the appointment, thinks it’s missing for some other reason and puts it back in the calendar!

Now the question: is there or will there be an update to rectify this for Outlook 2007?


I’m running version 12.0.6550.5003 SP2 with the update KB2412171 to have access to my Exchange Archive.

For more information:

Thursday, October 6, 2011

Outlook 2007 Update for Exchange 2010 Personal Archive Support

I have used Outlook 2010 to play around with Exchange 2010 Personal Archives but never Outlook 2007.
As most of you know, Outlook 2007 doesn’t support these by default. However, an update released last January (KB2412171) brings archives to Outlook 2007! However, not completely so support is limited...

After you download and install the update (you don’t need to restart you PC, just close and reopen Outlook), your archive will appear automatically (please see note below) and you will be able to do the following:
  • Copy/move messages between your primary mailbox and your archive;
  • Copy/move messages between any PST open in Outlook and your archive.


NOTE: if you have full access permissions to another mailbox or archive, these will automatically show up in your Outlook view! This is known as auto-mapping in Outlook 2010 and uses the msExchDelegateListLink AD attribute together with AutoDiscover to achieve this.


However, here’s what you will not be able to do:
  • Search across your primary and archive mailboxes at once, only separately;
  • Use Personal Tags to override Retention and Archiving Policies set up, if any, on your Exchange 2010 environment.


As this update is now somewhat old, I was expecting for these 2 issues to have been already addressed in another hotfix. However, I was unable to find anything related to this... So, as far as I know, this is still the latest functionality available for Outlook 2007 users.

Don’t forget that the archive is only accessible when you are connected to Exchange as it is never cached locally even when on cached mode.