Sp-dev-docs: API management (admin) - [Version]:16.0.0.8901 - Another object with the same value for property identifierUris already exists.

[ypcode]

Hi,

Category

• [x] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

After creating a SPFx solution that needs to access Microsoft Graph, I wanted to go to admin portal to approve permissions

Observed Behavior

I initially had something similar to #3823 (permission entry already exist), but then I got something different with no clue how to fix it

error: {code: "-1, Microsoft.SharePoint.Client.UnknownError", message: "Unknown Error"}

I get the following messages on the central admin page

And I can't see any of the app permission requests that are supposed to appear with my SPFx packages...

Steps to Reproduce

Whatever I can try now I always get this unknown error message on the app permissions page

Could you please help with this ?

Regards,
Yannick

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[mirkori]

We are having the same issue since a few days.

Before we did have the Error "Another object with the same value for property identifierUris already exists."

[ypcode]

Exactly @mirkori , I'm more confident since I'm not alone :D

Actually I got the "Unknown Error" because I tried to remove multiple entries in the Azure AD after I saw this message.

I restored them using the AzureAD Powershell and now I get back the same message

I checked on another brand new developer tenant and I get exactly the same issue

[luismanez]

Same issue here. Also is weird that I´m seeing 2 Azure Ad Apps registered as "SharePoint Online Client Extensibility Web Application Principal"

[ypcode]

I see it 6 times

Actually my SPFx app specifies 3 permission requests, and I deployed it two times... I really suspect it is related to that...

[luismanez]

Seems so! I always thought there should be only one App registered that way for all the spfx solutions using aadHttpClient...

[ypcode]

It looks like it is what the error message says somehow...

[ypcode]

I edited the title since the real issue is really this one...

[frnk01]

Can confirm same issue on multiple tenants.

[ypcode]

Exactly the same issue on my two dev tenant and my prod tenant

[rob-windsor]

Same issue.

[spdavid]

My workaround was to view the console when running my SPFx webpart and found out what clientId it was trying to call. Then deleted all the duplicates except the one that my webpart was actually using. Waited about 15 min and i got it working.

[NickSevens]

Have the same issue - resulting in my webparts throwing the error

Error: To view the information on this page, ask a global or SharePoint admin in your organization to go to the API management page in the new SharePoint admin center.

[mirkori]

@spdavid Thank you very much that workaround is working! Anyway the underlying issue still exists.

[NickSevens]

@spdavid @mirkori where do you find the client id that's being called? can't find a log for it

[spdavid]

@spdavid @mirkori where do you find the client id that's being called? can't find a log for it

In chrome in the developer tools under the console I was able to see the error when using the graphClient. You will find the id in the url that is referenced in the error information.

Example
var graphClient = await this.props.ctx.msGraphClientFactory.getClient();
let data = await graphClient.api(your graph call).get();

[NickSevens]

I restored the app, but apparently all my API permissions have been removed from the API management page. Existing apps don't work anymore...

[spdavid]

@NickSevens

Thats a scenario that i did not have as i only had my apps and no existing ones.

You can restore the groups using powershell and hopefully you get the permissions back.
https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-restore-deleted

[frnk01]

Anyone looking this up? @VesaJuvonen @patmill

[NickSevens]

Got it to work by:

• deleting all "SharePoint Online Client Extensibility Web Application Principal" apps except the one referenced in the mentioned console messages (thanks @spdavid)
• re-deploying SPFx apps to the app catalog
• re-approving permissions in the API management page

[ypcode]

On my side, by doing so, I now see the app permissions but I still have a "Unknown Error" message and when I try to approve the permissions I get this

I will try restoring all the apps and try it one more time.

[ypcode]

Ok regarding this last issue, I did not realized that I needed to recreate the app principal for restored apps

I did it and now it is working ! Thanks all for your inputs.

I leave the issue opened since, according to me, the root cause of all this is still an issue !

[Olena-In]

I have the same error message "Another object with the same value for property identifierUris already exists." on my tenant. I have created a fresh test tenant and I reproduced the issue within 10 minutes:

1. On a fresh tenant create an app-catalog
2. Just go to the API management page and wait for some time. 2 error messages will appear. If I go to "App Registrations" page, I can see 2 "SharePoint Online Client Extensibility Web Application Principal" applications.

[ypcode]

Moreover, I don't know if it is how it is supposed to work but the new app permissions requests are recreated each time I update my application in the app catalog...

[rob-windsor]

@ypcode That page functionality is sub-optimal. That's a known issue which I really hope will be addressed soon.

[Olena-In]

I found a solution for my "Another object with the same value for property identifierUris already exists."

Here it is:

1. Take a look at how many applications 'SharePoint Online Client Extensibility Web Application Principal' you have and which application has IdentifierUris = {https://microsoft.spfx3rdparty.com}

Connect-AzureAD
Get-AzureADApplication |? {$_.DisplayName -eq 'SharePoint Online Client Extensibility Web Application Principal'} | Select ObjectId, AppId, IdentifierUris

1. Set IdentifierUris of all 'SharePoint Online Client Extensibility Web Application Principal' to an empty array

$emptyValue = New-Object 'System.Collections.Generic.List[string]'
Get-AzureADApplication |? {$_.DisplayName -eq 'SharePoint Online Client Extensibility Web Application Principal'} |% {Set-AzureADApplication -IdentifierUris $emptyValue -ObjectId $_.ObjectId}

1. Wait for 5-10 minutes and repeat the step 1.

On my 3 different tenants the AppId which has IdentifierUris = {https://microsoft.spfx3rdparty.com} on the step 3 was different from the step 1. Now if I go to API Management Page, I have no errors and I have already granted permissions and they work.

Please note: if you deleted and then restored some apps, don't forget as @ypcode said to recreate the app principal for restored apps. It will not work without it.

Hope that helps.

[lucabandMSFT]

Guys, thanks for provide your feedbacks and investigate on this issue. couple of things:

1. there's actually no reason why you would end up with more app principals with the same name. we are doing some investigation and I will report back findings here. It looks like you guys are unblocked at this time, is that correct? Regardless if someone find him/herself in that situation again would you mind sharing the repro steps on how you ended up in that unworking state?
2. yes, we are aware of the sub-optimal capabilities of the "API Management" page. As mentioned in the 1.8.2 release notes we are releasing fixed capabilities of that page that will not duplicate the entries if they already exist.

Thanks again!

[ypcode]

Hi @lucabandMSFT,

For me there was nothing special done to have the errors:
On 3 tenants ( two DEV tenants created this month ).

• I created the app catalog site
• I deployed a SPFx solution having the webApiPermissionRequests property set in package-config.json to

    "webApiPermissionRequests": [
      {
        "resource": "Microsoft Graph",
        "scope":"Files.ReadWrite.All"
      },
      {
        "resource": "Microsoft Graph",
        "scope":"Calendars.Read"
      },
      {
        "resource": "Microsoft Graph",
        "scope":"Mail.Read"
      }
    ]

That's the first solution deployed on these tenants with this property.

• Once deployed, I went the the API management page of the admin portal
• It initially says, it has to be initialized. (can take up to 10 minutes)
• I come back about 20 minutes later and the error [Version]:16.0.0.8901 - Another object with the same value for property identifierUris already exists. was already displaying twice (see screenshots above)
• Going to the AAD portal, I see the SharePoint Online Client Extensibility Web Application Principal displayed 6 times

(By the way, it seems like it adds the permission requests when adding the package, and once again when clicking the "Deploy" button)
(As mentioned above, I suspect it appears 6 times since there are 3 permission requests, deployed twice)

The work around, as posted, by the various folks here is:

• Identify which client Id is used by the SPFx solution (in the console log, see the error when trying to call the Graph in my case)
• Remove all other SPO Extensibility apps from AAD portal
• The error disappers on the API management page and we can now approve the permission requests

Hope that summary helps !

[NickSevens]

@lucabandMSFT as for the repro steps, there was nothing we did at all. We have an application that's been running for a couple of months, and suddenly stopped working yesterday morning. I saw an error message regarding App permissions in console, so went to check in the API management page. That's when the error started showing there.
Moreover, it seems that every time I refreshed the API management page, a new SharePoint Extensibility ... app registration was created in AAD (I ended up with 9 instances of it).

[spdavid]

@lucabandMSFT

In my case i was using pnp xml to deploy the permissions. Every time i ran the script it created a new
'SharePoint Online Client Extensibility Web Application Principal' application
eg.

[lucabandMSFT]

ok guys, thanks a lot. We are investigating on this and will report back findings ASAP

[wobba]

I removed 4 entries which was different from the id in the console, and still get error in the SPO admin page, or using the CLI to list requests. I'll just let this one sit and wait for the findings. I'd be fine re-creating "SharePoint Online Client Extensibility Web Application Principal" even, as the tenant I'm working with is not using it yet - until now ;)

[wobba]

@lucabandMSFT did you guys figure something out, or is there a way to remedy this ourselves - deleting all SharePoint Online Client Extensibility Web Application Principal for example to have it recreated. Ideally would need this fixed in a clients tenant this week, but understand if it's more difficult.

[lucabandMSFT]

sorry for me being late in the answer... we did find a race condition and we temporarily put a fix in place while we are making a more robust fix. at this point no new object should be created.
if you have a duplicated object and you have the issue try to use the following steps to fix it:

• go to the API Management page in SPO Central admin (https://contoso018a-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement), select "view page source" and search for "spfx3rdPartyServicePrincipalId. Example from my tenant "spfx3rdPartyServicePrincipalId":"ab5c9c38-f75f-4c45-896d-7a5d8015f55e"

• copy that ID. go to the AAD portal and DELETE the one which ApplicationID IS NOT the ID copied. that will leave you with the right one

that should be enough. now if you have ALREADY deleted the "right" app id you will have to use the recycle bin functionalities that AAD has to bring that back. you can use PowerShell (it's actually integrated in the AAD portal so you don't have to install anything) to retrieve the right object back. More information on the right API to call here: https://docs.microsoft.com/en-us/powershell/module/azuread/restore-azureaddeletedapplication?view=azureadps-2.0

[wobba]

Thank you @lucabandMSFT :D

[ghost]

Hi,

Visiting the new API Management page should resolve any issues that you've had in the past. Depending on the state of your AAD tenant, you may have to reapprove permission scopes in the UX.

Please open a new issue if you're still seeing this problem.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues