SharePoint 2013: How to verify ULS log and Usage log file access

Title

How to verify ULS log and Usage log file access in SharePoint 2013 via PowerShell

Business Goal

Recently I had an incident involving Usage reports that weren’t working properly in a SharePoint 2013 farm. I found a nice troubleshooting article which really helped: Snowburnt…IT happens – How to troubleshoot SharePoint Usage Reports Usage Reports.

One of the checks was what the group permissions of the WSS_WPG and WSS_ADMIN_WPG were on the ULS and Usage log file directory on the different servers in the SharePoint 2013 farm. Since I didn’t wanted to uses explorer I decided to create a script to analyse this.

Technical Overview

The solution is a PowerShell script that uses some different cmdlets (Get-SPServer & Get-SPUsageService) from the SharePoint module and the Get-Acl cmdlet. From the Usage Service you can easily get the usage and log file directory path. Via an UNC path you can check the group permissions via the Get-Acl cmdlet. I use the Get-SPServer to determine on which servers to check these permissions.

Prerequisites

To complete this how-to, you must have the following prerequisites must be met:
– A domain account that can log on to one of the SharePoint 2013 servers
– A domain account that has privileges to manage SharePoint 2013 via PowerShell (SPShellAdmin role)

Steps

1. Run the Powershell script .\verify_logfileaccess.ps1

Additional resources

Gallery Technet – Verify ULS and Log file access
Snowburnt…IT happens – How to troubleshoot SharePoint Usage Reports Usage Reports
Technet Library – Account permissions and security settings in SharePoint 2013
Technet Library – Get-Acl
Technet Library – Get-SPServer
Technet Library – Get-SPUsageService

Applies to

SharePoint 2013

Change History

22-09-2016 – 1.0

SharePoint 2010: HTTP Error 503 – Service Unavailable.

KBID

EXP-INC-00003

Title

HTTP Error 503. Service Unavailable

Introduction

When you are working with SharePoint 2010 or SharePoint 2013 environments you probably have seen the HTTP Error 503. Service Unavailable error at some point. This error can have several causes, when you use your favourite search engine you can find a lot of articles on this subject.

Some common causes can be:

  • a disabled application pool
  • an invalid identity for a application pool because of an expired password.

This article describes how I ran into an issue with a group policy that caused a HTTP Error 503.

Symptoms

When you navigate to a SharePoint 2010 site you get an error:
HTTP Error 503. Service Unavailable

HTTP Error 503. Service Unavailable

Steps to Reproduce

1. Navigate to your SharePoint 2010 site

Cause

In my case this error was caused by a removal of Log on as a batch permissions of the Application Pool account on one of the Application servers in a SharePoint 2010 farm. The application pool account of your web application needs this permission on the server where it is running, you can also check out Corey Roth his blogpost on this topic, Corey’s Guide to SharePoint Service Accounts.

When navigating to the System Log on one of the servers in the SharePoint 2010 farm I saw an event of the Windows Process Activation Service (WAS) source with ID 5021:
The identity of application pool ‘yourapplicationpoolname’ is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.

System Log - WAS event id 5021
After finding the 5021 event I wanted to check what my Application Pool Identity was. You can check what the identity of your application pool is via the Application Pools view in Internet Information Service (IIS) Manager.

IIS - Application Pool Identity

When you established what your Application Pool identity is you can open the Local Security Policy Editor on the same server. You can also use run and type secpol.msc to fire it up. Check what the Security Setting is for the Log on as a batch job policy.

In my case a custom policy was set which had overwritten the default settings. The result was that the Log on as batch job permissions of the application pool Identity were removed.

Local Security Policy Editor - Log on as a batch job

Applies to

SharePoint 2010, SharePoint 2013

Workaround

Not Applicable

Solution

Add the Application Pool Identity account the Log on as a batch job group policy or give the account permissions via a local policy on the server if you are not using group policies.

References

Dot Net Mafia – Corey’s Guide to SharePoint Service Accounts
Technet – Account permissions and security settings in SharePoint 2013
Technet – Event ID 5021

Anywhere365: How to update Unified Contact Center Core

Title

How to update Unified Contact Center Core to version 3.0.15073.0

(Business) Goal

Anywhere365 is a product on top of Lync Server 2013 which I recently started working on. If you want to know more about this product I can recommend the GoLive documents on the site of Workstreampeople:

Anywhere365 is a native Lync Unified Contact Center addition that will significantly enhance the standard Lync functionalities available to your organization.

Everyone is a contact center with specific skill sets. Anywhere365 is the premium solution for streamlining communication and dialogues to ensure a more productive and efficient way of information sharing.

Source: Workstreampeople.com

Recently I was asked to update a Unified Contact Center Core installation to a new version, in this case 3.0.15073.0.

Technical Overview

Workstreampeople has a article on how to update Unified Contact Center Core as part of the GoLive documents, Workstreampeople – Update Anywhere365 Core. This is a good article which describes some manual steps and one PowerShell step. I decided to convert all the manual steps to automated steps.

The process of updating contains the following steps:
1. Stop UCC Service
2. Back-up UCC files, Dashboard & Attendant
3. Extract Zip update package
4. Unblock extracted files, if necessary
5. Run Update UCC script
6. Delete UCC cache files
7. Start UCC Service
8. Validate UCC version

This script uses some basic Windows PowerShell cmdlets like Get-ChildItem, Copy-Item, Remove-Item, Get-Service, Stop-Service, Start-Service and Unblock-File. Besides that I used the ExtractToDirectory Method from the System.IO.Compression namespace for extracting the zip.

Currently the script is far from perfect, so I am only sharing this for inspiration and I would definitely first test it on a testing environment!

Prerequisites

To complete this how-to, you must have the following prerequisites must be met:
– Member of Local Administrators group on the Anywhere365 Application server
– Member of Local Administrators group on every server with Lync Server file shares
– Member of the CSAdministrator group in the domain
– Member of the RTCUniversalServerAdmins group in the domain

Steps

1. Adjust the hard coded path values matching your environment
2. Run the Powershell script in Windows PowerShell via the following command .\update_ucccore.ps1
3. In the .\UpdateUCC.ps1 you are asked to stop IIS for an update, answer this with Y

Additional resources

Bish – Unzipping files in Powershell scripts
MSDN Library – ExtractToDirectory Method
TechNet – Copy-Item cmdlet
TechNet – Get-ChildItem cmdlet
TechNet – Get-Service cmdlet
TechNet – Remove-Item cmdlet
TechNet – Start-Service cmdlet
TechNet – Stop-Service cmdlet
TechNet – Unblock-File cmdlet
Workstreampeople – Anywhere365 Core
Workstreampeople – GoLive documentation
Workstreampeople – Update Anywhere365 Core

Applies to

Anywhere365, Lync Server 2013, SharePoint 2013

Change History

06-03-2015 – 1.0

SharePoint 2013: How to get the available page layouts of a web

Title

Get the available page layouts of a web in SharePoint 2013 via PowerShell

Business Goal

In my work as a consultant I sometimes need to analyse how a current SharePoint 2013 farm looks like. Of course you have great tools to help you with this like SPDOCKit. But sometimes I need more details of a farm. In this case I needed information on what kind of page layouts where used on a web.

Technical Overview

The solution is a PowerShell script that uses GetAvailablePageLayouts method to get the available page layouts of a web in a SharePoint 2013 farm. It also uses a definition of a parameter to get a value of a web. A nice description of this technique can be found in an article of Don Jones in Technet Magazine – Windows PowerShell: Defining Parameters.

Prerequisites

To complete this how-to, you must have the following prerequisites must be met:
– A domain account that can log on to one of the SharePoint 2013 servers
– A domain account that has privileges to manage SharePoint 2013 via PowerShell (SPShellAdmin role)

Steps

1. Run the Powershell script .\get_pagelayouts.ps1 with your desired weburl, for instance .\get_pagelayouts.ps1 http://weburl

Additional resources

Gallery Technet – Get the available page layouts of a web
SPDOCKit
Technet – PublishingWeb.GetAvailablePageLayouts method
Technet Magazine – Don Jones – Windows PowerShell: Defining Parameters

Applies to

SharePoint 2013, SharePoint 2010

Change History

23-01-2015 – 1.0

SharePoint 2013: Not able to connect to search service to retrieve valid settings

KBID

EXP-INC-00001

Title

Not able to connect to search service to retrieve valid settings

Introduction

In SharePoint 2013 there are some changes in how search work. Result sources replace scopes and federated locations. Other changes in search can be found overhere on Technet.

In a result source you can restrict queries to a subset of content by using a query transform. You can use the query builder interface for building such a results source. In SharePoint 2013, site collection administrators, site owners, and site designers can also create and configure result sources to meet their specific requirements.

This article describes how I ran into an issue with building a new results source in the query builder in Central Administration.

Symptoms

When you try to create a new result source from Central Administration in your Search Service Application you get an error:
Error: Not able to connect to search service to retrieve valid settings

Error: Not able to connect to search service to retrieve valid settings

Steps to Reproduce

1. Navigate to Central Administration
2. Go to Application Management > Manage service applications and select your Search Service Application
3. Go to Queries and Results > Results Sources
4. Click on the New Result Source button

Cause

Basicly the cause of this error is that the account which you use to access the Query Builder is not authorized to do this.

To see the cause you can open the ULS logs of SharePoint 2013, with a tool like ULS Viewer. When you find the right correlation you get an event of the level Unexpected:
Exception in Query Builder OnLoad: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Attempted to perform an unauthorized operation. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
at Microsoft.Office.Server.Search.Administration.Ranking.GetRankingModels()
at SyncInvokeGetRankingModels(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)).

SharePoint log error

Btw, if you having trouble filter your log on the following fields and corresponding values, Product – SharePoint Server Search & Category – Query.

Applies to

SharePoint 2013

Workaround

Not Applicable

Solution

Add the account with Full Control permissions to the Administrators for Search Service Application. You can do this via the interface in Central Administration or via Powershell. On TechNet this described in detail, Assign or remove administrators to a service application (SharePoint 2013).

References

Majorbacon – Error: "Not able to connect to search service to retrieve valid settings" or Why won’t my query builder work?
Technet – Assign or remove administrators to a service application (SharePoint 2013)
Technet – Understanding result sources for search in SharePoint Server 2013
Technet – What’s new in search in SharePoint Server 2013