Ability to update the user's email aliases (proxyAddresses attribute).
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)
Work has started on this, but it’s much more complex than it first appears. It’s unlikely to be available before Q2 2020.
Is there any update about this feature request? We are moving from SDS to Graph API. With SDS, we are asigning an email alias to every user, but there is no way right now to achieve this goal with Graph API.
It's really annoying not being able to do this with the API, we don't want to mix our Java-Graph-API solution with PowerShell scripting.
Morten Brørup commented
If it can be done by PowerShell, why not by the Microsoft Graph API?
Microsoft, you should take "public cloud" more seriously, and that means open APIs (like Microsoft Graph), not proprietary script languages (like PowerShell). It looks like Microsoft Graph is a second class citizen compared to PowerShell, when it comes to programmatic access to Azure AD.
A real must-have (and for groups too, pretty please?)!
Especially if you haven't activated Exchange Online, you cannot remove a corrupt ProxyAddress. This is very annoying because DirSync keeps telling is has sync issues, but we cannot fix them.
Patrick Norman commented
Agreed, we need this feature, it is integral to allowing users the ability to have self-service password resets.
David Conradie commented
I notice even the latest release of the Microsoft Graph doesn't support this capability. And as far as I can see, there's still no other API that does. Surely this is a vital function - what gives?