Troubleshooting SharePoint requires understanding the 8 Windows Services the platform depends on. Use this table to help identify services while researching issues. Also, pay attention to the account the service uses to run.
All of the services run with the permissions of the Local System with the following exceptions:
- SPTimerV3 runs as the account you designate in the SharePoint Configuration Wizard as the Farm Account
- OSearch runs as the service you configure for it in Central Admin
SPTimerV3, using the OWSTIMER.EXE, leverages SPAdmin, using WSSADMIN.EXE, when the Local System permissions are needed in a Timer Job. This allows a much wider set of modifications to be made to the system than even the Farm Account allows.
Services are identified differently during different troubleshooting steps.
For example, stopping the timer service can be accomplished two different ways:
- From the command line, you would enter net stop SPTimerV3
- In the Services Control Panel, you stop Windows SharePoint Services Timer
Further, if you were debugging a custom timer job, it would be important to know the name of the executable is OWSTIMER.EXE. Notice how each method of identification starts with a different letter in this case. This is an easy gotcha! if you are not aware of the differences.
How are services identified in the Event Log and the ULS Log? One answer: inconsistently!
|Service Name||Display Name||Description||Executable Path||Runs as|
|SPTimerV3||Windows SharePoint Services Timer||Sends notifications and performs scheduled tasks for Windows SharePoint Services||[12 hive]BINOWSTIMER.EXE||Farm Account|
|SPAdmin||Windows SharePoint Services Administration||Performs administrative tasks for Windows SharePoint Services||[12 hive]BINWSSADMIN.EXE||Local System|
|SPSearch||Windows SharePoint Services Search||Provides full-text indexing and search to SharePoint user and help content.||[12 hive]BINmssearch.exe||Local System|
|SPTrace||Windows SharePoint Services Tracing||
Manages trace output
|[12 hive]BINwsstracing.exe||Local System|
|SPWriter||Windows SharePoint Services VSS Writer||Windows SharePoint Services VSS Writer||[12 hive]BINSPWRITER.EXE||Local System|
|OSearch||Office SharePoint Server Search||Provides enhanced indexing and search for Office SharePoint Servers content. Replaces the Windows SharePoint Services Search service for search over SharePoint user content.||[MOSS Install]binmssearch.exe||Service Account|
|DCLauncher||Office Document Conversions Launcher Service||Launcher for Microsoft Office Server Document Conversions Services||[MOSS Install]binMicrosoft.Office.Server.Conversions.Launcher.exe||Local System|
|DCLoadBalancer||Office Document Conversions Load Balancer Service||Load Balancer for Microsoft Office Server Document Conversions Services||[MOSS Install]BinMicrosoft.Office.Server.Conversions.LoadBalancer.exe||Local System|
|Legend||[MOSS Install]||C:Program FilesMicrosoft Office Servers12.0|
|[12 Hive]||C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12|
"So, how do you avoid the elevation of permissions if your solution must perform a security-sensitive operation? A good technique is to split the solution into multiple components and use a secure interprocess communication mechanism between them. You can then run the component that requires administrative permissions in the context of the local System account, while the other component runs in the context of the SharePoint security account. Microsoft uses this technique in the SPTimerV3 service. SPTimerV3 runs without administrative permissions in the context of the SharePoint farm account and relies on the Windows SharePoint Services Administration (SPAdmin) service to perform administrative tasks on the local server. The SPAdmin service runs in the context of the local System account. SPTimerV3 and SPAdmin use .NET Remoting for interprocess communication, yet you can also use a lighter weight mechanism, such as named pipes, as long as you protect the communication facility by means of access control lists (ACLs). In the sample solution, I use the named-pipe approach."
From: Use SharePoint to Manage Your Windows Services, Pav Cherny, MSDN Magazine, April 2009