If you’ve read the Exchange Team Blog’s announcement for SP1 you may have noticed one of the new features mentioned that isn’t so widely publicised:
“On the client side features like auto mapping of shared mailboxes to user’s Outlook 2010 profiles will remove a support headache.”
As it’s one of my favourite new features and there’s not much documentation yet, I wanted to write a little more about the feature and demonstrate how it works in practice…
How it works
When you add full mailbox permissions on Exchange 2010 SP1 and SP2 to a new or existing shared mailbox that’s also on SP1, Exchange now updates an Active Directory attribute on the shared mailbox itself, named msExchDelegateListLink. This is a multi-value attribute containing a list of DNs (Distinguished Names) of the other mailboxes that have full access to the mailbox and should auto-map that mailbox:
![image[19]](https://i2.wp.com/www.stevieg.org/wp-content/uploads/image191.png "image[19]")
The next time Outlook 2010 or Outlook 2007 launches they searches for mailboxes that have the user’s mailbox DN listed and displays them below the user’s primary mailbox.
In previous versions this was accomplished by going to the user’s Exchange accounts settings, going to “More Settings”, choosing “Advanced” and entering the shared mailbox manually under “Open these additional mailboxes” as shown below.
For any organisation making use of a large number of shared mailboxes this is a bit of a pain as IT needs to both write documentation so users can do this themselves and in many cases do it for the user. The new feature simply removes this step.
The catch (!) is that just moving a shared mailbox to SP1 or upgrading isn’t enough to enable the feature. As it’s an extra attribute added at the same time as the permissions, you need to remove and re-add the permissions via the normal way (EMC or Powershell’s Remove-MailboxPermission/Add-MailboxPermission) to make this take effect, or do it yourself via ADSI scripting/AD Powershell (probably not very supported!).
Demonstration
Just to give you a quick demo of how simple this is, all you need to do is add permissions on the Shared Mailbox in the normal way:
Then on the client, close and open Outlook. The Shared Mailbox should show after a few seconds:
Yes, it’s really that simple. Simple enough that you might use it without even noticing and wonder how that shared mailbox got mapped in the first place.. But I think it’s definitely going to be a feature any IT department that routinely adds/removes permissions for mailboxes this way will appreciate.
Disabling the feature selectively
I’ve had a lot of comments from people who don’t want this to happen all the time. If this is you, the check out my other article Disable Exchange 2010 SP1′s Auto Shared Mailbox Mapping Feature.
Pingback: Office 365 – Exchange Online – Set Mailbox permissions | mavboss
Pingback: Outlook 2010 and auto adding mailboxes (but not removing them when it should) | LM Blog
Pingback: Outlook Mailbox Mapping | OutlookRecoveryGuide.org
Solution for me was very simple. Forget about the ADSI stuff. Just re-add the proxy mailbox that you can’t seem to get rid of.
-Go to outlook–>file–>account settings–>more setting and add.
-Once you add it, close the Outlook.
– Go exchange, remove your permission to the mailbox.
-Open Outlook, remove the mailbox by going to file-settings–>more settings–> remove
Kass,
The process that you describe here works perfectly and is very simple. THANK YOU!!!!
I do not really like to add every single user to a shared mailbox (I required a lot of them) and like to work with groups like we have done with Public Folders in past. But if I use a group the shared mailbox does not appear in Outlook!? Any idea how we are able to accomplish this automatic add/remove of mailboxes in Outlook with group memberships?
Hello, is there a way then ot make the primary mailbox hidden, so all that is left is the shared mailbox?
Pingback: Manage Distribution Groups by using PowerShell - My blog
Pingback: Mailbox Permissions - PowerShell commands - My blog
An article that actually describes the nuts and bolts of AutoDiscovery – this has helped me solve why some users didnt auto connect to shared mailboxes – but that leadds on to what is happening with our replication with AD / Exchange !!!?!?!
Thanks a lot, I was looking on how to disable autoMapping and found it in your other article.
Rosario
Surprised nobody has mentioned the fundamental stupidity of the function, Auto mapping is nice for normal user, but outlook client has to traverse EVERY mail enabled user in the domain to find the attribute on the TARGET mailbox. Absolutley stupid resource hungry process. What happens if there are 100 000 users, as in some education environments? The attribute, and search, should on the users own properties only. Guess developers have no real life experience. Bill please come back!
Yes, but wouldn’t that just be a one-time process?
Haha, yeah, that’s not how this works. At all.
First, Outlook has no clue about this attribute. It gets the list of linked mailboxes from the Autodiscover response. It does not go scouring through the AD for linked mailboxes.
The list in the Autodiscover response comes from one simple property on the mailbox: msExchDelegateListBL. The msExchDelegateListLink is a linked attribute. On the shared mailbox, it’s the “forward” link, and it links to the “backlink” attribute on the mailbox that has permissions to the shared mailbox. So, as soon as the link is populated on the shared mailbox, the backlink is populated automatically by the Active Directory. Thus, all Exchange has to do is read one property on the mailbox to find out all the mailboxes it needs to add to the Autodiscover response.
However, even if there was no backlink, this still wouldn’t be a particularly expensive operation. Exchange hammers AD all day long to resolve proxy addresses and other mailbox properties. In this situation, you could resolve all mailboxes with forward links to your mailbox with a simple LDAP query without even having a backlink:
(msExchDelegateListLink=DN of mailbox that’s logging on)
Since you’re querying a GC for a DN-linked value, this is not a very expensive query. You could even mark the attribute for indexing to make it super fast (like proxy address lookups).
Thus, this feature is not resource hungry at all, and even if there was no backlink, it still wouldn’t be resource hungry.
+1 Yep, as Bill says! Jonathan, you’ve got a little mixed up.
Refer http://technet.microsoft.com/en-us/library/hh529943(v=exchg.141).aspx, Microsoft acknowledges a performance hit.
The Attribute (MsExchDelegateListLink) is written on the GRANTING mailbox, so Autodiscovery (or any discovery process) has to parse EVERY User/Mailbox (Attribute) to find this.
“To accomplish this, Exchange populates the msExchDelegateListLink attribute in Active Directory to locate mailboxes for which the user has Full Access permission, and then provides this information to the Autodiscover service. Autodiscover then populates the AlternateMailbox attribute with the information necessary for Outlook to open the full access mailboxes”
As adding or removing values from MsExchDelegateListLink changes Outlooks behaviour on every launch, Autodiscovery is happening every time Outlook is opened. What I cannot find is where the attribute AlternateMailbox actually exists, do you know where it is Bill/Steve? This attribute must also be user specific.
The current environment I am working in has over 40,000 AD users (I have worked in bigger), so not trivial.
“In a single-domain forest, a global catalog server stores a full, writable replica of the domain and does not store any partial replica. A global catalog server in a single-domain forest functions in the same manner as a non-global-catalog server except for the processing of forest-wide searches”
Flat domain structure was recommended by Microsoft with the release of Server 2008, even the largest environments I have worked in now follow this. The fact the attribute is in the Global catalogue makes no difference?
The simple solution would be to write the attribute (and discover from) the Mailbox/user who is GRANTED rights, i.e. check 1 attribute regardless of environment size.
Outlook opening times is a common complaint I have from users (multiple environments), though load time seem to a be a bit random.
And Mark, no it is not a 1 time function, it is done every time Outlook opens (has to, to allow for changing permissions). Easy to test just by Writing the MsExchDelegateListLink attribute. Steve probably has a script that will do this (or would be easy to modify) or use ADSI edit.
The Attribute MsExchDelegateListLink has no effect on security or access, so if it is there Outlook will try to open the mailbox. It was quite common for the attribute not to be removed after removing permissions, or not to add the attribute when adding permissions, this appears to have been fixed now?
Why check 40,000 entries instead of 1? Or is my idea just dumb?
You guys are really stretching my memory, my original post was almost a year ago!
Jonathan, as I mentioned, that is not the way it works. The performance hit the article describes has nothing to do with looking at this attribute on a zillion mailboxes. The attribute that lists the mailboxes where you’ve been granted rights is already there. I mentioned it on my first reply.
Again, msExchDelegateListLink is the forward link. msExchDelegateListBL is the backlink. For example, let’s say you have a mailbox named Jonathan. I go to a mailbox named Bill and I set msExchDelegateListLink to point to Jonathan. Active Directory automatically populates msExchDelegateListBL on Jonathan with the DN of Bill (you can test this in ADSI Edit if you like). Now, when Jonathan performs Autodiscover, Exchange simply reads msExchDelegateListLink from Jonathan and returns those values in the Autodiscover response.
Outlook calls Autodiscover, Autodiscover reads msExchDelegateListBL from your mailbox. Done. There’s no scouring the AD for msExchDelegateListLink.
Oh, and in answer to your question about AlternateMailbox, that’s the part of the Autodiscover response that lists the mailboxes from msExchDelegateListBL. It’s actually AlternativeMailbox, though. They spelled it wrong in the article.
Bill the problem I have is that I do not see the attribute “msExchDelegateListBL”, is there a version when this was introduced? We are currently running Exchange 2010 SP1. Autodiscovery and opening mail boxes is working OK. My mailbox/user has access to 3 mailboxes and no attribute “msExchDelegateListBL” or anything close? Attribute “msExchDelegateListLink” is easy to find. AD is 2008 R2 fully patched. Exchange is going to be SPed in next couple of weeks. This is a different environment from when I wrote my original post…but same behavior? Where in AD is the attribute written?
Found the attribute in SP2 documentation, so looks like you are right for SP2 onwards, SP1 behaves pretty much as I described, so I guess somebody at Microsoft recognized the problem before me and fixed it with SP2.
Nope, not sure what you mean that you can’t find the attribute. If you’re looking in ADSI Edit, make sure you check the box to view read-only attributes. I just spun up a clean Exchange 2010 SP1 VM with no RUs or anything. I gave user 1 rights to user 2’s mailbox. Here’s a screenshot of the attributes in ADSI Edit:
http://gyazo.com/e254bdf070e13e50a3368a7bfd8d208b
This attribute was always there from the start. This was never the performance issue.
The performance issue the article is talking about is what happens whenever you add several additional mailboxes to Outlook by any method. It doesn’t have to be automapping. You can go into the profile, go to “Open these additional mailboxes”, and add some mailboxes there, and you’ll experience the same performance issue. It’s the issue that comes with opening several additional mailboxes by any method, regardless of automapping.
The problem with automapping is that, unlike additional mailboxes in the profile, you couldn’t take the mailboxes out of the profile. There was no way to stop Outlook from opening them (aside from removing the permissions), which was why it was such an issue.
Bill you are right, I had to turn on “backlinks” in ADSI edit 🙂 Documentation shows these were added to Exchange 2007 with SP2, total brain fade on my part. As a note these attributes can also be viewed from ADUC in advanced mode…which also needs the option “backlinks” selected.
Pingback: David Rowe - Automapping Mailboxes in Exchange 2010 and Outlook
Excellent items from you, man. I’ve bear in mind your stuff prior to and you’re just too great.
I really like what you have acquired right here, certainly like what you’re stating and the best way wherein you assert it. You are making it enjoyable and you still care for to keep it wise. I can not wait to learn much more from you. That is actually a great website.
Great post. I was checking constantly this blog and I am impressed!
Extremely useful info particularly the last part 🙂 I care for
such info a lot. I was looking for this certain info for a long time.
Thank you and good luck.