Solved O365 user sync issue

[RussellPTown]

Office 365 sync is a great idea, but not workable for us - and I suspect many others.

The issue appears to be that 3CX is matching the 'email' value from the 3CX extension to the 'username' of the O365 account - where it should use the 'Primary Email Address' attribute instead.

eg I have a user - 'John Doe', he may have the user name [email protected] and use the email address [email protected], 3CX rather than syncing his extension will create a duplicate one with extension number 0001

Hopefully this will get some attention in v16 Update1 ?

 

[StefanW]

I understand what you say, but I am not sure if I agree with you. As in order to have a primary email address an email plan is needed and we can sync all users in the Azure AD. Happy to see what the community thinks about it.

 

[casey_kitko]

Russel,

We haven't had a chance to look at the O365 integration but it sounds like us, and a majority of our customers would have issues. We use [email protected] as the username, and [email protected] as the email address.

I agree that 3CX should pull the email address from the 'Primary Email Address' attribute.

 

[craigreilly]

There is another thread about this as well.
Agree - need to add another field.

We have email already.
Add 'network login' or 'username' or similar.

 

[StefanW]

I am not still convinced that this is general the right solution (or commonly been used). Still open for discussion.

I just looked in my Office 365 Portal ECP and one thing I cannot find (which would a key asset to script an alternative primary eMail address) is Email-Address Policy in the mail flow section. It cannot be that you open every created recipient and do this work in manual manner?

 

[RussellPTown]

Hi Stefan,

Thanks for taking an interest in this.

Anyone with a hybrid exchange setup can still have the email address policy running on the on-premise Exchange. As you say, Address Policies haven't appeared yet in O365 Exchange and probably never will. I suspect there's an argument that people who have Azure AD accounts, but don't have an Exchange mailbox - either via O365 or on prem - and so don't have the primary email address attribute (which I think is your suggestion for why you chose this approach?) would be a smaller number than those who have an alternative email address, although only MS would know for sure either way.

When creating a new user, adding a new default SMTP address is no more onerous than setting group memberships, adding mobile phone numbers, manager details, assigning an O365 licence, etc etc, that are already part of the new user creation process.

One of the things we enjoy about 3CX after coming from an old steam driven Avaya Definity with it's command line and terminal emulator interface, is the simplicity of administration and I can see why you would want to keep things a simple as possible. (And the fact we can buy a whole new 3CX system, including 100+ handsets for less that the cost of the annual hardware maintenance contract from Avaya - and the fact it doesn't take almost a whole full height rack!)

Adding an extra field for 'O365 username' as suggested above would certainly be a solution that would fix the issue for us.

Could the sync process attempt to use Primary Email Address first and then fall back to 'username' if no match is found? That would seem to cover all cases without adding extra fields?

 

[StefanW]

first version of our integration was based on mail (Primary) and then changed to principal name so we can sync non "exchange" licensed Azure AD users...

It is a harder task to check if primary exist and if different from principal or does not exist at all and then pick one existing extension (or more as you can have 10 extensions with the same email in 3cx) and mapp the user ID to them or create new... possibilities over problems as you may can understand.

Lets see, no promises, but I can see a benefit from it, specially when we will go to SSO login to track more from the user in Office 365 then we initially liked to...