Do you recognize this? When starting Central Administration the Health Analyzer detected some issues, especially this one:
SharePoint 2010 tells you to use a domain account for its services and application pools. Do not use Local System or Local Service. Now most of the mentioned services can be changed by going to Security, Configure Service Accounts.
Now, what about the Windows Services like SPTraceV4? There are two ways to do this:
- Administration Tools, Services on every SharePoint server
- PowerShell script
Make an educated guess what I prefer… 
Here’s the PowerShell script I used:
# Get the tracing service.
$farm = Get-SPFarm
$tracingService = $farm.Services | where {$_.Name -eq "SPTraceV4"}
# Get the "svc_sp_services" managed account.
$managedAccount = Get-SPManagedAccount "Domainaccount"
# Set the tracing service to run under the managed account.
$tracingService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$tracingService.ProcessIdentity.ManagedAccount = $managedAccount
$tracingService.ProcessIdentity.Update()
# This actually changes the "Run As" account of the Windows service.
$tracingService.ProcessIdentity.Deploy()
The cool thing is that every SharePoint server is now updated!
At this moment when you Reanalyze the issue in the Health Analyzer the issue will disappear. Great!
The next day
I thought I was done. Apparently not. SharePoint does not tell you when changing the built-in account to a domain account, that you also need to do some additional settings for that account. What did I notice? All my log files were 0 bytes! Oops…
Do I need to set SharePoint Trace service back to Local Service or do I need to change the NTFS permissions to that folder? Well… the latter one comes close. After some Bing moments I found the answer. The domain account needs to be a member of the group Performance Log Users on all SharePoint servers. So I did. W00t!
Another lesson learned… Have a nice day!
Thank you! I modified the script a little.
# Get the “svc_sp_services” managed account.
[string]$domainName = ([ADSI]”).name
$Account = “CHANGE TO ACCOUNTNAME”
$managedAccount = Get-SPManagedAccount $domainName$Account
# Get the tracing service.
$farm = Get-SPFarm
$tracingService = $farm.Services | where {$_.Name -eq “SPTraceV4”}
# Set the tracing service to run under the managed account.
$tracingService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
$tracingService.ProcessIdentity.ManagedAccount = $managedAccount
$tracingService.ProcessIdentity.Update()
# This actually changes the “Run As” account of the Windows service.
$tracingService.ProcessIdentity.Deploy()
# AddUser to local group “Performance Log Users”
([ADSI]”WinNT://$env:computerName/Performance Log Users,group”).Add(“WinNT://$domainName/$Account”)
Better late then never… 🙂
Thanx for the extended script!
Thanks, your post saved me a lot of time :o)
I also added SharePoint Trace service to Performance Monitor group. Then the annoying message disappeared when I restarted the whole server farm.
Its not working. After I set domain account as SPTracev4 account, it stopped logging, and I am getting empty infos in log.
Peter,
Sorry for the late reply, but did you also add the account to the Performance Log Users group as I mentioned at the end of my post?
grtz,
Octavie
Thank you for posting this, it was really helpful. Although I added the account to the Performance Log Users group as you stated above, I still was receiving 0 byte log files.
It wasn’t until after I restarted the SharePoint 2010 Tracing and SharePoint 2010 Timer services that my logs started filling again. I thought it would be helpful to share.
Thanks again for posting!
I know this is an old thread but:
I have found that when following all of the above guidance, that everything goes to hell when it’s time to change the service account’s password.
Using SharePoint to change the password works all well and good except SharePoint does not change the Identity’s password for the Windows service. When farm servers start rebooting (for patches or whatever), the SPTracingV4 service tries to start but it can’t because it still has the old password for the account in the Identity section. Result: No more logging.
Since I am required to use “Automatic Password Changing” in my SharePoint farm, the ULS logs become useless. Unless someone can provide additional suggestions, I must keep my SPTraceV4 service set to run under the Local Service account. My SharePoint Health Monitor doesn’t complain about it either for some reason. Someone must have removed the Timer job that checks that.