3CX v20 update 6, 128sc, Ent, about 1200 actual 3CX users, self-hosted on prem (Linux vm under VMware).
Unless this has changed recently (we're on v20u6), if a user is created in our hybrid AD/Entra environment, and an existing user in 3CX with a matching email address isn't found, the M365 sync creates a new 3CX user. I refer to these users as "dummy users" because the Extension number resulting from the sync isn't the one we want to use. In some cases we don't even want a 3CX user for the domain user account. Since once a 3CX user is created, you can't change the Extension number. Yes - there are some configurable options for what extension to use when the sync creates a new 3CX user, but it doesn't meet our needs. For instance, we have several ranges of numbers in our dial plan, some are DID and some aren't. We try to assign a user's Extension by departments with blocks of number ranges reserved for each. There are also many users who don't need a DID, their Extension number comes from a range of numbers that aren't in the number ranges we have. Some AD/Entra users won't even have a phone, so we don't want a 3CX user created for them.
Note: In 3CX v18, the M365 sync process didn't work like described above. We could enable M365 SSO without it causing the dummy user to be created. The only real dependency here was to make sure the 3CX user's email that I manually created matched that of an AD/Entra user. If not, SSO wouldn't work for that user. In other words, enabling SSO under the earlier 3CX version didn't cause a dummy user to be created.
Our onboarding workflow has the user being created in the AD/Entra before I (as the 3CX admin) have all the configuration details to be able to correctly create the user. So, every day I see up to a dozen dummy users that need to be deleted before I can create the user with the correct configuration - especially the Extension. It can be several days between when our domain admins create the user in AD/Entra and when I create the 3CX user, during which time I ignore the dummy user. Also, because if I delete a dummy user one day, a new one will be created again using a new Extension when the next M365 runs. It's much less work for me to leave the dummy user in place until I have the correct details so I can create the 3CX user. AD/Entra users that won't have a phone will never stop being created.
Now, under FUP (Fair Usage Pricing), the dummy users being created by the M365 sync results in significantly more 3CX users than we want and have no control over being created. I estimate that we currently have about 1200 actual 3CX users but close to 1900 users are in the 3CX system. The majority of the difference of 700 users are users that shouldn't have an Extension assigned but due to the M365 process we can't prevent the dummy user from being created.
In anticipation of replies to this thread suggesting we change our processes, especially if it requires a change to our domain structure, I've been shut down by the domain admins. Also, I have to ask why was the change made to the M365 sync process that as of v20 causes dummy user creation? It didn't use to work this way in previous releases. Why can't there be an option in the M365 integration config to select whether or not to create the 3CX user if it doesn't already exist? Seems like this is an unnecessary dependency that I know doesn't only affect my organization.
The above matters because the FUP for our 192sc license allows for up to 1344 users. With our user count being 1860 as of today, FUP would require us to have a 512sc license at more than double the cost.
Unless this has changed recently (we're on v20u6), if a user is created in our hybrid AD/Entra environment, and an existing user in 3CX with a matching email address isn't found, the M365 sync creates a new 3CX user. I refer to these users as "dummy users" because the Extension number resulting from the sync isn't the one we want to use. In some cases we don't even want a 3CX user for the domain user account. Since once a 3CX user is created, you can't change the Extension number. Yes - there are some configurable options for what extension to use when the sync creates a new 3CX user, but it doesn't meet our needs. For instance, we have several ranges of numbers in our dial plan, some are DID and some aren't. We try to assign a user's Extension by departments with blocks of number ranges reserved for each. There are also many users who don't need a DID, their Extension number comes from a range of numbers that aren't in the number ranges we have. Some AD/Entra users won't even have a phone, so we don't want a 3CX user created for them.
Note: In 3CX v18, the M365 sync process didn't work like described above. We could enable M365 SSO without it causing the dummy user to be created. The only real dependency here was to make sure the 3CX user's email that I manually created matched that of an AD/Entra user. If not, SSO wouldn't work for that user. In other words, enabling SSO under the earlier 3CX version didn't cause a dummy user to be created.
Our onboarding workflow has the user being created in the AD/Entra before I (as the 3CX admin) have all the configuration details to be able to correctly create the user. So, every day I see up to a dozen dummy users that need to be deleted before I can create the user with the correct configuration - especially the Extension. It can be several days between when our domain admins create the user in AD/Entra and when I create the 3CX user, during which time I ignore the dummy user. Also, because if I delete a dummy user one day, a new one will be created again using a new Extension when the next M365 runs. It's much less work for me to leave the dummy user in place until I have the correct details so I can create the 3CX user. AD/Entra users that won't have a phone will never stop being created.
Now, under FUP (Fair Usage Pricing), the dummy users being created by the M365 sync results in significantly more 3CX users than we want and have no control over being created. I estimate that we currently have about 1200 actual 3CX users but close to 1900 users are in the 3CX system. The majority of the difference of 700 users are users that shouldn't have an Extension assigned but due to the M365 process we can't prevent the dummy user from being created.
In anticipation of replies to this thread suggesting we change our processes, especially if it requires a change to our domain structure, I've been shut down by the domain admins. Also, I have to ask why was the change made to the M365 sync process that as of v20 causes dummy user creation? It didn't use to work this way in previous releases. Why can't there be an option in the M365 integration config to select whether or not to create the 3CX user if it doesn't already exist? Seems like this is an unnecessary dependency that I know doesn't only affect my organization.
The above matters because the FUP for our 192sc license allows for up to 1344 users. With our user count being 1860 as of today, FUP would require us to have a 512sc license at more than double the cost.
