SharePoint Online UserProfiles and the story about synchronizing with Azure Active Directory–Part 2

2014-06-22 | Toni Pohl

In part one we saw that SharePoint Online (SPO) user profiles are partly synchronized from Azure Active Directory (AAD) automatically. Since an user has no influence on the synchronization process itself there´s an alternative to bypass the whole AAD story. Apps can write directly into specific SharePoint user profiles.

Why bypass AAD?

In some scenarios user data may not be transported via DirSync or ADFS from a local Active Directory (AD) to the cloud. One example would be that user data is only available in an HR system (and not in AD) and shall be used in SPO or SPO apps. Technically there´s a way to accomplish that. Here in part two we show how.


The Office App Model Samples (AMS) project

Actually writing to the SPO user profiles isn´t an easy task. Fortunately a couple of Microsoft people wrote some code samples and provided it on the open source platform codeplex.

The SharePoint and Office App Model Samples in short “Office AMS”
which is available at


In that download developers find tons of samples of HowTo´s for SharePoint and Office tasks. There´s also a PowerPoint documentation available giving an overview of the samples. See vesku-msdn-blog for more information, see Office AMS v2.0 has been released.

The base code

The solution within the Office AMS we´re using is Core.UserProfilePropertyUpdater.

That´s the base for updating user profile information. If we look into the documentation we see that the updating and reading of user profile properties happens via the user profile web service userprofileservice.asmx.

That´s interesting because this service exists since SharePoint 2007 and works with an (deprecated) SOAP Webservice. By now it seems this is the only way. Let´s see if that service is still available with the next version of SPO (which will come next year and I doubt it).

Anyway, the webservice-URL for accessing user profiles in Office 365 is

When using the sample we don´t have to care about the details of handling the SOAP webservice (but you can dive into it with the debugger to see what happens behind the scenes).

Important: No synchronization back!

Attention: Be aware that changes in the SPO user profiles are overwritten with that service. The user properties are NOT synced back into AAD. Properties like “workemail” which usually are coming from AAD or Exchange are overwritten. Keep that in mind to avoid unwanted side effects.

Start with the UserProfileManager

Open the Core.UserProfilePropertyUpdater project and modify it. The first step is to setup the authentication context and create an instance of the UserProfileManager for the Office 365 tenant:

UserProfileManager upm = new UserProfileManager();
upm.User = "";
upm.Password = GetPassword();
upm.TenantAdminUrl = "";

We need an Office 365 tenant administrator to perform changes of other SPO user profile objects except our own user.

Read an user profile property

Specify the user profile you want to use. The format must include the whole claim identity information and the user login name (the UPN).

See part 1 for the user login and the user profile properties.

string userLoginName = "i:0#.f|membership|";

Now we want to get the data. Let´s get the values of the user profile properties “AboutMe” and “SPS-LastKeywordAdded”.

Console.Write(String.Format("Value of {0} for {1} :", "AboutMe", userLoginName));
Console.WriteLine(upm.GetPropertyForUser<String>("AboutMe", userLoginName));

Console.Write(String.Format("Value of {0} for {1} :\n", "SPS-LastKeywordAdded", userLoginName));
Console.WriteLine((upm.GetPropertyForUser<DateTime>("SPS-LastKeywordAdded", userLoginName)).ToLongDateString());

The output should look similar to this example:


Write an user profile property

For writing data we need to distinguish between simple string information and complex data types. The first scenario can be done easily:

upm.SetPropertyForUser<String>("WorkPhone", "005555555", userLoginName);

To ensure the property is saved we can immediately check the property by reading it again:

Console.WriteLine(upm.GetPropertyForUser<String>("WorkPhone", userLoginName));

Continue with other fields like "WebSite", "AboutMe" and so on. The output could look like here:


Some properties consist of more than one information. In that case we need to read a PropertyData object that is used to hold complex types first.

UserProfileASMX.PropertyData p = upm.GetPropertyForUser("SPS-MUILanguages", userLoginName);

Then the object can be modified and written back.

UserProfileASMX.PropertyData[] pMui = new UserProfileASMX.PropertyData[1];
pMui[0] = new UserProfileASMX.PropertyData();
pMui[0].Name = "SPS-MUILanguages";
pMui[0].Values = new UserProfileASMX.ValueData[1];
pMui[0].Values[0] = new UserProfileASMX.ValueData();
pMui[0].Values[0].Value = "de-AT,en-US";
pMui[0].IsValueChanged = true;
upm.SetPropertyForUser("SPS-MUILanguages", pMui, userLoginName);

Check the result

In the Office 365 SharePoint admin center check the user profiles. The changes are instantly visible.

Search for the user profile and open it. It could look like the one here.



Between AAD (Office 365) and SPO user profile we can see some synchronisations and some mappings – some of them are maybe overwritten by our app…


if we continue we don´t find any more mappings…



If the automatic synchronization between [AD,] AAD and SPO cannot be used the SPO user profiles can be modified directly by an (still existing) SharePoint webservice through an app. Be aware of side effects when performing such changes in user profiles.

For a list of all (synched) user properties see the tables in part 1.

I hope these two articles help understanding the current status of user profiles in Office 365 and SPO.


Categories: Azure, Cloud, Developer, DirSync, English, Microsoft, Office365, SharePoint