Normally when an account is given full permissions to a shared mailbox, the shared mailbox is auto-mapped to the delegate account’s Outlook profile. The shared mailbox is added to a linked attribute in Active Directory. Linked attributes describe a relationship between objects and are often paired as ForwardLinks and BackLinks. In the case of Exchange shared mailboxes, the user DN is added to msExchDelegateListLink and the shared mailbox is added to msExchDelegateListBL.
Auto-mapped shared mailboxes are opened as a function of the forward linked attribute (msExchDelegateListLink) in combination with the Autodiscover feature. When the Autodiscover XML is examined (Test E-Mail Autoconfiguration) the auto-mapped mailbox appears in the XML tab in the AlternativeMailbox tag.
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Sales</DisplayName>
<LegacyDN>/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Sales</LegacyDN>
<Server>ServerName</Server>
</AlternativeMailbox>
Mailboxes opened in this manner (shared, archive, public, etc.) are not natively part of the Outlook profile and therefore are not processed by Outlook’s account creation routine. As a result, the auto-mapped shared mailbox does not acquire a signatures folder in the file system. By default, Outlook creates signature folders for all accounts that go through the creation process at C:\user\username\appdata\roaming\microsoft\signatures.
To add a signature to messages sent from shared mailboxes in Outlook we need the software to treat them as if they were a regular user account. This goal can be accomplished by disabling the auto-mapping for the delegates that access the shared mailbox and manually connecting Outlook to it. Unfortunately, this cannot be accomplished through the Exchange Control Panel or the Microsoft 365 Portal. It is easiest to disable automapping with PowerShell.
Before we learn the PowerShell code, it is important to understand that modifying the permissions, or membership of a shared mailbox with the Exchange Control Panel, or the Microsoft 365 Portal will re-enable the auto-mapping feature for all delegate accounts. The various GUI management tools for Exchange do not expose the attribute for auto-mapping. As a result, the attribute is always returned to its default state ($true) when these tools submit their commands.
The default enabled state of the auto-mapping feature imposed by the Exchange GUI tools causes the workaround to potentially malfunction for any or all member accounts. The issue occurs because Outlook will connect to a particular resource only once and the first connection wins. If the first successful connection to the shared mailbox is the auto-mapped AlterativeMailbox, the signature folder created by the work around will not be mapped to Outlook’s send function.
If a shared mailbox is mistakenly modified using one of the Exchange GUI management tools, each delegate must be removed and re-added using the PowerShell method (below) with the auto-map feature disabled. If a delegate user’s Outlook has already connected to the AlternativeMailbox, their signature for the shared mailbox will not function for up to four hours after the correction with PowerShell has been executed. The auto-mapped shared mailbox must be disconnected from the user’s Outlook profile by the Exchange Mailbox Agent before the explicit connection created by the workaround will be guaranteed to connect first.
To establish the workaround and enable Outlook signatures from shared mailboxes, create a shared mailbox. Once the shared mailbox is established use the Add-MailBoxPermission cmdlet to add the delegate’s accounts.
Add-MailboxPermission -Identity “Shared Mailbox Name” -User “Delegate User ID” -AccessRights FullAccess -AutoMapping $false
(replace “Shared Mailbox Name” and “Delegate User ID” with the actual values, leave the “” in place)
If you are applying this technique to an existing shared mailbox, or if you are correcting a mailbox that was modified with one of the Exchange GUI tools, you will need to remove and re-add all the delegate members with PowerShell. This small script automates the process.
$FixAutoMapping = Get-MailboxPermission “Shared Mailbox Name” | where {$_.AccessRights -eq "FullAccess" -and $_.IsInherited -eq $false}
$FixAutoMapping | Remove-MailboxPermission
$FixAutoMapping | ForEach {Add-MailboxPermission -Identity $_.Identity -User $_.User -AccessRights:FullAccess -AutoMapping $false}
(replace “Shared Mailbox Name” with the actual name, leave the “” in place)
Once the shared mailbox and its membership (auto-mapping disabled) have been established or corrected, all that it left is to access it with Outlook as if it were a separate account. You will use the delegate’s credentials to logon. Open Outlook, go to File -> Add Account, enter the shared mailbox’s primary email address, enter the delegate user’s email address and password when prompted for credentials.
techbloggingfool.com 