The app@sharepoint principal is not resolving in newly created tenants

Brass Contributor

This is a followup thread to a github post ( which has been closed. It has been asked to reopen this topic here.

Thanks to the original creator Michael Jensen for opening this topic in GitHub.


We experienced the same problems in three new developer Tenants we have created in the last two weeks.

Describe the bug

In the elevated privileges page there is an important tip about adding the app@sharepoint user as a term store administrator if you need app-only write access to the term store (I believe @wobba originally wrote about this in a post a couple of years ago).

Unfortunately we were not able to add the app@sharepoint user to the term store administrators group in a couple of tenants that we created in the past couple of days - that account will not resolve in the old and new term store UI (as shown in the following screenshots)

Old page



New page



It appears this issue is not isolated to the term store, as that user would not resolve in other user management areas (i.e. site collection admin, etc.)

What made this even more confusing was I was able to get the app@sharepoint account to resolve in one of our newly created tenants this afternoon, but that only worked via the old term store UI - the other tenant we created yesterday is still not able to resolve that account.

I also tried adding the full username i:0i.t|00000003-0000-0ff1-ce00-000000000000|app@sharepoint and experienced the same result as trying to simply add app@sharepoint.

Steps to reproduce

  1. Create a new tenant
  2. Go to the term store in the SharePoint admin center (you can try this in both the old and new UI)
  3. Add app@sharepoint to the term store administrators and try to resolve that account (and/or save your change)
  4. See the error saying no match found in the old UI (or no error, but no user resolution in the new UI)

Expected behavior

I expect the app@sharepoint account to resolve, so we can continue to use app only principals to write to the term store.

Environment details (development & target environment)

  • Your Developer Environment: N/A
  • Target Environment: SharePoint Online
  • Framework: N/A
  • Browser(s): Chrome v84
  • Tooling: N/A
  • Additional details: N/A

Additional context

My concern is this app@sharepoint account may be in the process of being removed, which means our app only apps will no longer be able to write to the term store (which would obviously be a significant issue).

Thanks for your contribution! Sharing is caring.

9 Replies

@Quantumrunner we have the same Issue within two tenants. The registry of a dummy app doesn't resolve the problem. Also setting -DisableCustomAppAuthentication to false has no effect.


Has anyone another solution?

I am experiencing the same issue in a newly created tenant as well, app@sharepoint won't resolve in the new or old term store experience and Mikael Svenson's workaround is not working unfortunately.  Anyone?  

@AnnieJohnson We have just retested this in a brand new O365 Developer tenant and the same problem occurred.


And yes the workaround from Mikael Svenson' has not been working for this anymore too. Since this was a developer tenant we can not open a ticket there.


If anyone has this problem on a productive tenant please open a ticket and maybe get back here if you get any new status from Microsoft.

@QuantumrunnerI actually did open a support ticket and they essentially copy/pasted the previous fix into an email: 


  1. Create a new app with app-only permissions following
  2. Connect to PNP-Online using the article - Connect-PnPOnline (SharePointPnPPowerShell) | Microsoft Docs 
  3. Please use the URL to connect to PNP-Online
  4. Connected to -admin and was able to resolve Get-PnPUser -Identity "i:0i.t|00000003-0000-0ff1-ce00-000000000000|app@sharepoint"
  5. Added i:0i.t|00000003-0000-0ff1-ce00-000000000000|app@sharepoint as a user in term store

Thank you for being part of Microsoft Family.


I replied with the outputs of the powershell script showing that the app@sharepoint principal does not resolve when connected to admin, but does resolve when connected to the root site.  Regardless the principal is not available to add in the term store.  I am awaiting their next response.

@AnnieJohnson When we did the testing this week we added the SharePoint App with app only permissions to the Admin Site Collection ( ) instead of the root site collection.


Afterwards the user could be resolved in PowerShell by conncecting to  and setting Get-PnPUser -Identity "i:0i.t|00000003-0000-0ff1-ce00-000000000000|app@sharepoint".


But the user still did not show up in the user selection on the modern or the classic TermStore Admin Page.

@Quantumrunner  Here is the latest from Microsoft support.  I answered some basic questions about my particular use case and am awaiting their next reply:


We would like to inform you that the Account app@sharepoint is related to the SharePoint Applications (Auditing logs/Virus check), it is a system account, belongs to the SharePoint Farms infrastructure, it was created to run on all Site Collections/Personal sites to collect auditing information. When the user provides some changes for his own Site Collection, or enables features or activates the site Auditing logs, his own account does not have the write permissions on the SharePoint Farm and this account it will be used to run and collect all the necessary information to be provided to the customer. Microsoft has set up a few security accounts to run in all Farms, in order for our customer to do some tasks, and get the required information. Also it is necessary for user security, for these accounts to always track the Site Collection searching for viruses that can be uploaded into SharePoint. Microsoft will not change that, all Farms have the same configuration and this same system account, and all Site Collections will use this account if they need to do it.


What Activities Should the customer expect from this account?

From the Customer side nothing will be expected, everything will be running normal, as should be, this account will not affect the Site Collection functionality or personal site, all the information on the Site Collection will be secure, and only the Site Owners and all people who have permissions to the site can see the information inside and share the same. This account can be visible if we create an auditing for our Site Collection or personal site. All private information is safe and, nothing will be collected, as we said before this account only gets information for auditing and looks for possible virus attack.

@AnnieJohnson Did you get any more updates from the Microsoft Support?


We did some more testing. We created an Azure AD Application with Site.Read.All Application permission and connected to the SharePoint Central administration (( site using SharePoint Client API (CSOM). Afterwards the user was available.


I'm not sure why this did not work when using the PNP PowerShell library and a SharePoint App (instead of the Azure AD App).



I think I finally have the solution for it!

The tricky part is, that you have ONE term store per tenant, but it behaves independently depending on how you access it  (I mean, depending on the context of the site collection you are accessing it from)








both point to the same term store but differently from what you could expect, they don't behave exactly the same.


After reading this:


I found out the app@sharepoint is created when you add an app file and 'approve' it.
If you add the app file one sitecoll01 and then go to term store using the sitecoll02 URL it won't exist there... but will exist on sitecoll01.


In my case, we were adding the app file to many site collections, but accessing the term store based on the root site collection https://MyTenant/ Is the same term store, ofc. But the account doesn't exist there.


Go figure...

Thanks for this!
Saved me a lot of hours :)