Hello. i posted on the O365 Forums however they suggested i posted the question here.

I think this has been posted a few times, i just want to know the best option for changing a user who is "Synced with active directory status" primary SMTP email address

currently on O365 we have John.Smith@contoso.onmicrosoft.com and we want to change it to John.Smith@contoso.com, attempts to change it within the O365 portal fail with a error.

The operation on mailbox "John Smith" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object 'John Smith' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

what attribute / setting would i need to alter on premise as the mailbox is not present in my on-premise mailbox

Any Suggestions 

Many Thanks

Gordon

As the mailbox is synced from your on-premise Exchange, you should have a "Remote User Mailbox" object in Exchange. In the "Email addresses" tab for the object, you can choose which email address you set as default. When you dirsync, the change will be replicated to O365.

If for some reason the "Remote User Mailbox" object has been removed, the resolution is a bit more time consuming:

1. Create a "Mail user" object for the user in Exchange connecting it with their existing AD account using the alias they have and the current primary email address.
2. With get-mailbox -identity 'username' | select exchangeguid you can get the GUID from Office 365.
3. Convert the GUID to import in to the MSExchMailboxGUID attribute in their AD account. GUID dd118d10-8802-4191-9580-78a16454eb98 becomes 10 8d 11 dd 02 88 91 41 95 80 78 a1 64 54 eb 98 as an example.
4. Paste the converted GUID in to the MSExchMailboxGUID attribute in their AD account.
5. Move the mailbox from O365 to Exchange.
6. Move the mailbox back to Office 365

This will correct the problem.

Hello.

The mailbox was created on Exchange Online it was not migrated, should a Remote User Mailbox still be present on Exchange On-Premise

many thanks

Gordon

As you're operating in a hybrid environment, the recommended method is to provision new mailboxes from Exchange with New-RemoteMailbox or Enable-RemoteMailbox (if an AD account already exists).  Then when you dirsync afterwards, the mailbox is provisioned automatically in Office 365. Then afterwards you assign a license.

Hi Gordon, I assume you already have a mailbox up and running on Office 365, right? Well now what you have to do is:

Change the User Principalname of the user, on premises, to john.smith@contoso.com - if not already and this is not related with the primary smtp address

For the primary smtp address you have two options:

Are you using ADFS for that domain? meaning is that domain federated? then you have to set the proxyaddresses attribute with SMTP:john.smith@contoso.com

If the domain is not federated entering the e-mail address on the mail attribute is enough

force dirsync and problem solved

Thanks for the reply's 

Were not using ADFS were using the Azure Ad Sync tool with password sync for SSO purposes.

so this is the standard practice for achieving SMTP address changes? there is nothing wrong with my setup?

regarding the process to create mailboxes at the moment

I assign a Exchange licences to AD Synced users which i turn creates a mailbox on the onmicrosoft.com domain, then change the Email address with the Set-Mailbox -windowsemailaddress command in windows azure PowerShell snapin , would it avoid all this if  them through the on-premise environment as suggest above via the New-RemoteMailbox command ?

with in the ECP does Recipients > + > Office 365 mailbox achieve the same thing?

many thanks

so this is the standard practice for achieving SMTP address changes? there is nothing wrong with my setup?

Answer: No your setup seems fine

You should always create a remote mailbox first, force dirsync and finally activate the license on 365.

Use your exchange on premises to do that

If you don't have an exchange on premises, (you should btw) create a user, add the mail attribute, force dirsync, add the license on 365. But you should use the new-remotemailbox

and yes a + office 365 mailbox achieves the same thing. Create one and if you go to the shell afterwards you can do a get-remotemailbox newuser@domain.com and you will see the newly created user/remotemailbox

yea we have exchange on premise i have a 2013 server running both CAS & MBX.

ill try this method as i am having issues getting mail to flow from on-prem to O365 and O365 to on-prem.

2 O365 users can send mail to each other and also have access to the GAL, however if i try to send to a user that is on-premise it just fails saying "The Domain name in the email address is incorrect Check the address"

If on-premise user tries to send to O365 user it fails with "The email address you entered couldn't be found"

i am trying to understand the New-RemoteMailbox Cmdlet 

i understand that will create a O365 mailbox + Mail-Enabled user on-premise

However say i have an existing AD user Johnsmith

UPN johnsmith@contoso.com

how would the new-remotemailbox command create him a mailbox?

or would i need to create him a on-premise mailbox and then migrate it to O365 via MRS

what is your process?

Many Thanks

Gordon

Hi Gordon, for mail flow to work you need to have the contacts correct. Let me explain so that you can check and test:

John365@domain.com is a mailbox on 365 with that primary email address

john365@domain.com needs to exist as a mail user (or remote mailbox) on premises. The primary smtp address needs to be john365@domain.com and the targetdeliveryaddress needs to be john365@domain.mail.onmicrosoft.com

if john365@domain.com does not exist as a mail user or remote mailbox on premises, than JohnOnPrem when emailing john365 it will fail with the error you described

JohnOnPrem@domain.com is a mailbox on premises. JohnOnPrem@domain.com needs to be a mailuser on 365.

When john365 emails johnonprem, because domain.com is not authoritative on 365 the email will be forwarded to on premises. It's MANDATORY for the mail flow 365 > on prem to work that johnonprem exists as a mail user on 365.

Answers to your questions:

no you don't need to create the user on premises and move him to 365

you should create a remote mailbox (creates the user) or enable the remote mailbox (existing user), force dirsync or wait, enable the license on 365. the target delivery domain of the remote mailbox (what determines the targetdeliveryaddress) needs to be domain.mail.onmicrosoft.com

regarding the domains, should my onprem.com domain on O365 be set to internal relay?

and on my O365 domain on-prem be set to internal relay as well?

many thanks

Gordon

Yes and yes. None of those domains should ba authoritative as the email needs to be forwarded to the other premises.

Okay so i have the above configured regarding the domains.

i just deployed a new users called remotetest@contoso.com via powershell.

New-RemoteMailbox -Name "RemoteTest" -Password <Password> -UserPrincipalName RemoteTest@contoso.com

DirSync Ran 

user appears in Azure AD within O365 - i then Assign a Exchange Online Licence E1 to the user.

O365 automatically configures Mailbox - Email Address is now RemoteUser@contoso.com (this solves the onmicrosoft.com issue) 

so we now have a mail-enabled user on premise and Mailbox in O365

when i try to email the user from Internally i get the error

remotetest@contoso.com (remotetest@contoso.com)
The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues, please contact your helpdesk.<o:p></o:p>

when i go into OWA with remotetest@contoso.com and try and send an email to an internal address i get.

Internaltest@contoso.com (Internaltest@contoso.com )
The domain name in the email address is incorrect. Check the address.

When i got this error i checked the message trace in Exchange-Online ECP and it shows

If i email someone outside of the @contoso.com domain from OWA as remotetest@contoso.com it works fine.

any suggestions.

i see alot of guides suggesting to use ADFS however i have opted for DirSync with password sync as for the SSO

Any Thoughts

Thanks for you help so far to

Gordon

• Edited by BpdZenithLtd 15 hours 56 minutes ago

You don't need ADFS. On premises open the remote mailbox, go to the email address tab and see what is the target delivery address. It should be just below the email addresses (a combo box)

it needs to be internaltest@contoso.mail.onmicrosoft.com

you can change it there or with the -remoteroutingaddress parameter on the new-enable-remotemailbox

but it should be calculated automatically.

yep the address is currently set to the following.

looks right to me.

An additional thought is that my DNS may be incorrectly configured.

some more background info.

i don't use centralized mail transport in our deployment as we don't need to do any strict mail filtering / processing

Existing Exchange MX & Autodiscover records remain unchanged on the public DNS

the only thing i have added is the Exchange-Online SPF entry into the existing SPF record

• Edited by BpdZenithLtd 14 hours 43 minutes ago

Ok, so that looks fine, next question is do you have a send connector named "To Office 365" (or similar) and more importantly that has as address space the contoso.mail.onmicrosoft.com ?? That is on premises.

yes on our On-Premise Exchange ECP

Mail Flow > Send Connectors > Outbound to Office 365 (Enabled) > *Address space > contoso.mail.onmicrosoft.com

email the user routing address directly and see if it works: johnsmith@contoso.mail.onmicrosoft.com

and i mean the smtp address and not the johnsmith object from the GAL

see if it works

we need to see if it's a problem with the contoso.mail.onmicrosoft.com routing (it does not look like) or with the AD object.

do a get-remotedomain |fl and see if the *onmicrosoft is there and set as targetdeliverydomain

if the above doesnt work / shows some things missing re run the HCW

solved it, it was a certificate issue, i checked the Connectors on the Exchange online and the settings didn't match up.

the connector from O365 to On-Premise was the issue

Turns out the certificate i was selecting was a Self signed certificate.

i recently inherited this system and it turns out the real certificate had no friendly name so it appeared invisible in the list (how annoying)

so in the certificate list it was showing the "invisible certificate" as a white space and above it the Self signed, i was selecting the self signed thinking it was the 3rd party cert.

Thanks for your time helping me with this issue.

Gordon

Great stuff. Yes that makes perfect sense. You should enable the public cert for smtp before running or re running the hybrid