SharePoint 2013 People Picker trouble reaching the server

We encountered the following errors on two seperate farms with the same scenario:

The SharePoint people picker displayed the following error

PeoplePicker error 1

The dutch language pack has been used but it says: Sorry, we’re having trouble reaching the server.

Fiddler

Fiddler is showing error 400 Bad Requests each time the people picker tries to contact the Active Directory

ULS Logs

Exception occured in scope Microsoft.SharePoint.ApplicationPages.ClientPickerQuery.ClientPeoplePickerWebServiceInterface.ClientPeoplePickerSearchUser. Exception=System.Security.SecurityException: Requested registry access is not allowed.

Original error: System.Security.SecurityException: Requested registry access is not allowed.

SocialRESTExceptionProcessingHandler.DoServerExceptionProcessing – SharePoint Server Exception [System.Security.SecurityException: Requested registry access is not allowed.

Scenario

We have installed SharePoint 2013 using SPAutoInstaller and configured the people picker using STSADM because we have a one-way trust domain.
The people picker has been configured using the default STSADM commands:

STSADM.exe -o setapppassword -password “*******”
stsadm -o setproperty -url <WebApp URL> -pn peoplepicker-searchadforests -pv “forest:<ForestNameA>,<UserAccount>,<Password>;forest:<ForestNameB>”

Solution
The only helpfull warning we get was from the ULS logs and the event viewer as the errors are also shown there. After verifying different access denied logs we saw that the portal account was trying to connect to a registery key that it had no access to. We solved this issue by adding the portal account to WSS_RESTRICTED_WPG_V4 in the Local Users and Groups manager. You will have to perform an IISReset after adding the user to this group! The user can be found after the IISReset:

PeoplePicker error 2

 

 

 

Increase SharePoint Workflow performance and reliability

We encountered several scenario’s where workflows did not start correctly or the workflow did not continue after a pause action. 1 error we have seen is as follows:

AutoStart Workflow: Microsoft.SharePoint.SPException —> System.Runtime.InteropServices.COMException (0x8102008A): <nativehr>0x8102008a</nativehr><nativestack></nativestack>

at Microsoft.SharePoint.Library.SPRequestInternalClass.AddWorkflowToListItem(String bstrUrl, String bstrListName, Int32 lItemID, Int32 lItemLevel, Int32 lItemVersion, Guid workflowPackageId, Guid& pWorkflowInstanceId, Guid workflowTaskListId, String bstrStatusFieldInternalName, Int32 lAuthorId)

at Microsoft.SharePoint.Library.SPRequest.AddWorkflowToListItem(String bstrUrl, String bstrListName, Int32 lItemID, Int32 lItemLevel, Int32 lItemVersion, Guid workflowPackageId, Guid& pWorkflowInstanceId, Guid workflowTaskListId, String bstrStatusFieldInternalName, Int32 lAuthorId)     –

— End of inner exception stack trace —

at Microsoft.SharePoint.Workflow.SPWinOeEngine.CreateWorkflow(Object context, SPWorkflowAssociation association, SPWorkflowEvent startEvent, Boolean bCreateOnly)

at Microsoft.SharePoint.Workflow.SPWorkflowManager.StartWorkflowElev(Object context, SPWorkflowAssociation association, DateTime elevationTimeUtc, SPWorkflowEvent startEvent, SPWorkflowRunOptions runOptions)

at Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.<>c__DisplayClass1.<AutoStartWorkflow>b__0(SPSite superUserSite, SPWeb superUserWeb)

I have collected a few settings that can be changed to increase performance or the reliability of Workflows in SharePoint.

1. Increase Throttle Size
2. Increase Batch Size
3. Time-Out
4. Workflow Timer interval
5. Event Delivery Throttle
6. Central Administration Time-Out

1. Increase Throttle Size

The workflow throttle setting controls how many workflows can be processed at any one time on the entire server farm

Use the following command to get the default value

stsadm -o getproperty -pn workflow-eventdelivery-throttle

You can change this value with the following command

stsadm -o setproperty -pn workflow-eventdelivery-throttle -pv “25”

image

2. Increase Batch Size

Batch size property controls how many work items waiting to be processed by the timer service will be executed in each run

Run the following command for the default value

stsadm -o getproperty -pn workitem-eventdelivery-batchsize

Run the following command to change this value

stsadm -o setproperty -pn workitem-eventdelivery-batchsize -pv “200”

image

Next start Central Administration and navigate to “Manage services on server”

image

Click on “Microsoft SharePoint Foundation Workflow Timer Service”

image

image

Also change this setting to for example 200

3. Time-Out

Timeout specifies the maximum time which can be taken to complete the workflow timer job in minutes.

Run the following command for the default value

stsadm -o getproperty -pn workflow-eventdelivery-timeout

Run the following command to change this value

stsadm -o setproperty -pn workflow-eventdelivery-timeout -pv “10”

image

4. Workflow Timer interval

Workflow timer Interval shows how often SPtimer job should run to process workflow items.

Use the following command to get the default value

stsadm -o getproperty -propertyname “job-workflow” -url https://portal.sharepointfire.com

You can change this value with the following command

stsadm -o setproperty -propertyname “job-workflow” -propertyvalue “every 2 minutes between 0 and 59” -url https://portal.sharepointfire.com

image

5. Event Delivery Throttle
The WorkflowEventDeliveryThrottle parameter is used to throttle the workflow events

Run the following command for the default value

stsadm -o getproperty -pn workflow-eventdelivery-throttle -url https://portal.sharepointfire.com

Run the following command to change this value

stsadm -o setproperty -pn workflow-eventdelivery-throttle -url https://portal.sharepointfire.com -pv “30”

image

6. Central Administration Time-Out

This is the same procedure as described in https://www.sharepointfire.com/2013/03/cannot-display-the-webpage-while-creating-a-web-application-in-sharepoint/

The website cannot display the page @ SharePoint due to Group Policy settings

This error (The website cannot display the page) can be thrown due to a number of reasons but I’ll will show the issue and solution we had after a few SharePoint 2013 installations.

Issue

We installed SharePoint 2013 correctly and verified if everything was up and running. The databases and websites were online and Central Administration was working. We only got the below error while browsing to our Web Applications.

image

We found the following errors in the ULS logging using ULSViewer.

Application error when access /SitePages/Home.aspx, Error=The given assembly name or codebase, ‘C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel\v4.0_4.0.0.0__b77a5c561934e089\System.ServiceModel.dll’, was invalid.
at System.ServiceModel.Activation.ServiceHttpModule.BeginProcessRequest(Object sender, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

System.IO.FileLoadException: The given assembly name or codebase, ‘C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel\v4.0_4.0.0.0__b77a5c561934e089\System.ServiceModel.dll’, was invalid.
at System.ServiceModel.Activation.ServiceHttpModule.BeginProcessRequest(Object sender, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Access Denied. Exception: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), StackTrace:
at Microsoft.SharePoint.Library.SPRequestInternalClass.PreInitServer(String bstrAbsoluteRequestUrl, String bstrServerRelativeUrl, Int32 lZone, Guid gApplicationId, Guid gSiteId, Guid gDatabaseId, String bstrDatabaseServer, String bstrDatabaseName, String bstrDatabaseUsername, String bstrDatabasePassword, Boolean fHostHeaderIsSiteName, String bstrAppHostHeaderRedirectDomain, Boolean fAppWebRequest, String bstrAppDomain, String bstrRequestAppWebDomainId, String bstrAppSiteDomainPrefix, Int32 iDatabaseVersionMajor, Int32 iDatabaseVersionMinor, Int32 iDatabaseVersionBuild, Int32 iDatabaseVersionRevision)
at Microsoft.SharePoint.Library.SPRequest.PreInitServer(String bstrAbsoluteRequestUrl, String bstrServerRelativeUrl, Int32 lZone, Guid gApplicationId, Guid gSiteId, Guid gDatabaseId, String bstrDatabaseServer, String bstrDatabaseName, String bstrDatabaseUsername, String bstrDatabasePassword, Boolean fHostHeaderIsSiteName, String bstrAppHostHeaderRedirectDomain, Boolean fAppWebRequest, String bstrAppDomain, String bstrRequestAppWebDomainId, String bstrAppSiteDomainPrefix, Int32 iDatabaseVersionMajor, Int32 iDatabaseVersionMinor, Int32 iDatabaseVersionBuild, Int32 iDatabaseVersionRevision).

After investigation we found out that the customer controls a lot using group policies and we verified a few policies with a working SharePoint 2013 environment.

Problem

The customer had removed the local group IIS_IUSRS from the group policy ‘Impersonate a client after authentication’ under Local Policies –> User Rights Assignment.

image

Central Administration was working correctly because the farm account was still present and because the farm account is member of the local administrator group.

Solution

We added IIS_IUSRS back to this policy and performed an IISReset. All Web Applications were up and running after the reset.

image