Office 365 – Hide from address lists (GAL)

I’ve recently been working on getting shared mailboxes in Office 365 to be hidden from the Global Address List (GAL) in the OWA and Outlook. I had a lot of trouble once I got the address hidden when I tried to access the shared mailbox (I’ll show the error later). After looking online, I couldn’t really find a comprehensive guide, hints writing this post. This post will cover the GUI, PowerShell and the problem that I encountered.

**Reminder, this only works for accounts in Office 365, the process is different for Active Directory synchronized accounts. Since I’m working with shared mailboxes, the accounts are NOT in my active directory.

Below is the screen shot from the OWA.
All Users

 

In order to “hide” shared mailboxes from this list, you either need to use PowerShell or access from the GUI. If you’re just doing one or two mailboxes, the GUI works well, but for larger scales, PowerShell would be recommended.

Gui

From your administrator account on Office 365, select ‘Admin’ and ‘Exchange’ from the drop down menu.

Exchange

 

After going into the Exchange Administration Center, verify that ‘recipients’ is selected and select ‘Shared’. This will bring you to all of your shared mailboxes.

Admin Center

Double click your Shared Mailbox that appears in the list or select the pencil icon to edit the properties. You will see that ‘Hide from address list’ is unselected. Since you want the account hidden from the address list, you need to select the check box. This makes your address hidden the from GAL.

PowerShell

To hide the account from the GAL using PowerShell is quite a bit more simple.

You need to connect to your Exchange Center via PowerShell by using the following:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Once connected into the Exchange Center, run the following PowerShell command to edit the one account.

Set-Mailbox -Identity user@domain.com -HiddenFromAddressListsEnabled $true

This will make the desired mailbox hidden, you can verify it from the GUI if you desire.

The Problem…

Since the Shared Mailbox is now hidden from the GAL, it’s going to cause some problems if you remotely access the mailbox. We have shared mailboxes enabled for Calendars and some for Inboxes for different functions. Therefore, many different people access different aspects of the shared mailboxes.

So, what’s the problem? Well, when you try to open the mailbox it gives you an error that either (1) you don’t have permissions, or (2) the mailbox doesn’t exist. Since I do a lot in the OWA, I’m going to show all error messages in that.

To replicate the error in the OWA (again the error message might change in Outlook), go to your inbox by selecting Outlook. Then select the drop down menu by your name, and select ‘Open another mailbox…’

Open Mailbox

This will present you with a window to enter the email address for the shared mailbox.

Another Mailbox

Enter in the email address of the shared mailbox and you will see something similar to this (obviously you will have an address in the white box):

Not Found

 

It will NOT let you open the mailbox because according to your GAL, it doesn’t exist (but still receives mail).

Workaround

In order to work around this issue, there are two options (1) unhide the mailbox and deal with it being in the GAL or (2) add the contact into your personal contacts.

If you REALLY don’t care about the address being in the GAL, then leave it. But, if you don’t want it in your GAL, it’s going to be quite a bit of work, that cannot be scripted or done remotely.

Since option 2 is the option I want to proceed with, I’m going to move forward with explaining it. If you need to reverse the “Hide from address list” shown above, just uncheck the box in the GUI, or run the following if you’re working in PowerShell.

Set-Mailbox -Identity user@domain.com -HiddenFromAddressListsEnabled $false

So, option 2.

You still need to unhide the address in either the admin center, or using the above command. If you verify in the GUI, you will see the check box unchecked. Or verify in PowerShell by running the following command.

Get-Mailbox -Identity user@domain.com | Format-List Hid*

This will display either True or False. If True, that means that it IS hidden from the GAL.

Once you have the HiddenFromAddressListsEnabled set to False, you can proceed forward by opening the mailbox outlined above that gave the error. This will perform the lookup in the GAL and open the shared mailbox for you.

But, since you don’t want the address in your GAL, you need to add a local contact with the shared mailbox address into your contacts before hiding the mailbox again. Once you have created the contact in YOUR contacts, you can hide the shared mailbox again (outlined above).

Once you have hidden the mailbox, attempt to open the mailbox as outlined before. It should work.

Issue

The biggest issue I have with this, is since we have multiple people accessing the mailboxes with various permissions, I cannot add the contact remotely to the contact list, nor can I expect everyone of them to add it locally themselves. If there is a way to add contacts to users contact lists remotely, I would love to know how to do it.

 

Like I said before, I couldn’t find any of this information in a centralized location, so I decided to consolidate it all together to hopefully help someone down the road.

Advertisements

5 thoughts on “Office 365 – Hide from address lists (GAL)

  1. Would it work to create the contact in a public contacts folder, and then assign access to that folder to those who need it?

  2. alternately to adding it to your contacts, it’s easy to just add it as an auto-complete address. compose a new message, enter the address and hit enter. discard the message. you can now enter the address in the ‘open another mailbox’ interface.

    there are other annoyances to hiding addresses of service/shared accounts in the GAL. try configuring your account in Outlook 2013. it will “auto-map” any accounts you have full mailbox permissions over, so you will see your shared account in there as well. when attempting to Send As/On Behalf Of the service account, your mail will be rejected. this is because it searches the GAL for permissions. The only way to make this work is to show it in the GAL (or use OWA).

    We are currently rolling out o365 and I’m concerned about a decision that was made earlier: by default, all shared/service accounts are hidden from the GAL. We may consider changing this since we are still early in the roll-out. What other impact or usability/support issues may this configuration cause?

    1. I hadn’t thought about doing the auto-complete and removing the address. If it works, that is a great idea!

      I have also run into the problem with auto-mapping the mailboxes. Initially I setup me having full control of all shared mailboxes and they all showed up, causing outlook to run pretty slow. My solution to that was removing full control permissions for myself via PowerShell. I then created a script that asks for the mailbox name and the user and will assign/remove full control as needed. It works well if I need to take a quick look to see something in the mailbox. I’ve also had problems with people deleting stuff out of the shared mailboxes that they shouldn’t delete. I’ve found that when a user deletes something out of a shared mailbox it doesn’t go into the deleted items, it goes into the hidden recovery recycle bin and can only be restored from PowerShell in a specific timeframe, it is a massive pain. I’ve made some work arounds for that, but I’m not sure if it’s the best choice.

      We rolled everything out as showing up in the GAL, which allowed the people that needed it to have it mapped. Then when I hide it from the GAL they still stick. My guess is that it’s the auto-complete as your pointed out. I wouldn’t worry about which way you roll them out, it can be changed very quickly with PowerShell. On a side note, I’ve found using PowerShell with Office 365 is much faster and the settings seem to be applied immediately.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s