4

I have been happily using Powershell to automate a lot of admin task in an Exchange 2010 On-premises environment.

Recently, I found a new job which uses O365 in a hybrid environment. Just to explain a bit, the new environment has On-premises Active Directory plus an instance of On-premises Exchange Server (which actually has no user mailboxes inside). The On-premises Active Directory is synced to an Azure AD in the cloud and all user mailboxes are in Exchange Online in O365.

I tried to modify my Powershell script (based on On-premises Exchange 2010) to run in this new environment. I added commands to establish a MFA Powershell session to Exchange Online. Then, except replacing some On-premises Powershell commands with new cloud Powershell commands, I was able to "get-" most of the information I want.

However, when I tried to run the same Powershell commmands to update mailbox (for example to hide a mailbox), I encountered an error message saying that you cannot do so and must update via the On-premise instance. The funny thing is when I run the same old script to "add-mailboxfolderpermission" or "remove-mailboxfolderpermission", I was able to so.

Does anyone know why it is like that? If I cannot use "set-mailbox" to hide the mailbox, what commands should I use to hide the mailbox?

Blue Tongue
  • 147
  • 11

1 Answers1

3

The on-premise AD is synced to Azure AD to support Office 365/Exchange online. The sync is one-way (almost entirely), from on-premise to the cloud. The on-premise AD is authoritative and that is the only place you can make AD changes.

Note that the mailboxes are all in the cloud. A mailbox is the data store for all of the Exchange data. If you want to change the mailbox, you do that in the cloud. If you want to change (almost) anything stored in AD, like mailbox visibility, you have to do that on-prem and then synchronize or wait for the next sync.

To make changes to mailbox metadata and settings stored in AD, run the same old commands you used to run against the local domain controllers, instead of trying to run them against your EOL/Office 365 tenant account.

Does that explain it or would you like more detail?

Todd Wilcox
  • 2,831
  • 2
  • 19
  • 31
  • the reason I was confused is in Exchange 2010 On-premises, I used the command "set-mailbox" rather than "set-aduser" to hide a mailbox from GAL and so in EOL, I thought this hide/unhide setting must be in EOL too. So, as I learnt now, to hide/unhide a mailbox in O365, I will need to modify the msExchHideFromAddressLists in On-premises AD and then let it sync to EOL. – Blue Tongue Feb 16 '19 at 04:02
  • So, what you are saying is always update your local AD for those EOL features that are modifiable via msExch attributes in AD account Is this correct? – Blue Tongue Feb 16 '19 at 04:10
  • @BlueTongue Correct. And your first comment is also correct. Some of the big areas that this effects are proxy addresses and of course distribution group membership and all kinds of basic data like name, address, title, etc. – Todd Wilcox Feb 16 '19 at 08:06
  • Thanks for explaining it me. Much appreciated. Can you please also explain to me what the purpose of the empty On-premise Exchange Server in a hybrid O365 environment is? I understand there are On-premises business apps which need to send out email but I don't think you need to build an empty Exchange Server for that. – Blue Tongue Feb 17 '19 at 05:10