Bolufer Blog - SharePoint & .NET language

One of the most common questions is definitely about the resources used by Search. Using Continuous Crawl and/or many crawl processes and/or frequent crawl schedules and/or big change sets in the content sources, etc. – all makes the resources consumed by Search higher and higher. Besides the most known optimization and scale-out techniques, I get the question very often: how the resources consumed by noderunner.exe can be limited? The first part of my answer is: Please, do plan your resources in production! Search is often seen as "something" that works "behind the scenes", but it can make some very bad surprises… I'm sure you don't want to see your production farm consuming 99% of the available memory while crawling… So please, plan first. Here's some help for this: Scale search for performance and availability in SharePoint Server 2013 . But you might have some dev or demo environments, for sure, where you cannot have more than one crawl

A main criterion that distinguishes websites between good and bad usability is the way, how users can enter data to forms.  Imagine a list with around 15 or more fields. Now a user creates an initial item for that he only enters a few metadata to the item like title, description and a date. After that, another user modifies that item and adds some other field-values. And at last but not least, a third user completes the form by entering all missing values. So you want to show specific fields related to users or roles. Wrap that by a workflow with email-notifications if you want but that’s not the topic of my post.  By default, you have a newform.aspx/editform.aspx that displays all those 15 fields which is not quite necessary for the first user. The second user should not see those metadata-fields the first user entered during initial creation and the last user fills the last values. Finally you really want to impress your customer so the fields in the form

Users added to AD group not granted access in SharePoint Clear - SPDistributedCacheItem – ContainerType DistributedLogonTokenCache ELSE: Here’s an interesting scenario I hadn’t experienced before:  SharePoint 2013 farm doing a user profile sync with Active Directory. Security was based on Active Directory security groups managing membership and authorization controlled through SharePoint groups containing the AD groups. As users were added and removed to/from the AD groups, they weren’t seeing the change reflected in the SharePoint sites. After a crash course in claim caching, here’s what we ended up with. First, an admittedly simplistic view of how SharePoint manages tokens: User browses to SharePoint site SharePoint checks local token store (STS) for a non-expired cached claim for that user If not found, STS creates a new claim by querying AD and then adds it to the cache If found, uses the cached claim That covers the user, now lets look at how Share