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"

https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/entity-and-complex-type-reference#user-entity shows that we can GET, POST and PATCH the "otherMails" attribute of a user object. otherMails is described as "A list of additional email addresses for the user", which makes it sound like the user's email aliases. However, if you set this attribute, then look at the user in the Office365 Admin Center or Powershell, you see it's actually the "Alternate Email Address" attribute: i.e. the contact address required for admin accounts. In the Graph API the attribute that lists the email aliases is "proxyAddresses" and this is read-only (i.e. only supports GET). It's been explained to me by Microsoft support that the proxyAddresses attribute is owned by Exchange Online and there's currently no programmatic access to the attribute except via Powershell. But we could really use an API for this.

Worth noting that the AAD Graph API's current capability looks like a bug. You can programmatically set 'otherMails' (aka Alternate Mail Address) with multiple values, but if you then look at that attribute in the O365 admin UI or via Powershell (set-msoluser), it only accepts and uses a single value.

This has been around since at least 2013 (see https://social.msdn.microsoft.com/Forums/azure/en-US/8bd82025-ef07-479d-9c7a-da0f9b4a75fd/setmsoluser-alternateemailaddresses-issue?forum=WindowsAzureAD)

Currently we are creating users in Azure AD through Azure AD Graph API (from our Identity Manager Application). Also we assign licenses using the same Rest API. Our users, among other thinks, uses Sharepoint Online and Skype for Bussiness Online. All of our users have his mailbox in an Exchange 2010 (on-premise), so they don't have the Exchange Online Plan. For Skype for Bussiness integration with Outlook, it's needed that the mail attribute on the Azure AD object be the same as the mail address in Outlook. The problem is that this attribute is read only throug rest API. Also, in Sharepoint Online, we can't send notifications to these users because they sharepoint profile doesn't have an email address.

So should be possible create Azure AD users with mail. Using Azure AD Connect the mail attribute is syncronized with Active Directory mail, why this is not possible using Azure Rest API?

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.

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.