On Premise user created with proper UPN but once DirSync'd to Office 365 we notice the wrong suffix.

What kind of suffix does the user get in O365, does it match the default domain?

No but it is an accepted domain.

So it seems like some sync rule is doing this. Have you reviewed the dirsync/addsync rules, you can temporary disable any custom/modified ones to see if it makes a difference.

It turns out that the user is created on premise (by FIM) with no User Principal Name

Oddly, the UPN given in the cloud is not the default domain.
There must be some logic in dirsync to choose that?

If no UPN is present, it will use the SamAccountName. But the domain part should be the default one, that's why I asked you above. My bet is some rule in FIM is making this happen.

FIM is making it blank yes.  It is supposed populate it later in the day (full day to on board) on premise.
Makes sense that SamAccountName is the prefix used for UPN
the rule in DirSync looks like this for UPN sync:

cd.user_inetOrgUser:dn,sAMAccountName,userPrincipalName->mv.person:userPrincipalName

If I create a test user (leaving FIM out of the picture) with a blank UPN the same thing happens.. so I would think I would lean toward DirSync.. Thoughts?

Oh, I thought you use FIM for the sync as well. Anyways, seems I can repro this on one test tenant. When the user doesnt have UPN populated, the domain part does NOT correspond to the default MSOL domain (Get-MsolDomain | ? {$_.IsDefault -eq $true}), but seems to automatically pick the federated domain.

I'll test with non-federated domain later, if I manage to find a test tenant :)

there are 5 federated domains in this case and this one is not the default either.
has me stumped.

Vasil,

In your case what is the 'DC=Domain'?

wow where do you find that mapping?!

I can ask a new question on that. it is out of scope.
:-)

Vasil I opened this question
https://www.experts-exchange.com/questions/28688685/How-do-I-find-this-DirSync-mapping.html

If UPN is not assigned, synched user would have UPN suffix from Distinguished name (DN).

In Active Directory, the default UPN suffix is the DNS name of the domain in which user account created.

https://technet.microsoft.com/en-us/library/cc739093(v=ws.10).aspx

That's on the 'In from AD - User AccountEnabled' rule (using AADSync on that this machine). No need for new question, you got the answer yourself :)

Yeah but my DirSync does not show this detail (is it because you have the new AADSync?)
Source                : {sAMAccountName, userPrincipalName}
Destination           : userPrincipalName
FlowType              : Expression
ExecuteOnce           : False
Expression            : IIF(IsPresent([userPrincipalName]),[userPrincipalName],
                        IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))

Where does it show it here? or is this not the correct place to look?

This is the mapping when you are using Dirsync. Now, editing the rule extention is a different matter, and I have no idea how to do it :)

You can simply map another attribute to use as UPN, but that will affect every object, so be very very careful with that. Or you can just replace it with direct mapping UPN->UPN, so that objects without UPN will not sync. But better yet, ask the gurus at the FIM forums on TechNet: https://social.technet.microsoft.com/Forums/en-US/home?forum=ilm2

I just want to see where that default mapping is in DirSync - i dont want to change it.
I don't see the below like you..

Source                : {sAMAccountName, userPrincipalName}
Destination           : userPrincipalName
FlowType              : Expression
ExecuteOnce           : False
Expression            : IIF(IsPresent([userPrincipalName]),[userPrincipalName],
                        IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))

What you see there is just the rule 'name', the actual function is not exposed. But yes, this is the mapping that explains this behavior.

so how did you expose it?  can you tell i really want to see that lol

I didn't, the one I pasted is from AADSync. I'm just assuming that it does the same thing, as we have actually confirmed with our tests. Afaik, those functions are 'hidden' inside some DLL for the dirsync client, but if you want a definitive answer, post this on the TechNet FIM forums where the gurus are :)

The behavior makes sense, although I've always assumed that this is done on the service side. Now I know its client side, and that we have control over it.

There's some veeeeery old documentation here: https://technet.microsoft.com/en-us/library/cc720667(v=ws.10).aspx