Heads up are you still using SharePoint 2010

I want to spread my colleague Stefan’s post for this important headsup:

Mainstream support for SharePoint 2010 will end on October 13th, 2015:

After this date only security fixes will be provided for SharePoint 2010. That means if you are running into an issue after October 13th which is caused by a problem in SharePoint 2010 and which has not already been addressed before you will no longer be able to request a hotfix.
Not the best situation if you are using SharePoint 2010 as a business critical application.

There are still three months till deadline – enough time to evaluate SharePoint 2013 and consider an upgrade.



PeoplePicker – Double Users and Diacritic issue

Well, it is an another well know issue by Microsoft.
Here you can find some definitions:

* Experiencing inconsistencies with some user profiles where the user Account name attribute is observed to vary between e.g. Domain\aloş and Domain\alos . This is observed in SharePoint Central Administration > User Profile Service Application > Manage User Profiles and Edit User Profile sections and therefore impacting approval workflows where they are using InfoPath Forms .

*Connecting local domain to Sharepoint server, in domain are login with diacritics, in sharepoint there are login of users with diacritics – wrongly displayed .Also when search for the user in people picker we get two users account one with account name with diacritics and second without it.
In UPA profile contains correct account name (without diacritics)

Issue Reproduce:
Add a user in Active Directory. In example we are adding TESTMOSS2010T\Berkc user.


For first time login the SharePoint as a Site collection administrator (which should be different that our test account)
And try to grant permission the user but use diacritic as berkç (use ‘ç’ instead of ‘c’)


When you check and verify the user, move and keep Mouse over the validated user text , that will Show us the account
As you can see it is “TESTMOSS2010T\berkç” . Well so far so good . SharePoint accept it without any problem when you click the OK.


If you search from user it will Show you just one with “berkç”


If we try without diacritics like “berkc” it is also accepted .


But wait a minute , If you keep Mouse over the validated user text , that still show us the account as
“TESTMOSS2010T\berkç” .
Hmm , thats looks strange . (Well actually SharePoint has already saved the data in UserInfo table & UserInformation List as ‘berkç’) and SharePoint is clever enough to understand this is same user.
(because they have same SID) PS: If the SIDs are different well it is tottally different problem and out of scope for this article 🙂


You can see in UserInfo table


And User Information List


Well , I dont want to use it like this. This user should be “TESTMOSS2010T\berkc” so how can i change it .
Move-SPUser will helps here.


$user = get-spuser -Identity “TESTMOSS2010T\berkç” – web <web Url>
Move-SPUser -identity $user -NewAlias “TESTMOSS2010T\berkc” -IgnoreSID
(In some scenarios it doesn’t work , so in that condition you may need to delete user from SharePoint and add again )
After i changed that user account , hmm i can see now 2 account if i search from people-picker .


Why ? The reason is LSA cache . Because very first time we make a query to AD as “berkç” and AD accepted it (Well the configuration of AD user resolution for diacritics is a different issue so i don’t mention here) and Server LSA cache has stored as “berkç” . So PeoplePicker has uses both SharePoint DBs and AD Resources to Show results . In that condition SharePoint DB (User Information List) returns “berkc” and AD query bypassed by LSA – Show us “berkç

The LSA maintains a SID cache on domain member computers. This cache stores mappings between SIDs and user names. If the SID information exists in the local cache, the LSA returns the cached user name information instead of checking whether the user name has changed.
The local SID cache helps reduce domain controller workload and network traffic. However, inconsistency may occur between the local cache and the domain controllers.

If you want to get rid-off this behavour ; disable LSA cache: http://support.microsoft.com/kb/946358.

To work around this issue, disable the local SID cache on the domain member computer. To do this, follow these steps:

  1. Open Registry Editor.To do this in Windows XP or in Windows Server 2003, click Start, click Run, type regedit, and then click OK.

    To do this in Windows Vista and newer, Click Start, type regedit in the Start Search box, and then press ENTER.

  2. Locate and then right-click the following registry subkey:
  3. Point to New, and then click DWORD Value.
  4. Type LsaLookupCacheMaxSize, and then press ENTER.
  5. Right-click LsaLookupCacheMaxSize, and then click Modify.
  6. In the Value data box, type 0, and then click OK.
  7. Exit Registry Editor.

Note The LsaLookupCacheMaxSize registry entry sets the maximum number of cached mappings that can be saved in the local SID cache. The default maximum number is 128. When the LsaLookupCacheMaxSize registry entry is set to 0, the local SID cache is disabled.

Unfortunately there is no other resolution for this design.


When using Lookup Column facing exceed list view threshold

Recently faced following issue ; To clarify that i want to share how i reproduce it ;
This issue can be reproducable SPO, SharePoint 2013 and 2010

+Create a list named “LargeOne” with 2100 item
+Set the list view threshold limit 2000 for this list
+Create another list for lookup named “LookupOne”
+Add some data in LookUp List
+Add a Lookup column to “LargeOne” list as pointing the “LookupOne” List (For example title)
+Index that column in LargeOne List
+Create a view named “testview” by filtering related LookupColumn and set row limit 100

Occurence :
View not show items and facing following error
“The view can not be displayed because it exceeds the list view threshold(5000 items) enforced be the administrator”

Expected :
View shows items

What you will see in ULS Logs
01.06.2015 14:15:07.70 w3wp.exe (0x3978) 0x1694 SharePoint Foundation Health 46ri High
Throttled:Big list slow query. List item query elapsed time: 0 milliseconds, Additional data (if available): Query HRESULT: 80070024 List internal name, flags, and URL: {976E4B58-476A-4B5F-A4D5-7AB44279BD71}, flags=0x0000000020801080, URL=”https://blog.bugrapostaci.com/Lists/Largeone/testview.aspx&#8221; Current User: 2110 Query XML: “<Query><Where><Eq><FieldRef Name=”SiteID”/><Value Type=”Text”>999</Value></Eq></Where></Query>” SQL Query: “N/A”

01.06.2015 14:15:07.70 w3wp.exe (0x3978) 0x1694 SharePoint Foundation General xxpm High
Unable to execute query: Error 0x80070024

01.06.2015 14:15:07.74 w3wp.exe (0x3978) 0x1694 SharePoint Foundation Web Parts 89a1 High
Error while executing web part: Microsoft.SharePoint.SPQueryThrottledException:
The view can not be displayed because it exceeds the list view threshold(5000 items) enforced be the administrator
—> System.Runtime.InteropServices.COMException (0x80070024):
The view can not be displayed because it exceeds the list view threshold(5000 items) enforced be the administrator.

Well this issue is “By Design” . The throttling limit is enforced in order to protect the health of the SharePoint server. Looking up the value of the lookup list causes the throttling limit to be enforced.  When making a query to SQL, we limit our queries to less than 5000 items.   There is a hard coded functionality on SQL that will lock the entire table if the query exceeds 5000 items.  In order to offset this we set the list threshold to a value equal or less than this to avoid such actions.

And documented following article.
“Although you can index a lookup column to improve performance, using an indexed lookup column to prevent exceeding the List View Threshold does not work. Use another type of column as the primary or secondary index.”

And more extra info: Indexing the column in the other list or library does not improve performance of the lookup operation

For a workaround you think that you may be  disable throttling ,  but this time for a big possibility you will face performance issues.

$web=Get-SPWeb $weburl
$list.enablethrottling = $false

On this manner we suggest make a good planing for handle large lists when you are using SharePoint otherwise that could create a real pain and lots of jobs to do.

Unable to delete a Site Content Type from site

In one of my previous article i have explained in details why you could not delete a content type from a specific list .

In this article i would like to explain the issue when you want to delete a content type from a site .
To able to delete a content type in a site there are some restrictions .If a content type is in use , you could not delete it. Meaning of “in use” depends following 2 restrictions to provide data integrity and prevent data lost

1) This content type should not be inherited by another content type
2) This content type should not be used in a list .

When you want to delete a content type, SharePoint is very safe to prevent the deletion if this content type in use , but there is problem here , Where this content type in use ?
There is no OOB tool to find it , you can use powershell to iterate all webs in that site and the lists to find it out but it is a little time consuming operation.
There is another and easy way to do it , if you have Access to SQL server in related content database and you can run following select queries.

declare @SiteId uniqueidentifier
declare @Class bit
declare @ContentTypeId tContentTypeId
declare @IsFieldId bit

/* You need following parameters */
@SiteId = ‘8893D8B3-87C2-410F-9DBA-89E8DAC9BB6E’
Set @Class = 1 /* Needs always 1 means is a ContentType */
Set @ContentTypeId = 0x0100A0E39C8B4EED1A47A72EE334ADB2D5D1
Set @IsFieldId = 0

/* Checkes for  if given content inherited by another content type */


select ContentTypeId,Scope,[Version],ResourceDir,SolutionId,IsFromFeature
from  ContentTypes  WITH (INDEX=ContentTypes_SiteClassCTId, FORCESEEK)
where SiteId = @SiteId AND Class = @Class AND
ContentTypeId <= (@ContentTypeId + 0xFF) AND ContentTypeId > @ContentTypeId

/* Checkes for if given content is used by a list */


select W.FullUrl as Url ,L.tp_Title as ListTitle
from ContentTypeUsage WITH (INDEX=ContentTypeUsage_SiteIsFClassCTIdWeb, FORCESEEK)
Join Lists L on L.tp_ID = ContentTypeUsage.ListId
Join Webs W on W.Id = ContentTypeUsage.WebId
Where ContentTypeUsage.SiteId = @SiteId AND ((@IsFieldId IS NULL AND IsFieldId IS NULL) OR @IsFieldId=IsFieldId) AND
Class = @Class AND
ContentTypeId <= (@ContentTypeId + 0xFF) AND
ContentTypeId >= @ContentTypeId




As you can see ; in first query result the content type inherited by other 4 content types , the name of the inheriters are in ResourceDir column. And Scope is Show which SubWeb in defined.
for second query results the content type in use for just for one list , which is present in http://contoso.com/SubWebLevel1/SubWebLevel2 -> List Name is “Test”

For delete this content type the action plan is simple
1) Delete all inherited content types.
2) Delete/Change any item if it is using this content type in “Test” List
3) Remove the content type form the Test List. (Dont forget this!!!)

Ok. How SharePoint understand a content type in use in site level ?
There is a stored procedure name proc_IsContentTypeInUse . I have adjusted above SQLs that according to this procedure as like How SharePoint does.

*Dont forget any direct changes for any SharePoint Database is not permitted. That can cause your system is not supported .So dont change (Update/Delete/Insert) anything by SQL.


August 2014 CU for SharePoint 2010/2013 has been released

The product group released the August 2014 Cumulative Update for the SharePoint 2013 product family.


Be aware that all Update for SharePoint 2013 require SharePoint Server 2013 SP1 OR March 2013 PU for SharePoint 2013 to be installed first.

Please also have a look at the article that discusses how to properly patch a SharePoint 2013 farm which has Search enabled (see below).

Also be aware that in August no so called “Server” or “Uber” packages have been released instead only fix packages for individual components of SharePoint have been released. That means if your SharePoint system is on an older patch level than July 2014 CU you need to install July 2014 CU before installing the below listed August 2014 CU fixes in order to update your system to the latest patch level.
With other words: It is highly recommended to install SP1 and July 2014 CU before installing August 2014 CU!

Previous releases of the SharePoint Server 2013 cumulative update included both the executable and the .CAB file in the same self-extracting executable download. Because of the file size, the SharePoint Server 2013 package has been divided into several separate downloads. One contains the executable file, while the others contain the CAB file. All are necessary and must be placed in the same folder to successfully install the update. All are available by clicking the same Hotfix Download Available link in the KB article for the release.

This CU does NOT(!) include all SharePoint 2013 fixes previously released! It is recommended to install July 2014 CU before installing this CU.

The CU does not include SP1! You can install SP1 before or after installing this CU.

  • KB 2883081 – SharePoint Foundation 2013 August 2014 CU
  • KB 2883086, KB 2883085, KB 2883078, KB 2880559, KB 2760213 – SharePoint Server 2013 August 2014 CU
  • KB 2883083 – SharePoint Server 2013 with Project Server August 2014 CU
  • KB 2883093 – Office Web Apps Server 2013 August 2014 CU (KB delayed)



For More Information :

For SharePoint 2010 August 2014 CU

The product group released the August 2014 Cumulative Update for the SharePoint 2010 product family.

Be aware that the August Cumulative Update for SharePoint 2010 is a Post-SP2 hotfix. It is recommended to have SP2 installed before installing the August CU.

Also be aware that in August no so called “Server” or “Uber” packages have been released instead only fix packages for individual components of SharePoint have been released. That means if your SharePoint system is on an older patch level than July 2014 CU you need to install July 2014 CU before installing the below listed August 2014 CU fixes in order to update your system to the latest patch level.
With other words: It is highly recommended to install SP2 and July 2014 CU before installing August 2014 CU!

This CU includes all SharePoint 2010 fixes released since SP1. The CU does not include SP2.

  • KB 2889825 – SharePoint Foundation 2010
  • KB 2889831 – SharePoint Server 2010

For More Information: