I would like to be able to fully migrate my AD users to the cloud, so that when I use them to log into an AzureAD Joined Machine, the whoami CMD properly returns AzureAD\fristnamelastname. Right now there are hidden attributes accociated with the previously AD synced user, that causes the whoami CMD to return DOMAIN\username. This is preventing cloud migrations.

Response I received suggesting that I contact this team.

"This a known gap, that we're reviewing. Even though you have migrated the user from AD to Azure AD, the onprem SamAccountName is still intact on the user object, among other on-prem AD attributes. As a result, Azure AD picks those details and shows domain/user instead of AzureAD/user. This attribute cannot be modified or cleared through Graph APIs at this point, so there's no way to change the behavior

Please file a UserVoice suggestion on MS Graph for this so that our teams can get the feedback and prioritize it as needed"

If you have a tenant with a lot of users or a SaaS platform that works with millions of users accounts in Microsoft, it is extremely painful and time consuming to pull/sync profile images from Microsoft Graph. Doing live queries against Graph for photos are also causing additional strain on the Graph infrastructure and end users suffer the performance penalty of a service having to query another service first. So it is ideal to sync images in some cases to local systems for performance gains.

Based on testing that I did I calculated that fetching photos on 300'000 users can take up to 4 hours. Reason for this is because you first have to fetch all the members and then fire a separate query per user to https://graph.microsoft.com/v1.0/users/{userid}/photo/$value to fetch the photos, while staying within the throttling limits of Graph.
The other problem is also that the query to fetch the photo is blind as it may not return a photo as the user does not have a photo. But since I do not know if the user actually has a photo, I am forced to fire them blindly and then based on the response I will know if the user has a photo or not.

So, to resolve this two things would be required:
a) The user object needs a photo property populated with a last-updated date or etag.
This will tell me firstly, the user actually has a photo, stopping the need for a blind query against $value, and then secondly, is the photo the same as the previous time queried based on the photo property value.

b) Delta queries and subscriptions need to adhere to the photo property change of the user.
This will allow me to setup a web hook or timer job that will only query and work with user records that actually got changed, reducing the need for me to pull all user accounts from graph and then in turn reduce the amount of calls required.

would like to have a filter on the users api of Microsoft Graph API, where I will be able to filter the users based on onPremisesSamAccountName, which is currently not available with Graph API.

We have the internal employee id to be stored with onPremisesSamAccountName variable which is present in users API of Microsoft Graph. We are trying to filter with onPremisesSamAccountName property to filter based on the internal employee id. Currently we are not able to do that with Graph API but we really need this to be workling or would be happy if we get know any possible workarounds if available

https://graph.microsoft.com/v1.0/users?$filter=onPremisesSamAccountName eq '[some-id]'&$select= userPrincipalName,displayName,department,jobTitle,companyName,onPremisesSamAccountName,....[more list of fields for select]
The expected outcome is to show the required result but the response what we got is as follows

{
"error": {
"code": "Request_UnsupportedQuery",
"message": "Unsupported or invalid query filter clause specified for property 'onPremisesSamAccountName' of resource 'User'.",
"innerError": {
"request-id": "[request-id from request]",
"date": "[date on which request is made]"
}
}
}

At present it is possible to update a users Office 365 profile photo fairly simply using the Graph API and a short bit of PowerShell.

However, when the photo changes it does not automatically feed through to Sharepoint Online. There is seemingly some unknown set of criteria for this to happen, such as making a user login to Sharepoint directly, which is not something our user base ever does.

I have been getting around this by running scripts that make use of the CSOM libraries to generate and upload the required xThumb images but it would be much nicer if either the process happened by itself, or if there were an API call that could be made to upload directly to the correct location.

Currently Graph insights/used includes in "resourceReference" only the webUrl to the file. This is, for office Documents usually a link to a browser based view.

This is not very useful if you need the actual file url. For other files, eg html files, it points to the display-form in sharepoint, and not the actual file, eg
https://postat-my.sharepoint.com/personal/u11q12ppostat/Documents/Forms/DispForm.aspx?ID=3256

Also, for some reason, DocumentSets are included in the "used" results also.

So i would suggest to also add the actual url to the file to the resourceReference (additionally to a webview, as you do not always use graph from inside a browser, and correct the weburl accordingly, as of course also jpeg files and html files, ... can be directly viewed in a browser, and don´t need to be directed to a "dispform".)

remove the DocumentSets from Results (as these are not "used files")