Tracing Service failed to create the trace log file at location specified in SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS\LogDir. Error 0x0: The operation completed successfully. . Traces will be written to the following directory: C:\Users\SPSERV~1\AppData\Local\Temp\.
SharePoint Experts, Information Architects, Expert Witness
We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: firstname.lastname@example.org or call 704-873-8846 x704.
Thursday, January 31, 2013
SharePoint 2013 Event ID 2163
After installing SharePoint 2013, you might come across an issue where you see an Application Event ID 2163 start popping up. While it may seem innocuous, it actually will cause multiple problems down the road.
The error is effectively telling you that the SharePoint Tracing Service is not able to write to the SharePoint log folder; when it cannot, it will write to the account local folder (under AppData). This means the service will not really work because the local user folder is not accessible to other SharePoint accounts and services.
The Event ID 2163 error message will be something like this:
In the System Application Event log, the message looks like this:
As you can see, the account that's having the problem is indicated. Sorting this all out is pretty simple - what it really means is simply that the account running the service (SPService as shown) doesn't have permissions to write to the SharePoint Log file directory.
If you open up the Services (Start > Administrative Tools > Services or Start > Run... then enter services.msc and click OK) and locate the SharePoint Tracing Service, you can determine the account in use:
The confusing part about the message is that it indicates not the physical path to the log files but the Registry setting (HKEY_LOCALMACHINE/Software/Microsoft/Shared Tools/Web Server Extensions/15.0/WSS) - remember, by default, the SharePoint logs are located in c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Logs but if you are working in a production environment, the logs are probably (or should be) located elsewhere. You might already know where they are but if you don't, you can easily use the setting to find them - if you open the Registry editor (Start > Run... then enter regedit then click OK) then follow the path, you will see the "LogDir" setting (FYI don't make any changes here):
As you can see, this is the default setting - %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS\ - that is, the default path mentioned above.
Using Windows Explorer, navigate to the location specified - (by default, c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\). Right click on the folder and select Properties then click the Security tab:
As you can see, the account in question here (SPService) is a managed account and would NOT be a member of the Administrators group so by default, it has no access here. Click the Edit... button, add the account and give it Full Rights to this folder:
Click Apply then OK then close out the properties window (Side note: it is not a bad idea to add the SharePoint Farm account with full permissions here).
Once this is completed, a reboot is suggested but not necessary and may not be possible in a production environment; you can optionally use the Services (Start > Administrative Tools > Services or Start > Run... then enter services.msc and click OK) - right click on the SharePoint Tracing Service and select Restart:
Sterling International Consulting Group is a specialist in enterprise systems including architecture, governance, business continuity, and disaster recovery planning with over 28 years in IT and management consulting. SICG also has a dedicated practice in SharePoint Technologies and Microsoft Technologies. From planning to analysis to development to deployment, SICG has the experience and knowledge to understand the best for your business – find out why: email@example.com – www.sterling-consulting.com.
Keep up with the latest articles and tips around SharePoint from author & CEO David Sterling via http://www.sharepoint-blog.com and his personal blog site:http://davidmsterling.blogspot.com or contact him directly at firstname.lastname@example.org.