Warning: count(): Parameter must be an array or an object that implements Countable in /www/htdocs/w0066174/domain/techspark/wp-content/plugins/wordpress-ping-optimizer/cbnet-ping-optimizer.php on line 533

Category Archives: Sharepoint

Recently we added Access Services to our SharePoint 2013 environment. After the initial setup we started testing the new implementation and stumbled over an error while accessing the details page of an app. This has nothing to do with access itself, more with apps in general.

After clicking on details you get an error message with the correlation id. So nothing easier to get the log regarding that error.

This leads us to a permission issue. We tried granting the App Management Service Account “SPDataAccess” permission on our logging database, which did not help.

As you can see in the log there is an user specified IUSR SID: S-1-5-17. This leads to a permission issue from IIS WebServer. Makes sense as all SharePoint Applications are running within the IIS and their Application Pools. As our App Management Service Account wasn’t the issue we granted our Application Pool Account under which the Web Applications are running, the “SPDataAccess” permission on our logging database.

Recently I stumbled over out ULS Logs on the Web Frontends. Suprisingly they were empty, 0 bytes. I checked the permissions for the account the tracing service is running with (Web Application Pool Account). Everything was fine, same permissions as on the other servers where it was working.

So I checked the local groups and found out the tracing account must be a member of the “Performance Log Users”. Add the account, restart the “SharePoint Tracing” Service and you will see the uls logs growing.

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 – The specified network name is no longer available.)”

This message only appeared on one out of five servers. No reboot, no iisreset resolved the problem.

We resolved the issue by moving the database to another sql node (FailOver / Always On). When you move the database all connections will be forcibly closed. Seems that the sql server doesn’t allow the server to connect to the database as some connection was still established. If you can’t move the database to another node, simply restart the instance or put the affected database in single user mode to close the connections.

“Each SharePoint service application must run the C2WTS locally. The C2WTS does not open any ports and cannot be accessed by a remote caller. Further, the C2WTS service configuration file must be configured to specifically trust the local calling client identity.”

Its mandatory that the Claims2WinowsTokenService runs on ALL WebFrontends and Backend Servers! (don’t think its necessary on real Backend Server without user interfaces like search server)

Specifies the name of the Active Directory organizational unit (OU) that servers must be a member of to join the Office Web Apps Server farm. Use this parameter to prevent unauthorized servers (that is, servers that are not in the OU) from joining an Office Web Apps Server farm.

But how to apply this setting? As using the DN of the OU does not work you need to use the Canonical Name of the OU. If your machines are located in CONTOSO.COM/Computers/OfficeServer/SERVERNAME1 you need to use the following command: