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)