Author / Simon Doy

Unknown's avatar

Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.
an anime character who has a slight beard and no hair, he is slim. He is happy because he has just solved the problem. The character is detailed and they are sat in a corner office. Behind the is a city scape scene.
by Simon Doy

Power Platform Error: Office 365 Connector – List Group Members Fails with Request_ResourceNotFound


This article details the findings of an investigation into a problem that we had with a Power Platform, Power Apps based solution. The reason for the issue is that this organisation needs to be more secure than most.

The organisation operates under numerous compliance and regulatory standards and the application that was built helped them implement one of their compliance based business process .
This solution happened to be one of the first solutions we rolled out. We hit an issue that we had not seen before. Looking around the Internet, it seemed that neither had many others. So, I want to document it and share what we saw so that others can get up and running faster than we did!
As they say, “Sharing Is caring!”

The issue was that a Power App was using the Office 365 Connector to List Group Members and it was failing with the following error:
Office365Groups.ListGroupMembers failed: { “error”: { “code”: “Request_ResourceNotFound”, “message”: “Resource ’33cd8c47-a8dc-XXXX-XXXX-a2a699b80f66′ does not exist or one of its queried reference-property objects are not present.”, “innerError”: { “date”: “2025-01-03T13:55:43”, “request-id”: “e0d458b3-0292-4624-96dc-10a4cccbe4ec”, “client-request-id”: “e0d458b3-0292-4624-96dc-10a4cccbe4ec” } } }

Checking the resource object id, which was for a user, they certainly did exist! Ultimately it was this that led us to the solution which I will detail below.

The code is shown below:

 
Investigation

We quickly realised that it was down to some sort of permission. One of the problems with troubleshooting is you do second guess yourself and we started to wonder if the problem was down to the users not being a member of a group. Well, one of the things that we need to mention is that the member of the group, was a Microsoft Entra ID Security Group. There are various settings which we checked but they never seemed to be the right problem.

The main issue we had is that we have a iThink 365 Development tenant with Power Platform Development environment and we could not recreate the problem.

Another thing to mention is that if a user was a SharePoint Administrator with a Microsoft Entra ID Role then the problem did not occur. We proved this by giving one of the users who we trusted that right and everything worked beautifully.

Anyway, after a couple of days of investigation between the teams I spent some time looking through all the Microsoft Entra ID policies and settings. I found the following Microsoft article: https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions.
One of the settings mentioned is “Read Other Users” which has the following description:

This setting is available in Microsoft Graph and PowerShell only. Setting this flag to $false prevents all nonadmins from reading user information from the directory. This flag might prevent reading user information in other Microsoft services like Microsoft Teams.
This setting is meant for special circumstances, so we don’t recommend setting the flag to $false.

The article did not explain how to make the change but after some searching an article was found which uses the Entra ID PowerShell module

The two commands that we used were:
Get Authorization Policy
This is used to get the authorization policy to see if the read other user permission was set to false.
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.entra/get-entraauthorizationpolicy?view=entra-powershell

Set Authorization Policy
This is used to set the authorization policy to set the read other user permission to true.
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.entra/set-entraauthorizationpolicy?view=entra-powershell

In turned out that the read other users permission was set to false!
Hurrah if we found something that could well be the problem, such a relief.. now to see if worked.

After a discussion with CTO and CIO who then mentioned some other issues that they were seeing ended up being related to this same setting. We got permission to make the change.


How long does the setting take to be applied?


One of the things that we were not sure of was, how long would the setting take to filter through the users.
Funnily enough it seemed to happen very quickly and when one of the users accessed the Power App it worked first time! So, to be safe give your users about 30 minutes for the change to take effect.

Conclusion


In this article I explained an issue we had with the Office 365 Group Connector which was reading the group membership and the users in the group. The Power App connector was failing.
This article explains how to fix the issue by setting the ReadOtherUser property to true. This is the default setting applied to accounts and it is unusual for the setting to be set to false.

I hope, not that if you are reading this and have this problem, this article will help you quickly resolve it! 😊

An image of person thinking about whether to use which AI Search tool
by Simon Doy

Knowledge Copilot Agents – To use or not to use Azure AI Search?


Introduction

Updated: 14th January 2025 – The guidance has been updated by Microsoft and the Enhanced Search which uses Copilot Semantic Index does not require every user to have a Microsoft 365 Copilot license.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/knowledge-copilot-studio

This article discusses some of the things to consider when deciding whether to use Azure AI Search as the data source for Copilot Agents.
The AI world is moving quickly, and Microsoft is also moving quickly with constant updates and changes to its propositions.

However, one of the issues that we have found at iThink 365 when building Knowledge Copilots for our customers is that the quality of the Copilot and the user experience are directly related to the quality of the search results underpinning it.

Generally, we have used Azure AI Search as our search engine which we have seen has provided dramatically better results for our customers. The reason is the type of search technology underpinning the Copilot. Azure AI Search is built for AI workloads and can be configured to use several different search technologies including Semantic, Keyword, Vector and a hybrid of these search technologies.

However, the use of Azure AI Search does increase the cost of running the Copilot because you are paying for Copilot Studio, Azure Open AI and Azure AI Search resources. Whilst some people would say that this is not worth it due to the increase in cost, it really is the only solution for getting the results that customers expect.

The reason for the Azure AI Search approach is that the base Copilot Studio uses the basic Microsoft 365 search engine when Copilot is accessing knowledge held in SharePoint. This experience uses Keyword based searches to give results and we have found that the experience for customers has not been as good.

However, it is important to keep up to date with Microsoft and their changes. Microsoft have been listening to the feedback from their customers, MVPs and partners and so at Ignite 2024 they announced the introduction of Copilots built on Copilot Studio to use the Microsoft 365 Copilot Semantic Index. This has the potential for really improving the experience for users and brings the experience more inline with what we have seen with Azure AI Search.

There is something to be aware of, to be able to take advantage of the Microsoft 365 Copilot Semantic Index your organisation and users need to be licensed for Microsoft 365 Copilot.
Without the licenses, your Knowledge Copilot will not be able to use the premium search capabilities and therefore Copilot Semantic Index.


 
Questions to help make your decision

So, our decision on whether to use Azure AI Search or not is based on the following questions:

  • Does one user have a Microsoft 365 Copilot license?
  • Are the documents being accessed with knowledge in them, either PDF, DOCX or PPTX and are they less than 512MB in size?
  • Is all the information that needs to be accessed held in supported documents in Microsoft SharePoint?

If the answers to these questions are yes, then my suggestion is to do a proof of concept using Copilot Studio and the premium search experience and test to see if the user experience is good enough so you do not need to use Azure AI Search.

However, if the answer is no to either or following testing the user experience then I would recommend using Azure AI Search to give our customers the experience that they deserve.

Conclusion

I hope that this helps you understand when to use which approach with your Microsoft Copilot solutions, in particular those with Knowledge Copilot and Copilot Agents.