SCim azure integration issue with bad parameters

I already tried submitting a ticket for this, but got told to contact dev support. I'm not a dev, just an admin. So I'm going to try here before jumping into that mess. For some reason there is little online regarding my issue.

I have recently migrated to the new RC SSO webapp that included SCIM integration for auto provisioning. So far it is working well, but it is having some strange issues with cell phone numbers and countries. I have not been able to nail down exactly what is going wrong, and I'm starting to wonder if the default mappings logic is not sufficient. I figured I would loop you guys in since I'm having trouble finding much documentation online so far.

To be clear, our integration is fully configured and is running in update/create mode. We are syncing 42 users currently without issue. The rest(mostly outside the USA) are failing due to country field issues:

SystemForCrossDomainIdentityManagementServiceIncompatible

StatusCode: BadRequest Message: Processing of the HTTP request resulted in an exception. Please see the HTTP response returned by the 'Response' property of this exception for details. Web Response: { "schemas" : [ "urn:ietf:params:scim:api:messages:2.0:Error" ], "status" : "400", "scimType" : "invalidValue", "detail" : "Parameter 'addresses.country' value is invalid." }. This operation was retried 1 times. It will be retried again after this date: 2022-03-31T12:30:12.1417689Z UTC

From the error above, it almost looks like the field isn't not resolving correctly in SCIM on the RC side?
One other item of note, most of our RC accounts are preexisting. About 50 are syncing and updating fine, the rest are failing on country.

Page 1 / 1

Can you pick one of the user data that failed and email me phong.vu@ringcentral.com? The fastest way for me to help is to reproduce the error with my code and tackle the issue or reporting it.

With further tweaking and testing (with help from Phong Vu!!) I was able to narrow this down to the e911 features and localities. I have not been able to fully test the scenarios, but it appears there are multiple things happening.

1) When supplying a phone number in SCIM for provisioning (create), phone numbers within that locality must be available as unassigned extensions. Mobile extensions will not work!

2) Only certain countries are allowed during updates. (so far appears to be USA, UK, CAD. may be more). I have not purchased lines in all localities.

3) There seems to be some kind of correlation between the e911 address and the locality of the phone number. (this makes sense really, but not confirmed)

In the end, I removed all address info from my schema map in azure and things updated properly.

RC still requires hardline licenses for provisioning in SCIM, so that kinda sucks. The problem with this is; When people leave, the line does not go back to an unmapped number. It gets left in limbo on as unassigned phone device(still provisioned). The result is you will periodicly have to go back and manually remove the numbers from the unmapped phones, send them to your pool, and then create new unused extensions. This whole process is slow and tedious due to having to go through the purchasing prcoess for each locality, one by one, even though no purchases are being made. It's hard to believe RC is still like this after all these updates and improvements.

At least I can auto-create users now, and sync metadata updates.

Same issue was reported for [ extension.contact.businessAddress.state ]
https://community.ringcentral.com/answers/111090/view.html

@Ben McBeen > "...In the end, I removed all address info from my schema map in azure and things updated properly. ..." That's not really a "fix".

Reply

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded