Disable Exchange 2010′s Auto Shared Mailbox Mapping Feature
Update - 8th December 2011
Service Pack 2 bring this functionality natively into Exchange Powershell and you no longer need this script if you are on Exchange Server 2010, SP2 allows you to specify that you don't want auto-mapping enable directly from the native Add-MailboxPermission command, using the -AutoMapping parameter:
It's that simple.. Stay tuned for a future article explaining how to extend this functionality to the Exchange Management Console 
Original Article - Applied to Service Pack 1 only:
You may remember from my previous article "Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2007 & 2010", since Exchange 2010 SP1 was released, granting a user permissions to another mailbox automatically adds the mailbox to the user's profile in both Outlook 2010 and fully patched Outlook 2007.
A few of the comments make it clear this isn't a universally-desired feature, in particular if you're an Admin and have access to a range of mailboxes (particularly system mailboxes like support addresses etc). Whilst it can be removed with ADSI edit after granting permissions, that's not a straightforward way to accomplish this.
To get round this and make it easy to add permissions without the auto-mapping I've written a straighforward script that can be used as a direct replacement to the normal Add-MailboxPermission command, Add-MailboxPermissionNoAutoMap.ps1.
Savvy Exchange Powershell coders will ask "why don't you do this using the Scripting Agent, disabling it across the board, even in Exchange Management Console".. Well that was my first thought. However, it appears that with Add-MailboxPermission the actual entries are added after the OnComplete section runs instead of before. If that get's fixed I'll certainly re-visit as it would be ideal to have a solution that allows the feature to be switched on or off on demand.
So, in the meantime, here's your drop in replacement Powershell script. It's very simple - it takes the standard parameters to the Add-MailboxPermission cmdlet and after ensuring we know what domain controller the command will act on (to ensure no replication confusion) it adds permissions the normal way, then removes the msExchDelegateListLink AD entry that has just been added.
Here's an example of it in use..
As you can see, it's very similar to the normal Add-MailboxPermission command - in fact it should accept all the same parameters and pass them through without modification. Hope you find it useful!
The full script is below, along with the file to download underneath:
.SYNOPSIS
Adds Mailbox Permissions without Auto-Mapping in Outlook
.DESCRIPTION
Performs the same functions as Add-MailboxPermission with the added extra that it doesn't automatically add the Mailbox to Outlook 2007 and 2010
For more help use Get-Help Add-MailboxPermission
#>
param(
$Identity,
[Alias('db')]
[Switch]
$Debug,
[Alias('wv')]
$WarningVariable,
[Alias('cf')]
[Switch]
$Confirm,
$Instance,
$AccessRights,
[Alias('ea')]
$ErrorAction,
[Switch]
$IgnoreDefaultScope,
$DomainController,
[Alias('wi')]
[Switch]
$WhatIf,
[Alias('ob')]
$OutBuffer,
[Alias('wa')]
$WarningAction,
$Owner,
$InheritanceType,
$User,
[Alias('ov')]
$OutVariable,
[Alias('vb')]
[Switch]
$Verbose,
[Switch]
$Deny,
[Alias('ev')]
$ErrorVariable,
[Switch]
$AsJob)
if ($DomainController)
{
# Domain Controller was set. Get the Mailbox we are adding permissions for first so we have it's LDAP DN
$Mailbox = Get-Mailbox $Identity -DomainController $DomainController
if (!$Mailbox)
{
throw "Could not find Mailbox $($Identity)"
}
# Add the permission
$Result = Add-MailboxPermission @PSBoundParameters
} else {
# Domain Controller was set. Get the Mailbox we are adding permissions for first so we have it's LDAP DN and a domain controller name
$Mailbox = Get-Mailbox $Identity
if (!$Mailbox)
{
throw "Could not find Mailbox $($Identity)"
}
# Set the domain controller
$DomainController = $Mailbox.OriginatingServer
# Add the permission
$Result = Add-MailboxPermission @PSBoundParameters -DomainController $DomainController
}
if ($Result)
{
# If the mailbox permission was successfully added, remove the auto mapping using ADSI
$LDAPUser=[ADSI]"LDAP://$($DomainController)/$($Mailbox.DistinguishedName)"
$LDAPUser.msExchDelegateListLink.Remove(((Get-Mailbox $User).DistinguishedName))
$LDAPUser.SetInfo()
# Output the result of Add-MailboxPermission like the normal command would
$Result
}
Download AddMailboxPermissionNoAutoMap.zip
Related posts:
- Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2010 and Outlook 2007
- Scripted Shared Mailbox Creation on Exchange 2007/2010
- Creating Shared Calendars on Exchange 2010
- Setup and use the GAL Photos feature using Exchange 2007 [Updated]
- Outlook 2007 update for personal archive and automatic mailbox mapping released
More from StevieG.org
- About Me
- Car PC
- Exchange 2010 Virtual Load Balancer
- Exchange Environment Report
- Recommended Exchange Reference Material
Find Me On…
Important Notice
Categories
Recent Posts
- A quick look at the free Exchange Server 2010 Boot camp from ExchangeServerPro.com
- Importing Global Address List entries into a user’s Contacts folder
- Thoughts on Mailbox Database Distribution in Exchange 2010..
- Testing edge blocking in Forefront Online Protection for Exchange using Powershell
- iPhone with Exchange 2010 – Business Integration and Deployment available for pre-order now
- A look back at 2011, and a look forward to 2012
Top posts
- Disable Exchange 2010's Auto Shared Mailbox Mapping Feature
- Using the Exchange 2010 SP1 Mailbox Export features for Mass Exports to PST files
- Generate Exchange Environment Reports using Powershell
- Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2010 and Outlook 2007
- Managing iCal Calendar Sharing with Exchange 2010 SP1 [Updated]
Blogroll
- Aaron Tiensivu's Blog
- Clint Boessen's Blog
- Devin on Earth
- Dougs Blog…
- Elan Shudnow's Blog
- Exchange Server Pro
- Exchange Team Blog
- Exchange2010.com
- Exchangepedia Blog
- Henrik Walther Blog
- Microsoft Messaging and Mobility User Group UK
- Mike Crowley's Whiteboard
- Mike Pfeiffer's Blog
- Nuttin but Exchange
- VMlover by Daniel Eason
April 15th, 2011 - 14:50
If you wrap that into a function and dot-Source it in your Powershell Profile, you even don’t notice that it is a custom script… Nice Work! Thanks! Christian
April 26th, 2011 - 19:17
Thanks, glad you like it. Now I have a fair few scripts I am wrapping them up into a single module; as you say it’s easier when the commands are pre-loaded!
Steve
June 17th, 2011 - 09:19
can you do this for delegating control between domains?
EG: PAs for the Finance Directors; both accounts on domain 1; but they all have linked mailboxes on domain 2 (where exchange is obviously).
June 18th, 2011 - 10:40
Hi Simon,
It should do IIRC, this is only a wrapper for the normal Add-MailboxPermission and it strips the auto mapping afterward, so it’s bound by the same constraints
Steve
June 17th, 2011 - 09:33
Does this work for the enumeration of security group members?
June 18th, 2011 - 10:39
If you add a group, it doesn’t auto map the mailbox for the group members so ‘by default’ Exchange already does this for group members.
Steve
September 27th, 2011 - 10:49
Very useful script that we have with one of our customers. Just tried it on a site with a resource domain and it failed to remove the auto map. Foolishly I didn’t capture the error but basically it looked like it added the permission OK but when the script tried to remove thew automap it failed to find the Account Domain user account on the resource domain Domain Controller.
Regards,
Jonathan
September 28th, 2011 - 11:39
Hi Jonathan,
Unfortunately I’ve not tested this out in a multi-domain environment. Theoretically one would expect it to work (maybe not so in a resource forest situation) but it may need to trap the different domain and find an appropriate DC
Steve
October 29th, 2011 - 18:16
Does this remove all auto-mapping of existing mailboxes a user has full access to, or just remove the auto-mapping of the mailbox you’re adding at the time of running this script?
November 8th, 2011 - 00:21
It should only affect the auto mapping of the user you are adding permission to. It won’t affect other users given mailboxpermissions with auto mapping.
Steve
November 17th, 2011 - 23:06
Thanks for the reply.
I have a script that runs this for every user who has a “Direct Report” and grants the manager access to their Direct Reports’ mailboxes, then goes through each one of those Direct Reports and grants them access to each others (but doesn’t grant them access to their managers).
This sounds odd but it is what the staff wants.
Problem is people move around, often.
Do you know of any solutions or tricks that might help with performing cleanup of old, unnecessary permissions and re-add new ones when organizational changes are made?
I was thinking maybe once a quarter run a script that removes everyone’s access to any user mailbox, then re-adds based on their current Manager and Direct Reports (active directory), then of course re-adds those general mailboxes some departments use (could be based on checking their security group permissions).
November 30th, 2011 - 23:27
I think such a script is possible, to be honest right now I wouldn’t have time to write one for you though.
Steve
December 15th, 2011 - 12:53
Thanks for the post, very useful.
I’m looking to disable the auto mapping function for my entire domain (ie every user). Any ideas how I could achieve this?
Sorry to ask but powershell isnt my strong point.
Thanks
February 7th, 2012 - 00:35
Thank for the great post. Have used on several sites.
Also interested in disabling that feature on the entire domain. Is it possible?
You also mentioned: “Stay tuned for a future article explaining how to extend this functionality to the Exchange Management Console” … Any ETA???
Cheers
Alexandre
February 7th, 2012 - 07:56
No-one asked me yet! You are the first
There was a problem originally with extending the functionality (using the scripting agent) so any permissions set via the EMC would also take this no-mapping functionality. In SP2 though that should be fixed.
Basically this is an all or nothing thing – it will be a method of disabling across Exchange. Will this meet your needs?
Steve
February 7th, 2012 - 11:12
Yes! Go ahead!