Quick Fix: Office 365 DirSync Hide a user from Global Address List

This week i have been working on some process automation, around a user leaving an organisation using Office 365.

DirSync (and it’s newer iterations) has been a very useful for Password Sync and User creation, however it can be a bit of a drag when it comes to editing mailbox settings. In this case, Hiding a user from the Global Address List.

Set-Mailbox Error On Prem

So to hide the Mailbox from our Office 365 Address List we need to use ADSIEdit and change the msExchHideFromAddressLists attribute to True, then wait for DirSync to do it’s thing.

ADSIEdit

This is fine for a one off, well maybe it is, but i like to script things so i can execute a bunch of actions to an account at once.

Enter PowerShell.

Unfortunately this attribute is not exposed to Set-ADUser, only to Get-ADUser, and Set-Mailbox is not valid here as the user has no On Prem mailbox anymore. We need a way to expose the attribute we want to edit, and save it.

We can do something like this:

$user = Get-ADUser dfunk –properties *

This tells PowerShell to collect every attribute the user has and store them as $user.

Next, we edit the attribute.

$user.msExchHideFromAddressLists = “True”

This then sets that attribute to True.

Now we save,

Set-ADUser –instance $user

Set-AD

Voilà

This of course applies to any attribute you care to edit, i also use it when i need to add additional email addresses to an account that is provisioned via DirSync.

For even more fun why not roll this into a ‘Leavers’ script that removes their Office 365 Licenses, forwards email to other users disables there account etc etc.

About Robert Pearman
Robert Pearman is a UK based Small Business Server enthusiast. He has been working within the SMB IT Industry for what feels like forever. Robert likes Piña colada and taking walks in the rain, on occasion he also enjoys writing about Small Business Technology like Windows Server Essentials or more recently writing PowerShell Scripts. If you're in trouble, and you can find him, maybe you can ask him a question.

18 Responses to Quick Fix: Office 365 DirSync Hide a user from Global Address List

  1. George says:

    You probably have local exchange server as well, but I don’t, so I don’t have, msExch* attributes in AD. Any other Idea?

    • Jack Chamberlain says:

      George,

      Hopefully, someone else can be helped by this.
      We use Office365 and AD Connect that syncs the directories.
      We had a user account that was disabled before we went to AD Connect. The user got re-activated but the msExchHideFromAddressLists=True was still set when the user was synced to Azure. We were unable to un-check the box as we did not (and will not) extend the schema with an Exchange prepare AD command. We got the error that the object was out of write scope. This prevented the user from showing up in the GAL.
      The way we got around this problem:
      1. Enable AD Recycle Bin
      2. Back up the email just in case
      3. Delete the user from local AD and run a manual Delta sync. This forces O365 to soft-delete the mailbox and account.
      4. Verify the user shows up in Deleted Users on Office365.
      5. Restore the user on Office365 only . Set password to a secure password.
      6. Once the mailbox is reconnected in the Exchange console on Office365, clear the Hide From Address Lists checkbox
      7. Open Active Directory Administrative Center and restore the user object
      8. Run manual Delta sync. This gave an error on the first sync but worked on the second try.
      The user then showed up in the GAL.
      Hope this helps,
      Jack

  2. You should just be able to use a normal Set-Mailbox command against Office 365.

  3. Oliver says:

    That’s not possible when you sync the user with AAD Connect and you don’t have an Exchange On-Premise Setup, means: No Exchange in On-Premise AD = no msExch* attributes… and you’ll not be able to configure the mailbox with the Set-Mailbox command.

  4. bobebuk says:

    if you have never had any exchange on-premise and as such no msExch attribute, this is easily enough resolved by extending the schema with the exchange setup files.

    1. Logon to a local DC and make sure you are an Enterprise & Schema Admin.
    2. On the same server insert the Exchange 2010 CD (or download Exchange 2010 SP2 and unpack it).
    3. Open up a CMD prompt and browse to the CD/SP2 directory.
    4. Extend the schema by executing the following command: setup.exe /ps (if this is not sufficient you can also do “setup.exe /PrepareAD” and “setup.exe /pl“)

    obviously dependant on your environment change control may be required.

  5. You suggested rolling this into a “Leavers Script”. Has this been developed somewhere I can borrow for my organisation?

    • nonseq says:

      I hate to contradict MS, but you can extend the AD Schema to add the msExch properties, without installing a server. Then once the properties are in Active Directory, you can change them either with powershell, or using ADSIedit, to edit the property directly.

      We migrated to Office365 a year an a half ago, without an in-house Exchange server, and we needed the proxyAddress and TargetAddress properties, which are installed with extending the schema.

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

%d bloggers like this: