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 ( - Contact me direct: or call 704-873-8846 x704.

Search This Blog

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:
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\.
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:

Problem solved!!

About us:
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: –
Keep up with the latest articles and tips around SharePoint from author & CEO David Sterling via and his personal blog site: or contact him directly at


Jussi Palo said...

Why grant permissions on 14/15 level, and not only on LOGS folder? I did it on LOGS lever, and it fixed the issue.

Anonymous said...

I received this error on an SBS 2011 Standard box. The service runs under LOCAL SYSTEM on a plain vanilla SBS 2011 install. I applied Full Control perms to that account on the LOGS folder and cycled the Tracing service. No errors at this time. Thanks for the excellent write-up. - Mike

Unknown said...

You should also check the permissions and the membership of the local WSS_WPG group. The TraceService service account should be a member of that group and it should have modify permissions to the LOGS folder.

After modifying the permisisons for that group on the LOGS folder and restarting the Trace Service logs started to be populated in the correct folder once more.

Jigs Gaton said...

I really appreciate folks like David who take the time to post clear fixes for something like this. Sharepoint is a bear, and this helped :)

Mike Lefebvre said...

%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS\
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS

fixed it for me

Tristan Payne said...

Thanks Mike - that worked, Sharepoint seemed to set its permissions correctly by resettgin the directory - I set it back to %commonprogramfiles%\etc - all seems to be good now.