The New Entra ID Photo Update Settings Policy for User Profile Photos

Photo Update Settings Policy is Long-term Unified Replacement for Other Controls

Given the historical foundation of Microsoft 365 in several on-premises applications, it probably wasn’t surprising that we ended up with a confusing mish-mash of routes by which it was possible to update the profile photos for user accounts through SharePoint, Exchange, Teams, Delve, PowerShell, and so on. Looking back, it took a surprising amount of time before Microsoft acknowledged that the situation was untenable.

A new approach that worked across Microsoft 365 was necessary. That process began in October 2023 with the retirement of the Exchange Online cmdlets to update photos for mailboxes. Entra ID is now the definitive source of photo information for user accounts and groups and the foundation for the new approach is a set of Graph APIs surfaced as cmdlets in the Microsoft Graph PowerShell SDK, like Set-MgUserPhotoContent.

A New Photo Update Settings Policy to Control User Profile Updates

In June 2024, Microsoft introduced a new Entra ID policy based on the photoUpdateSettings resource to control who can update photos and the allowed sources for updates. Managing the photo update settings policy requires the PeopleSettings.ReadWrite.All scope. The settings for a tenant can be retrieved as follows:

$Uri = "https://graph.microsoft.com/beta/admin/people/photoupdatesettings"
$Settings = Invoke-MgGraphrequest -Uri $Uri -Method Get
$Settings

Name                           Value
----                           -----
allowedRoles                   {}
@odata.context                 https://graph.microsoft.com/beta/$metadata#admin/people/photoUpdateSettings/$entity
Source

The settings shown above are the default. The supported values are described in the photoUpdateSettings documentation.

Controlling From Where Photos Can Be Updated

The source for photo updates can be undefined, meaning that photo updates can be sourced from applications running in either the cloud or on-premises (synchronized to Entra ID from Active Directory). Alternatively, you can set the source to be either cloud or on-premises. For example, to update the settings so that photo changes are only possible through cloud applications, create a hash table with a single item to change the source to cloud and use the hash table as the payload to patch the policy:

$Body = @{}
$Body.Add("Source", "Cloud")
$Settings = Invoke-MgGraphrequest -Uri $Uri -Method Patch -Body $Body

Like any update to an Entra ID policy, it can take 24 hours before the policy update is effective across a tenant.

Controlling Who Can Update Photos

By default, any user can update the photo for their account and the value for AllowedRoles is blank. If you want to restrict who can update photos, you can select one or more directory roles and include the GUIDs for these roles in the AllowedRoles property (a string collection).

The roles defined in AllowedRoles must hold the permission to set user photos. In Graph terms, these permissions are either microsoft.directory/users/photo/update or microsoft.directory/users/allProperties/allTasks (only held by the Global administrator role). The following roles can be used:

  • Directory writers (9360feb5-f418-4baa-8175-e2a00bac4301).
  • Intune administrator (3a2c62db-5318-420d-8d74-23affee5d9d5).
  • Partner Tier1 Support (4ba39ca4-527c-499a-b93d-d9b492c50246) – not intended for general use.
  • Partner Tier2 Support (e00e864a-17c5-4a4b-9c06-f5b95a8d5bd8) – not intended for general use
  • User administrator (fe930be7-5e62-47db-91af-98c3a49a38b1).
  • Global administrator (62e90394-69f5-4237-9190-012177145e10).

All are privileged roles, meaning that these are roles that enjoy a heightened level of access to sensitive information.

To update the photo settings policy to confine updates to specific roles, create a hash table to hold the GUIDs of the selected roles. Create a second hash table to hold the payload to update the settings and include the hash table with the roles. Finally, patch the policy.

$Roles = @{}
$Roles.Add("62e90394-69f5-4237-9190-012177145e10", $null)
$Roles.Add("fe930be7-5e62-47db-91af-98c3a49a38b1", $null)
$Body =@{}
$Body.Add("allowedRoles", $Roles)
$Settings = Invoke-MgGraphrequest -Uri $Uri -Method Patch -Body $Body

To reverse the restriction by removing the roles, run this code:

$Body = '{
  "allowedRoles": []
}'
$Settings = Invoke-MgGraphrequest -Uri $Uri -Method Patch -Body $Body

The result of limiting photo updates for user accounts to the user administrator and global administrator roles means that after the new policy percolates throughout the tenant, any account that doesn’t hold a specified role cannot change their profile photo.

The Teams client is probably the best example. The implementation here is not yet optimal. The block on photo updates imposed by an OWA mailbox policy causes Teams to inform the user that administrative restrictions stop photo updates. If the photo update settings policy restricts updates to specific roles, Teams allows the user to go through the process of selecting and uploading a photo before failing (Figure 1).

A failure to update a profile photo due to policy restrictions

Photo settings
 policy
Figure 1: A failure to update a profile photo due to policy restrictions

An Early Implementation of the Photo Update Settings Policy

Inconsistencies appear in the early stages of implementation. It will take time for Microsoft to update clients to allow and block profile updates based on the photo settings policy. And it will take time for tenants to move from the previous block imposed by OWA mailbox policies. In doing so, you’ll notice that the only restriction supported by the new policy is through roles. The OWA mailbox policy setting allows per-user control and multiple policies can exist within a tenant. The current situation therefore delivers a less granular policy.

Maybe a less granular mechanism will be acceptable if it helps with the rationalization of photo updates across Microsoft 365. However, I can’t help thinking that this is a retrograde step. Perhaps Microsoft will address the need for more granular control through Entra ID administrative units, which seems to be the answer for this kind of requirement everywhere else in Entra ID.


Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

20 Replies to “The New Entra ID Photo Update Settings Policy for User Profile Photos”

  1. Tony, when I understand you right, this new photo-policies would not yet work together with Administrative Units, right? Background: it is still a pain to use Graph in a Tenant where you only have scoped/delegated permissions. The Replacment of “Set-UserPhoto ” with “Set-MgUserPhotoContent” is one of countless examples where we are lost in space as Graph still does not seem to be ready for scoped-permissions (as Exchange Online was from its very beginning…) – or do I miss something?

    1. The new photo setting policy is scoped on administrative roles, not units. At a meeting yesterday, I pointed out to Microsoft that the lack of granularity in the new policy was problematic. I hope to be able to follow this up in an effort to convince the developers to do better.

  2. An issue I’m encountering is this seems to assume humans only. An Azure application with User.ReadWrite.All can use Graph API to set photos.
    But if you apply allowedroles this functionality stops, even if you assign the Azure application with the Azure roles e.g.:

    “source”: “cloud”,
    “allowedRoles”: [
    “62e90394-69f5-4237-9190-012177145e10”,
    “fe930be7-5e62-47db-91af-98c3a49a38b1”
    ]

    My application has fe930be7-5e62-47db-91af-98c3a49a38b1, but still gets:
    Status: 403 (Forbidden)
    ErrorCode: ForbiddenByAdminEditPolicy

    1. I have a case open with MS for this exact reason that it doesn’t seem possible to use in an application context.
      Status: 403 (Forbidden)
      ErrorCode: ForbiddenByAdminEditPolicy

      I doubt I will get a satisfactory response, but maybe it will reach the dev team eventually.

  3. i have the same problem with my application, if i set the permission my script didn’t work. but if i din’t set the permission user change their picture themselve !
    hope Microsoft chnag this rapidly

      1. I’ve just encountered the same issue. I’ve raised it with Microsoft Support and the answer I was given is:

        “The feature you mentioned essentially involves using an application to perform a task that is only allowed by delegated permissions. Making this change would not be a simple feature request; it would require a fundamental change to Entra ID’s role management logic, which is not possible at this time.”

        Essentially it sounds like they took an easy out by implementing restrictions based on Entra ID roles, but it now snookers them for application authentication. I guess it’s not going to happen any time soon. Also, not really a bug, but a bad design decision working as expected.

  4. Nice article, but I am facing some issues that could originate from changing this policy.

    How can I revert it to the default? I feel like I made a mistake trying it.

      1. Yes, but how do I reset the sources, so that any source can be used? Like this?

        $Body = @{}
        $Body.Add(“Source”, $null)
        $Settings = Invoke-MgGraphrequest -Uri $Uri -Method Patch -Body $Body

      2. The text says:

        $Body = ‘{
        “allowedRoles”: []
        }’
        $Settings = Invoke-MgGraphrequest -Uri $Uri -Method Patch -Body $Body

        I assume this is correct. I haven’t tested it since writing the article.

  5. It seems App Authentication is now also working.

    I had to enter the application name into the search box, which made a separate tab appear, where I could select the application.

    After allowing the role itself and assigning the allowed role to the application it seems to work again just like before we set any restrictions.

      1. So for these steps, we still need to assign the application one of the roles above and assign this API permission to the application?

  6. After implementing the changes, thumbnail linked to the synced mail user in EntraID is not replicated from AADSync for those onPrem Exchange mailboxes containing userphoto (AD thumbnail).

    May I know the method to restrict user self-upload, in the meanwhile, allow DirSync account to replicate the changes from onPrem to EntraID?

    1. I’m not sure that the photo ever synchronized from on-premises AD to Entra ID. There’s been so many moving parts with user photo management over the past few years that it would surprise me if seamless synchronization works. You can always stop users uploading photos and do background photo management using PowerShell scripts to upload/update photos for users with on-premises accounts. That should be a pretty easy script to write.

  7. Is there no way to allow both DirSync and Photo updates via cloudapps while blocking users from updating their own profile photos?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.