SharePoint 2013 Web Applications requests not logged to ULS logs


Issue

Ever since I built my dev VM with SharePoint 2013 and least privileged installation it had this issue where no user requests entries (Info, Error, Unexpected, …) would get logged to the SharePoint ULS logs. At first I blamed it on SharePoint of course, but CU after SP after PU did not fix my issue so it couldn’t be that. And no other of the environments I set up were affected by this issue.

What _did_ get logged:

  • Every other process (Distributed Cache, OWSTimer, NodeRunner, …)
  • Central Administration requests
  • Service Application requests

My least privileged installation is pretty basic stuff:

ACCOUNT

DESCRIPTION

DOMAIN\sp_farmadmin

Farm Administrator is used for the Timer Service and Central Administration AppPool Identity.

DOMAIN\sp_setup

Installation account. Requires local admin rights on SharePoint and dbcreator and security admin on SQL Server.

DOMAIN \sp_contentapps

AppPool Identity for SharePoint sites

DOMAIN\sp_serviceapps

AppPool Identity for SharePoint Service Applications.

DOMAIN \sp_search

Search Content Access account for indexing data.

DOMAIN\sp_superuser

Super User account for object caching.

DOMAIN\sp_superreader

Super Reader account for object caching.

DOMAIN\sp_ups_sync

User Profile synchronization account to Active Directory. Requires "Replicate Directory Changes" on the domain. http://technet.microsoft.com/en-us/library/ff182925.aspx#permission

 

Since this is a dev VM you can imagine this being a real pain troubleshooting bugs and flow. Until today, because on one attempt I changed the Service Account for the Content Application Pool (DOMAIN\sp_contentapps) to the Farm Administrator and POOF! my logging had returned:

image

Cause

So what was wrong with this DOMAIN\sp_contentapps? I decided to fire up the awesome ProcMon (filter on User Name, exclude all “Success” entries) to see what exactly was going on:

image

It was trying to load that user’s Windows profile from disk but somehow ended loading up a temporary profile:

 image

Look for Event ID 1511 in the Application Event Log and you’ll find a corresponding entry:

image

Solution

Microsoft have provided us with a few options to resolve this in the following KB Article: http://support2.microsoft.com/kb/947215/en

  • Open the Registry Editor
  • Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  • Find the key starting with S-1-5 and ending with .bak
  • Remove the .bak suffix (if you can’t rename because a key already exists you have to rename the latter in two steps so it ends up having the .bak suffix)
  • Click on the renamed key (without suffix) 
    • Set the value for “RefCount” to 0
    • Set the value for “State” to 0
  • Reboot
  • Log in & out with the account (you may need to temporarily grant it access to do so) so the profile folder gets created
  • Ensure that the correct profile folder is present
  • Ensure that the application pool is started (likely it failed after the reboot because of the missing profile folder)
  • (Optional) Clean up the “.bak” registry key and corresponding temporary profile folder

So conclusion; I probably at some point deleted that profile folder for who knows why, but it had some unforeseen consequences…

HTH

 


Links to this post

Comments

CAPTCHA Image Validation