Few years back, I released a “proof of concept” script that uses the Graph API endpoints to enumerate all shared files, across all user’s OneDrive for Business site collections within an organization. Due to some recent changes in the underlying Graph API endpoints, I have released an updated version of the script. This article goes over the changes, as I will likely forget about them 🙂
The aforementioned Graph API changes can be found here. In a nutshell, the permissions resource, which the script uses to determine whether a file is shared and who is it shared with, has been updated to provide some additional context. The grantedTo and grantedToIdentities properties the script used thus far will soon be deprecated, and replaced with the newly introduced grantedToV2 and grantedToIdentitiesV2, respectively. In most cases, a SharePointIdentity object will be returned now, which compared to the old identity one has some additional properties, such as the “claim” representing the object within SharePoint Online. The screenshot below shows a comparison between the values of grantedTo and grantedToV2 properties.
The changes in turn make it possible to return an unique identifier for the user, whereas previously the script had to return the ambiguous displayName value in some scenarios. Similarly, we will have the siteUser property with sharePointIdentity object value for the output of grantedToIdentitiesV2 as well.
I also took this opportunity to rework the authentication part of the script and get rid of the ADAL dependencies. The Renew-Token function has been updated to use direct HTTPS requests now, instead of the ADAL methods. As previously required, you still have to enter the tenantID, appID and client_secret values. If you prefer a different method, just replace this part of the script with your own code.
Here’s the link to the script: https://github.com/michevnew/PowerShell/blob/master/Graph_ODFB_shared_files.ps1
Hello , Thanks for the great content, but I am curious that this script can process in a tenant that has users up to 5000? Thanks in advance <3
The number of files/items is the usual pitfall, not the number of users. This is why the approach taken within the script is to limit the “depth” of the query… but no guarantees 🙂
You might have to add some throttling controls if the script runs into issues.
This script is good, I’m using on test tenant with a few users it working very well. But once run on 2,xxx users tenant We got Invoke-WebRequest: The remote server returned an error: (401) Unauthorized. after script run about 1 hr. is it because token expiration? I think the way to control scope of users to run report will be useful.
I’m working on an updated version that will support executing against a subset of the users (via CSV or otherwise)
Is it posible to run this on a single user or select users from csv?
You will have to edit the script logic for that… The next version, which I will likely release in few days, has support for that.
A colleague of mine recently found this script and we are using it to find the Everyone claims on all of our ODfB sites. This is great work. Does a similar script exist for all tenant SharePoint sites, excluding ODfB?
I haven’t bothered with SPO, as at the time I wrote it, there was no way to enumerate SPO sites via the Graph API. One day I might update it…
I am getting the following error.
VERBOSE: POST with -1-byte payload
VERBOSE: received 1624-byte response of content type application/json; charset=utf-8
Invoke-WebRequest : The remote server returned an error: (403) Forbidden.
At C:\Users\bills\Documents\script\Graph_ODFB_shared_files (2).ps1:223 char:21
+ … { $result = Invoke-WebRequest -Headers $AuthHeader -Uri $uri -Verbose …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
Make sure you are running the script with the required permissions.
I am getting the same error message. I have assigned the application User.Read.All, Sites.ReadWrite.All, and Directory.Read.All. I initially had it as Sites.Read.All, which gave a different error message, but once corrected, it resulted in the same error as above. I also let it sit for a while so if anything needed to apply on the backend, but no luck. Maybe MS changes some things?
I have no trouble running the script. Double-check your permissions and make sure they are actually reflected in the token.
Change your application permissions to Type “Application” and not “Delegation” then it works.