You don’t need “SMTP:” in the RemoteRoutingAddress parameter when using powershell to add it.
Okay i understand. I was thinking it might not be necessary to run Enable-RemoteMailbox.
The issue is that we do not have an on-premise Exchange server in DEV, making it difficult to use Enable-RemoteMailbox. I was considering other solutions to enable the mailbox, but I understand the limitations. They installed the Exchange management tools on another sever, but from IQService, we cannot use Enable-RemoteMailbox.
I have another customer where mailbox management (enabling/disabling) works perfectly using PowerShell scripts.
If you want to do it completely without PowerShell, you need to populate the following additional attributes:
proxyAddresses: SMTP:[email protected],smtp:[email protected]
msExchRemoteRecipientType: 1
msExchRecipientDisplayType: -2147483642
msExchRecipientTypeDetails: 2147483648
Note, proxyAddresses is a multi-valued field (separated here for clarity with a comma). This is what the PowerShell does under the covers, ie it just populates AD attributes.
1 Like
Is pratical or recommanded those attribute directly ?
I’ve not had a problem with it, but like I say above, it could be deemed less supportable. I’m not specifically recommending it as it does involve deep knowledge of hybrid Exchange, just giving you options and some context. The attributes I mentioned in the first instance, mail, nickname and target address, though are fully supported for direct modification.
Hi Manish! What commandlets you are referring to are being depricated?
Finaly, We use similaire commands provided by @KRM7 but in our case retrieved directly : exchange server, service account and password from our Active Direcotry source configuration