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]"
}
}
}

The collection size of a request to `/users` cannot be feasibly limited.

Our active directory has tens of thousands of entries. The API only enables retrieving 100 entries per request. Getting ALL the entries takes a long time and I don't need them ALL. Unfortunately, the options for filtering the request are quite chintzy.

I can use the eq (equal) filter, which would be fine if looking for a single user, but I'm trying to limit the resulting collection to a group of users (e.g. to users who's displayName contains a substring, or where surname is not null). I cannot even use the not equal filter. I receive the following reply:

"Unsupported property filter clause operator 'NotEqualsMatch'."

`endswith` is not supported. regular expressions are not supported. `search.in` is not supported.

Not to mention, the user object only has a few useful properties.

I am develop a app with message extension that could help gather some information based on context, e.g. when this message extension is triggered inside a 1-on-1 chat , it needs to know the user information of the other participant in the chat.

There is already /beta/chats/{chatId}

But unfortunately, there is no way to know the exact chat Id the message extension is triggered from. There would be an event named as "composeExtension/query" sent to my bot endpoint with payload that contains a "conversation id" but it could not be used to retrieve chat directly.

And there is no participant information provided in chat info object.

I hope :

1. "composeExtension/query" event should contain chat Id if this message extension is triggered inside a chat

2. Chat info should contain participants information
2.