Disable Auto-Mapping for the complete environment instead per user using the Shell

You cant use the EMC to disable auto-mapping. We all know that! We also know that we can grant full access permission to users mailbox and disable the auto-mapping feature per user with using the Shell.
The primary problem is that some users have full access to so many mailboxes but can't keep a good overview in outlook, recognizable!

Is there also a possibility to disable auto-mapping for the complete existing environment included from now to the future without doing anything in the future from applying the disabling?





  • Edited by supraindo 19 hours 17 minutes ago
  • Moved by Bill_Stewart 8 hours 18 minutes ago Move to more appropriate forum
May 20th, 2015 6:00am

Hi Supraindo,

Please find below link to article which has a nice script for

1. Removing existing auto-mapping enabled AccessRights on mailboxes.

Script to remove Exchange 2010 AutoMapping for all mailboxes

# Get all mailboxes in the forest
$Mailboxes = Get-Mailbox -ResultSize unlimited -IgnoreDefaultScope
$ConfirmPreference = 'None'

# Iterate over each mailbox
foreach($Mailbox in $Mailboxes)
{
    try 
    {
        # Try to run the example fix against the current $Mailbox
        $FixAutoMapping = Get-MailboxPermission $Mailbox |where {$_.AccessRights -eq "FullAccess" -and $_.IsInherited -eq $false}
        $FixAutoMapping | Remove-MailboxPermission
        $FixAutoMapping | ForEach {Add-MailboxPermission -Identity $_.Identity -User $_.User -AccessRights:FullAccess -AutoMapping $false} 
    }
    catch
    {
        # Inform about the error if unsuccessful
        Write-Host "Encountered error: $($Error[0].Exception) on mailbox $($Mailbox.DisplayName)" -ForegroundColor Red
    }
}

2. Disabling it for future automatically, I don't see anything right now.

Except creating a RBAC role and limiting admins' access to Add-MailboxPermission cmdlet. And the admins having access should be aware and always include -Automapping:$false as shown below whenever using it.

Add-MailboxPermission -Identity JeroenC -User 'Mark Steele' -AccessRight FullAccess -InheritanceType All -Automapping $false
I'll get back, if I happen to find anything on the 2nd point.

References:

https://technet.microsoft.com/en-in/library/hh529943(v=exchg.141).aspx

Free Windows Admin Tool Kit Click here and download it now
May 20th, 2015 8:47am

This is not a scripting question. It is a product specific question.  You should ask it in the Exchange forum for the version of Exchange you are using.
May 20th, 2015 10:00am

Hi Supraindo,

Back to point 2 disabling AutoMapping for the Entire Org by default. Earlier releases when this was made available there was no option to disable it even per user basis, later EMS cmdlet was there. This makes it clear that MS wannts you to use it and as this is something built into exchange without any endpoints to manage it organization-wide. Hence any users without explicitly disabled would automatically have automapped shared mailboxes. (We can post a feature request on this at the most)

Back to what we have is per-user disabling automapping that too on first attempt of Add-MailboxPermission, if user already has it, we need to remove everything and re-assign with automapping $false.

Below are two points for leveraging this workaround automatically to some extent:

Headsup on  Proxy Functions in PowerShell:

By choosing the same name as the cmdlet, we can take advantage of the command discovery process in Windows PowerShell. Basically, if you have a cmdlet and a function with the same name, the function takes precedence. Here is the order of command precedence that is used by the command discovery process in Windows PowerShell:

Alias: All Windows PowerShell aliases in the current session

Filter/Function: All Windows PowerShell functions

Cmdlet: The cmdlets in the current session ("Cmdlet" is the default)

ExternalScript: All .ps1 files in the paths that are listed in the Path environment variable ($env:PATH)

Application: All non-Windows-PowerShell files in paths that are listed in the Path environment variable

Script: Script blocks in the current session

This is kind of re-writing the cmdlet with your default values, like -automapping $false

Here is an article to begin with, how and where to implement that you need to find out. Make sure you deploy it across all servers where you manage using EMS, you might want to update the environment path variable as well.

So in some cases like PS Remoting from client PC, this script most likely will not be triggered.

Another option would be using Cmdlet Agents:Scripting Agent:

Eg. Its like you create a New-Database, this can be used to trigger as script which would run Mount-Database.

So you can make Add-MailboxPermission trigger a script like in the earlier post's point 1. However this to me appears too messy for your scenario. Note this would work when you are running the Add-MailboxPermission using EAC as well.(As cmdlets run at background for GUI as well)

Free Windows Admin Tool Kit Click here and download it now
May 20th, 2015 11:46pm

Hi supraindo,

Thank you for your question.

We could create a distribution list, then access Full Access permission to a distribution list, then add the user to the member to a distribution group. Then check if is was auto-disabled.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Jim

May 21st, 2015 3:10am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics