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:
Farm Administrator is used for the Timer Service and Central Administration AppPool Identity.
Installation account. Requires local admin rights on SharePoint and dbcreator and security admin on SQL Server.
AppPool Identity for SharePoint sites
AppPool Identity for SharePoint Service Applications.
Search Content Access account for indexing data.
Super User account for object caching.
Super Reader account for object caching.
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:
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:
It was trying to load that user’s Windows profile from disk but somehow ended loading up a temporary profile:
Look for Event ID 1511 in the Application Event Log and you’ll find a corresponding entry:
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
- 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…