AD Photo Synchronization with Windows 10

By default, the Windows 10 (1607 in the example images below) user profile picture shows a blank person picture. This can be changed by having a group policy pull down a picture from Active Directory and set it for the user for each workstation they log into. There are two major steps that this involves:

  1. Import user photos into Active Directory
  2. Deploy PowerShell script using Group Policy Logoff Script

Import user photos into Active Directory

The first thing to do is import the user photos into Active Directory. I’ve followed this guide here,, in order to use PowerShell for the import. You will require using Active Directory Module for Windows PowerShell in Administrator mode. This will essentially save the picture in the “thumbnailPhoto” attribute for that user in Active Directory.


Note: The thumbnailPhoto attribute max size is 100k, so please ensure your photos are less than that size. If you try to import a picture that is over 100k, you’ll receive the following error, “Set-ADUser: A value for the attribute was not in the acceptable range of values”. Reference:

Running the commands successfully should give no errors as per the example image below:

To find out if the user already has a photo in AD, see the images below for the difference between not in AD and in AD for the user’s thumbnail photo attribute.

Deploy Powersheel script using Group Policy Logoff Script

Now once the pictures are imported into Active Directory for the users, the PowerShell script found here,, can be used for the Group Policy Logoff scripts. This will essentially run the PowerShell script when the user logs off a machine. The PowerShell script will check AD if the user has a thumbnail photo, retrieve it, and set it as the current Windows account photo for that user.

Create a new GPO and add the logoff script. The logoff scripts location can be found User Configuration -> Policies -> Windows Settings -> Scripts (Logon/Logoff). Add the PowerShell script to the “PowerShell Scripts” tab with no parameters. As mentioned in the original blog above, it is recommended to place this as a logoff script for two reasons:

  1. It prevents any impact to user logons which can be very important in an enterprise environment.
  2. The picture will only appear during the next fresh logon anyways. This shouldn’t be an issue especially if it’s the same person using that workstation all the time.

Once the PowerShell script has been added, the GPO settings will look something similar to the following image below.

Once the GPO has been linked to an OU that contains the user’s object in AD, any workstation that the user logs into will run the PowerShell logoff script and the user’s photo will appear in the logon screen and the picture placeholder on the start menu.

If your users don’t have local admin on their workstations, then additional steps need to be taken for the Group Policy object that was created. This is pretty typical of enterprises to not allow their users to be local admin on their workstations. In this case, we will switch the GPO to attach to an OU containing workstations instead of an OU containing users. The reason why the PowerShell script alone won’t work for users that don’t have local admin, is due to registry key permissions that are needed for the PowerShell script.

Using this guide,, permissions can be set for the needed registry key and sub keys. In the same GPO, add the registry key by going to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Registry and clicking “Add Key…”.

Copy and paste “MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AccountPicture\Users” under “Selected Key” or browse to it manually and press OK.

Go to “Users” and select “Allow” for “Full Control” and click “OK”.

Select “Replace existing permissions on all subkeys with inheritable permissions” and click Ok.

You will then see the registry key under “Registry” in the Group Policy object.

Then under the same GPO, go into Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy and enable the “Configure user Group Policy loopback processing mode” for Merge mode. This will essentially allow the PowerShell logoff script to still run for users even if the GPO is linked to an OU that contains workstations only. Merge mode will still allow the user’s regular user based GPOs to still apply. For a good explanation on Group Policy loopback processing, check out this link:

The group policy object “Settings” tab should look like the one below once: the Registry key has been added with the appropriate permissions, loopback processing has been enabled, and the logoff script has been added. Again, ensure that this group policy object is linked to an OU with workstations rather than an OU with users.

If you take a look at the registry key, MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AccountPicture\Users, for a workstation that doesn’t have the above GPO applied, “Users” won’t have Full Control of the Key and sub keys.

Once the GPO is applied, “Full Control” will be given to the “Users” group for each workstation that the GPO applies to.

The “Users” key and the sub keys below are what is given permission for each non local admin user in order to run the PowerShell logoff script successfully under the user’s permissions.