Tag Archives: SharePoint 2010

SharePoint 2010: Unable to edit user properties

The other day I received a support case where customer complained that they “suddenly” lost ability to edit user properties in SharePoint 2010. As usual picture worth thousand works so the problem was that if you navigate to Site Actions > Site Permissions, locate some user and click on your user name you will be presented with user information page and if you click edit you will see this:

Sort of interesting Edit Personal Settings dialog where it is not possible to edit anything…

But it used to look like that:

You see more properties listed and they are editable. Now having that description you have to be really skillful with art of googling to get to the bottom of this in the form of some blog post similar to this one. Because to do a proper Google search (one which yields a solution) you have to employ the right terms/know the nature of this issue. But if you noticed word suddenly in quotes in the very beginning I had a background information on preceding changes which caused this “sudden” issue hence was able to fix it. I will go into detailed explanation below for the sake of knowledge sharing.

First of all 1st screenshot is normal for environments where UPS is up and running – as soon as you configure it, SharePoint assumes that all property modifications are being performed on AD DS side and synced from there on a regular basis by UPS. Once UPS is provisioned SP 2010 hides/modifies default forms (layouts/userdisp.aspx – the one where you may click Edit Item to change your properties on the _layouts/useredit.aspx form) and instead of them for users whose profiles are synced you supposed to see specific user profile page instead, which will look approximately like this:

If it does not shown and you see the same uneditable edit form as on the first screenshot, then it either means that UPA is not configured completely or user profile is not synced yet (are you sure that user in question is in right OU?)

So essentially first screenshot/problem shows us that UPS was partially configured/profile(s) not synced (as we still not getting user profile page) but default forms already modified in the process of UPS installation, because when you provision a UPA it will set the fields in hidden site user info list to read only and hidden. With this knowledge about the nature of the problem you may google for the right scripts/information.

In my case we worked on environment where UPS was failing to start/work properly (one of these cases where you need delve deeper into configuration of UPS and peruse something like this blog post) hence it was just mandatory to restore ability to edit user properties. And for that you just need to use the script below against your SP web app (grab this script on GitHub).

# Load SharePoint PS Module (if not already loaded)
# You only need this section if you want to run this script from PS ISE / outside of SP Management Shell
$ver = $host | select version
if ($ver.Version.Major -gt 1) {$host.Runspace.ThreadOptions = "ReuseThread"} 
if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null) 
Add-PSSnapin "Microsoft.SharePoint.PowerShell"

# Tested with SharePoint 2010
# Restores editable user fields after UPA provisioning
$web = Get-SPWeb http://intranet.contoso.com/
$names = "Title", "EMail", "MobilePhone", "Notes", "SipAddress", "Picture", "Department", "JobTitle"
foreach( $name in $names )
$f = $web.SiteUserInfoList.Fields.GetFieldByInternalName($name);
$f.Hidden = $false
$f.ReadOnlyField = $false

Once this script completes you will get your editable user properties back. Two potential problems you may have with this:
1) If Get-SPWeb part of the script complains about incompatibility saying something like “Microsoft SharePoint is not supported with version 4.0.30319.34014” just run new PS instance using -version 2.0 switch;
2) If script completes successfully but you getting user profile page instead of your old beloved form – delete user profile and try again (in case you are not keen or fully removing UPA).

And one last note with regards how we run into this in my specific support case. Client was using K2 and they lived quite happily without UPS provisioned in their SharePoint environment which is a bit strange as a UPS is a requirement for K2. But after upgrading to 4.6.11 the very strange issue crop up which had a bit obscure symptoms on the surface, but in the end was isolated to the fact that each time GetUserGroups URM call was performed to the SharePoint provider no SharePoint groups of which this user is direct member were returned. On the surface it looked like random losing of user’s group membership information and randomly failed K2 tasks which were assigned to SharePoint groups. Randomness stemmed from the fact that GetGroupUsers URM call returned all users for the same group just fine.

And knowing that sometimes it is difficult to find where it was told that XYZ is requirement for K2, I’ll clarify this for UPS specifically: you can find it in K2 blackpearl Installation and Configuration Guide > Prerequisites > Environment Configuration > SharePoint Server 2010 User Profile Service set up

“The SharePoint User Profile Service on any non SharePoint Foundation version must be set up correctly for the Identity Services Group Providers to function correctly with regards to User, Group and Membership resolution. It must be correctly populated with the user’s information and the service must be started.”

Posting rather a lot about SharePoint 2010 at the time of 2016 and cloud stuff I rather feel like author of The Old New Thing blog who at some point decided to blog about old stuff as there is less competition there – everybody busy blogging about new and shiny things (though I should admit I don’t go into really low level details as that blog does) 🙂 But I hope these posts may still be useful for someone.

How to: Install SharePoint 2010 August 2015 CU

On a day to day basis I keep repeating people to always check on with K2 compatibility matrix before installing or upgrading their K2 environments. Very frequently people try to mix K2 with too new Microsoft components which weren’t tested with their version of K2. But there is an opposite issue when Microsoft infrastructure components lag behind in terms of patches/versions fully supported by their release of K2. I know quite a few people still using SharePoint 2010 with K2 4.6.11. So with SharePoint 2010 being an old thing in itself people often skip CUs for this product for some reason which is unknown to me. In this article I want to discuss what is the latest CU for SP 2010 supported by K2 4.6.11 (note that with 4.7 K2 dropped support for SP 2010) and how to install it.

What is the latest CU for SP 2010 supported by K2 4.6.11? As usual you have to check compatibility matrix, but you have to find old one, which will show you this:

And this:

Does it mean that newer CUs will break something/won’t work with K2? Not necessarily, it only means that it won’t be supported because it has not been tested. At the time of release of 4.6.11 latest SP 2010 CU available was August 2015 CU and hence all testing and QA was performed against this CU – K2 cannot guarantee that all will work with newer CUs.

With that knowledge if you are still on SP 2010 it makes sense to make sure you running “newest” supported CU for it. Easiest way to do that is fire off SharePoint Management Shell on your SharePoint server and execute the following command:


This will give you your current build:

Having this information look up in SP builds list @ Todd Klindt’s SharePoint Admin Blog to translate this into CU and SP levels, for example 15.0.7106.5000 translates into August 2013 CU:

Note that there may be minor last digit discrepancies depending on how you look up for build number. So now I know that my SP 2010 is August 2013 CU and for K2 4.6.11 I can go up to August 2015 CU (download link) from that – let’s try to do it.

First things should go first – backup your SharePoint environment. Navigate to Central Administration > Backup and Restore and click Perform a backup – just go through the wizard and create full farm backup. It can be good idea to test that your backup can be restored.

Once backup is done an CU file is downloaded launch it, accept license terms and hit “Continue”:

CU installer will check for installed updates and proceed with extracting files and installation of update after that:

Once done it will ask for reboot:

Most frequent mistake in all this process it assuming that after reboot of your SharePoint server you will be running updated SharePoint version. Quick check with (Get-SPFarm).BuilVersion will show you the same build as it was before you started CU installation process. So update is not finished just yet and to complete it you have to locate SharePoint 2010 Products Configuration Wizard in Start Menu:

and run it. Next you just go through the wizard’s steps to complete upgrade:

Warning you got in the very beginning should be taken seriously if you do this on a server used by other people where IIS reset may have undesired impact:

Once all configuration tasks completed you should get confirmation of successful configuration and click Finish button:

After clicking on Finish it will take you to CA main page automatically. In CA you can navigate to Upgrade and Migration > Upgrade Status where you can see confirmation of successful upgrade:

And now it is time to issue (Get-SPFarm).BuildVersion command once again:

First execution of the command on the screenshot was made before running of SharePoint 2010 Products Configuration Wizard and the second after wizard completion – now we run build 14.0.7155.5000 which is the latest SharePoint 2010 build officially supported by K2 4.6.11.

Switching SP2010 from Classic Mode to Claims Mode Authentication

SharePoint Server 2013 uses claims-based authentication as its default authentication model, and it is required to enable its advanced functionality. Using claims-based authentication has the following advantages over using Windows classic-mode authentication:

  • External SharePoint apps support. App authentication and server-to-server authentication rely on claims-based authentication. With Windows classic-mode authentication you are unable to use external SharePoint apps. You also cannot use any services that rely on a trust relationship between SharePoint and other server platforms, such as Office Web Apps Server 2013, Exchange Server 2013, and Lync Server 2013.
  • Claims delegation without “double-hop” limitation. SharePoint can delegate claims identities to back-end services, regardless of the sign-in method. E.g., suppose your users are authenticated by NTLM authentication. NTLM has a well-known “double-hop” limitation, which means that a service such as SharePoint cannot impersonate the user to access other resources on behalf of the user, such as SQL Server databases or web services. When you use claims-mode authentication, SharePoint can use the claims-based identity token to access resources on behalf of the user.
  • Multiple authentication providers per one web application. When you create a web application in claims-based authentication mode, you can associate multiple authentication providers with the web application. It means, that, for example, you can support Windows-based sign in and forms-based sign in without creating additional IIS websites and extending your web application to additional zones.
  • Open standards. Claims-based authentication is based on open web standards and is supported by a broad range of platforms and services

There are several supported scenarios for migrating or converting from classic mode to claims mode authentication which performed with use of a number of Windows PowerShell cmdlets: you either switch your web apps on SP2010 before upgrade to SP2013 or you can convert SharePoint Server 2010 classic-mode web applications to SharePoint Server 2013 claims-mode web applications after you have SP2013 installed already.

Steps to switch your SP2010 web apps to claims based authentication:

1. Enable claims authentication for your web app.

$WebAppName = "http://portal.denallix.com" 

$wa = get-SPWebApplication $WebAppName

$wa.UseClaimsAuthentication = $true


2. Configure the policy to provide the user with full access.

$account = "Denallix\Administrator" 

$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

$wa = get-SPWebApplication $WebAppName

$zp = $wa.ZonePolicies("Default")

$p = $zp.Add($account,"PSPolicy")




3. Perform the migration.


4. Provision claims


Once done you with these changes may verify that you are using Claims Authentication for your web application:

GUI way. In Central Administration navigate to web application management, select your Web Application and click on Authentication Providers button:

SP 2010 check web app authentication mode 01

It will open a window where you can verify your default authentication mode:

SP 2010 check web app authentication mode 02

 PowerShell way:

$web = Get-SPWebApplication "http://portal.denallix.com" 


It will return True or False depending on whether you have Claims Authentication enabled or not (screenshot below for enabled state):

SP 2010 check web app authentication mode 03

In case you have K2 components installed you may need to perform relevant configuration changes on K2 side (see Claims Authentication Configuration section at help.k2.com) which I will cover in separate blog post.

In case if you are in a mood for deep dive into what & why of claims authentication subject you may read through the following articles:

Identity (Management) Crisis (Part 1): The evolution of identity concepts

Identity (Management) Crisis (Part 2): Everything you (think you) know is wrong

Identity (Management) Crisis (Part 3): Solving the Identity Problem

Identity (Management) Crisis (Part 4): Selecting a Comprehensive Identity Management solution

Claims Based Identity: What does it Mean to You? (Part 1)

Claims Based Identity: What does it Mean to You? (Part 2)

Claims Based Identity: What does it Mean to You? (Part 3)

SharePoint 2010 and Windows Server 2012/2012 R2 compatibility

The other day I was trying to build SharePoint 2010 SP1 VM for testing purposes, and as I already had Server 2012 R2 VM available I tried to install SP 2010 SP1 on it – with no luck as both prerequisites installer threw warning about comparability and SP installer itself just failed to complete without warning me beforehand. So after number of stubborn attempts ended up with the same negative result, I decided that it’s high time do some reading/RTFM time.

The thing here is that SP 2010 RTM don’t supported on/compatible with Server 2012 / 2012 R2. “On Windows Server 2012 R2, Microsoft supports only the SharePoint Server 2010 SP2 slipstream media configuration and not the RTM version of that configuration.” Feel free to read Microsoft KB2724471 for details, you will see all the errors I saw trying to install SP 2010 SP1 on Server 2012 R2 there.

Well at list this is well documented unlike my other “retrospect” discovery of the fact that IIS 7.0 doesn’t surface in its GUI option for editing Providers for Windows Authentication when you right click on Windows Authentication icon in Authorization settings (where you can configure NTLM/Negotiate/Kerberos ant their precedence)… You need to employ IIS Administration Pack and wade through its keys/entries to adjust this stuff, which is only a bit better then using appcmd.exe or other CLI options for doing this. And yes in case you forgot you can’t install IIS 7.5 on Server 2008 (not R2).

With that it seems that I need to arrange some Windows Server 2008/2008 R2 VM for testing “old stuff” 🙂

SharePoint 2010: get build number

Just a quick note on how to get SharePoint 2010 build number. Run following in SharePoint 2010 Management Shell:



It will return you something like this:


Detailed list of SharePoint builds which will allow you to translate this output into “human language” SharePoint 2010 SP/patch level can be found for example here or even better reference is SharePoint Patch Reference on MSDN.