Dienstag, 30. Juni 2015

Monitoring crawler impact

Problem: Do you know what your SharePoint Search Crawler is doing?

Solution: If you want to monitor what the SharePoint crawler is doing, you can watch the Threads Accessing Network, Filtering Threads and Idle Threads from the OSS Search Gatherer category in Performance Monitor during a content crawl.

In my development VM, I see that the number of filtering threads stays at around 20 and the number of idle threads around 12 for the duration of the crawl which means that an average of 8 threads are being used by the gatherer process.

In SharePoint 2010, you can control the content crawl rate at the search service application level by using Crawler Impact Rules. By default, the number of simultaneous requests changes dynamically based on the server hardware and utilization. Crawler impact rules are often used to throttle the request rate for external websites. You can manage crawler impact rules in Central Administration > Search Service Application > Crawler Impact Rules.

Next, let’s create a new crawler impact rule to limit the number of simultaneous requests to 2 using the * site name wildcard to apply the rule to all sites.

If we keep an eye on the performance counters this time, we can see that now the difference between the number of filtering and idle threads during a crawl equals to 2 (11 filtering threads and 9 idle threads in the example below).

The performance counters confirmed that our new crawler impact rule is working. Be careful when you delete a crawler impact rule though! I’ve seen it a number of times in different SharePoint farms that SharePoint remembers and keeps using the last deleted crawler impact rule. I verified it by monitoring the performance counters – the deleted crawler impact rule remains in effect until the the SharePoint Server Search 14 service is restarted (or a new rule is added that overrides the deleted rule settings). So remember – restart the SharePoint Server Search 14 windows service after deleting a crawler impact rule!

Mittwoch, 10. Juni 2015

WCF WebService Factory for SharePoint 2010

Problem:
When you create your own SharePoint WCF Service in the ISAPI folder you might encounter the following error when sending to large Xml.

The maximum array length quota (16384) has been exceeded while reading XML data. This quota may be increased by changing the MaxArrayLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader.

Solution:
You need to create your own Service Host Factory.
<% @ServiceHost Debug="true"
    Service="ExampleHostFactory.TestService, ExampleHostFactory, Version=1.0.0.0, Culture=neutral, PublicKeyToken=11e99323d9a22b04"
    Factory="ExampleHostFactory.ServiceHostFactory, ExampleHostFactory, Version=1.0.0.0, Culture=neutral, PublicKeyToken=11e99323d9a22b04" %>



using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Client.Services;
using System.ServiceModel;
using System.ServiceModel.Description;

namespace ExampleHostFactory
{
    public class ServiceHostFactory : MultipleBaseAddressBasicHttpBindingServiceHostFactory
    {
        protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            ServiceHost serviceHost = new MultipleBaseAddressBasicHttpBindingServiceHost(serviceType, baseAddresses);

            if (serviceHost != null)
            {
                serviceHost.Opening += new EventHandler(HostOpening);
            }

            return serviceHost;
        }

        void HostOpening(object sender, EventArgs e)
        {
            ServiceHost serviceHost = sender as ServiceHost;

            if (serviceHost != null && serviceHost.Description != null && serviceHost.Description.Endpoints != null)
            {
                foreach (ServiceEndpoint endpoint in serviceHost.Description.Endpoints)
                {
                    if (endpoint != null && endpoint.Binding != null)
                    {
                        BasicHttpBinding basicBinding = endpoint.Binding as BasicHttpBinding;
                        if (basicBinding != null)
                        {
                            // configure binding settings
                            basicBinding.MaxReceivedMessageSize = Int32.MaxValue;
                            basicBinding.ReaderQuotas.MaxArrayLength = Int32.MaxValue;
                            basicBinding.ReaderQuotas.MaxBytesPerRead = Int32.MaxValue;
                            basicBinding.ReaderQuotas.MaxStringContentLength = Int32.MaxValue;
                        }
                    }
                }
            }
        }
    }
}

Disabled users in SharePoint


Problem:
Do you have disabled users from active directory appear in SharePoint?

There are scenarios you might observe disable person's details will appear in SharePoint people search, they will still show in the organization chart webpart in my site etc. In the configuration of the user profile service you can filter the disabled user accounts from active directory to SharePoint.

Solution:
Filter the disabled user accounts in user profile service

Go to [Central administration] [Application Management] [Manage Service Applications] [User Profile Service Application]

Click on Configure Synchronization Connections

From the connections you are using click on Edit Connection Filters menu.


It will open the Edit Connection Filters screen from that you can see Exclusion filter for users. In Exclusion filter for users enter the below values.

Attribute : userAccountControls (Select from dropdown)
Operator: Bit on Equal (Select from dropdown)
Filter : 2

Once you enter the required values click on Add button and it will show the below details in Exclusion filter for users section.
Finally click on ok button to submit the Edit connection filters details. Once you are done do a full synchronization run.

Problem 2:
This does not filter users in the SharePoint address book.

Solution 2:

By configuring the settings for the control, you can filter and restrict the results that are displayed when a user searches for a user, group, or claim. Those settings will apply to every site within the site collection.

The following example filters out user accounts that do not have e-mail addresses, or that are disabled. Because security groups do not always have e-mail addresses associated with them, an OR statement is used to ensure that security groups are still included in the query results:

stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "(|(&(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(objectcategory=group))" -url http://ServerName