Unifying 3CX with Microsoft 365 - Initial Set-Up - Part 1 of 3

[Keith Winhall_3CX]

In preparation for version 18, we have been working on the synchronization between Microsoft 365 accounts and 3CX. With more and more businesses looking to simplify their working environment, synchronising companies’ 365 accounts and 3CX is an important step. It brings a whole host of benefits including user sync, calendar status sync and the ver...

Continue reading the Original Blog Post.

 

[Benedikt Machens]

Hi,

is it possible to define an Extension inside Azure that is used in 3CX? If you don't want 3CX to selected the extension number sequentially.

 

[ChrisC_3CX]

@Benedikt Machens

is it possible to define an Extension inside Azure that is used in 3CX? If you don't want 3CX to selected the extension number sequentially.

No but you can first have the user created in 3CX with the extension you want and the same email as the one defined in Microsoft 365. This will have the 365 user, with that email, sync to that 3CX extension. That said, if you want to have this done for multiple extensions, you could utilize the extension import function on 3CX before you sync with 365.

Note: Also, selecting the starting extension number is possible but from there onwards it will of course create them sequentially.

 

[StefanW]

Hi,

is it possible to define an Extension inside Azure that is used in 3CX? If you don't want 3CX to selected the extension number sequentially.

unlike in a local AD is the field for "Extension" has been removed in AzureAD. This leave by default only Office Number and Fax Number. First is used for Team Integration by 3CX and must be in an e164 format. This leaves only the Fax number, which might be used by customer for the intended porous and therefore is also out of the race. --> Unfo not

 

[JSlow]

unlike in a local AD is the field for "Extension" has been removed in AzureAD. This leave by default only Office Number and Fax Number. First is used for Team Integration by 3CX and must be in an e164 format. This leaves only the Fax number, which might be used by customer for the intended porous and therefore is also out of the race. --> Unfo not

Could you not use custom attributes/extensions and then use Graph to get the attribute? https://docs.microsoft.com/en-us/gr...tensionproperty?view=graph-rest-1.0&tabs=http

It could be a potential pain-point initially but I'm thinking most companies have some kind of script to auto-add users...this would just be another line in it to add the desired extension unless I'm completely misunderstanding what an extension property is in Azure/Graph

 

[Patrick the phoneman]

unlike in a local AD is the field for "Extension" has been removed in AzureAD. This leave by default only Office Number and Fax Number. First is used for Team Integration by 3CX and must be in an e164 format. This leaves only the Fax number, which might be used by customer for the intended porous and therefore is also out of the race. --> Unfo not

Hi Stefan,
should it not easy to say on 3CX side to take the last 3 digits from the business phone field as the internal extention number (as an option)? Or a preview screen where you can enter the internal numbers?

Cheers

 

[ivan.antic]

Hi,
Can you please confirm which 3cx license (STD, PRO or ENT) eventually one would need to integrate call2teams with 3cx?

Thanks,

 

[NickD_3CX]

Hi,
Can you please confirm which 3cx license (STD, PRO or ENT) eventually one would need to integrate call2teams with 3cx?

Thanks,

Hi!

When V18 Final is released, an Enterprise license key will be required in order to use the Teams integration.

 

[dbradt]

@NickD_3CX @StefanW
howto troubleshoot direct routing?

can you share some tought/info/guidelines on that one?

a test scenario at aws ec2 has current issue:
users are synced and they show up as ms365+teams; firewall checker is running fine. we can't find any problem in the logs.

but direct routing shows as inactive but sip options is ok. calling the 999 vm with teams client indicates it as 'unavailable' ...

 

[Evolute IT]

@NickD_3CX @StefanW
howto troubleshoot direct routing?

can you share some tought/info/guidelines on that one?

a test scenario at aws ec2 has current issue:
users are synced and they show up as ms365+teams; firewall checker is running fine. we can't find any problem in the logs.

but direct routing shows as inactive but sip options is ok. calling the 999 vm with teams client indicates it as 'unavailable' ...

Have you configured the domain and SSL certificate correctly? We configured it within minutes using the 3CX script.

 

[NickD_3CX]

@NickD_3CX @StefanW
howto troubleshoot direct routing?

can you share some tought/info/guidelines on that one?

a test scenario at aws ec2 has current issue:
users are synced and they show up as ms365+teams; firewall checker is running fine. we can't find any problem in the logs.

but direct routing shows as inactive but sip options is ok. calling the 999 vm with teams client indicates it as 'unavailable' ...

Hi!

First, what Frederick said.

Moving on from that, after you execute the scripts generated by 3CX, you *may* have to wait up to 24 hours for the changes to take effect on the MS Teams platform.

To troubleshoot after this, I'd recommend enabling Verbose logging in the 3CX Settings, and then checking the Activity Log to see if any calls are reaching the 3CX Server.

Another simple test would be to try and call from a 3CX extension to Teams Extension to see if that direction works.

 

[sheldonssbr]

Hello guys
Can someone please confirm me if it is a mandatory requirement for the M365 / Azure AD user to have a paid license on the Microsoft side?
In this case, We need only use the SSO feature.

I ask this because we cannot "see" in 3CX users without a license assigned in the M365 tenant.
Thanks

 

[NickD_3CX]

Hello guys
Can someone please confirm me if it is a mandatory requirement for the M365 / Azure AD user to have a paid license on the Microsoft side?
In this case, We need only use the SSO feature.

I ask this because we cannot "see" in 3CX users without a license assigned in the M365 tenant.
Thanks

They should appear just fine:


Read the note in Step 4 though:
https://www.3cx.com/docs/microsoft-365-integration/#h.qstanjnw2wlt

[EDIT]
This was also clarified here: https://www.3cx.com/community/threa...ers-via-azure-ad-enable-sso.80076/post-368735

 

[Judako]

Hi Stefan,
should it not easy to say on 3CX side to take the last 3 digits from the business phone field as the internal extention number (as an option)? Or a preview screen where you can enter the internal numbers?

Cheers

Really liking your idea. Take the last x amount of digits (x being what you decided on when setting up your 3cx) from the business phone field and set that as the internal extention number. Having no real option to assign an extention number to a Microsoft 365 User when using this sync is kind of a let down.

 

[Csut12]

What is the 3CX impact of not adding `Mail.Send` MS Graph permission?

The proposed implementation in the youtube video appears to be not good - if I understood correctly, it grants `Mail.Send` to the 3CX Azure App Registration as Application mode. That means the 3CX Azure Application Registration can impersonate *any and all* user `Mail.Send` within O365 organization, as long as have access to that application. This is not user -> user mapping, this is app access = ALL org impersonation mapping.

To make matters worse, to constrain this application permission means manually adding users to an Application Policy that the 3CX Azure Application Registration users can be impersonated as - conceptually this isn't much use because you end up with all users being adding to that group and 3CX Azure Application Registration is back to square one of granting way too wide of send permission. The Application Policy is more useful for when granting Application/Service type apps permissions to a specific user account (like a SMTP mailer or a 3CXMailer account), but loses its meaning when majority of company is added into it.

This `Mail.Send` permission should be moved to Delegated flow, where User123 can grant 3CX permission to send on their behalf. I believe same Azure App Registration can support Application and Delegation permissions from single app registration.

Out of curiosity, what is intended use of Mail.Send by 3CX software? User to self email notification of voicemail?

 

[Benedikt Machens]

What is the 3CX impact of not adding `Mail.Send` MS Graph permission?

The proposed implementation in the youtube video appears to be not good - if I understood correctly, it grants `Mail.Send` to the 3CX Azure App Registration as Application mode. That means the 3CX Azure Application Registration can impersonate *any and all* user `Mail.Send` within O365 organization, as long as have access to that application. This is not user -> user mapping, this is app access = ALL org impersonation mapping.

To make matters worse, to constrain this application permission means manually adding users to an Application Policy that the 3CX Azure Application Registration users can be impersonated as - conceptually this isn't much use because you end up with all users being adding to that group and 3CX Azure Application Registration is back to square one of granting way too wide of send permission. The Application Policy is more useful for when granting Application/Service type apps permissions to a specific user account (like a SMTP mailer or a 3CXMailer account), but loses its meaning when majority of company is added into it.

This `Mail.Send` permission should be moved to Delegated flow, where User123 can grant 3CX permission to send on their behalf. I believe same Azure App Registration can support Application and Delegation permissions from single app registration.

Out of curiosity, what is intended use of Mail.Send by 3CX software? User to self email notification of voicemail?

I think the intention is to send welcome mails, conference mails and other stuff that are not user specific.

You can edit the created app after the wizard has done its job. Multi-Domain usage and so on.