I am running SQL Server 2017 Standard CU 5 in a failover cluster with two nodes (single instance cluster). I have followed these two manuals to deactivate CEIP aka spyware features:

  • The CEIP service is disabled and stopped,
  • the CEIP role removed from the cluster
  • and all registry entries regarding CustomerFeedback and EnableErrorReporting are set to 0.

However I still get the message "Software Usage Metrics is enabled." in SQL Server error logs after a service restart. Additionally there are frequent errors from ESENT like the following in my windows event log:

ESENT error access denied

There is a MS Knowledge Base article for this problem. However it is for SQL Server 2012. It says that this error is related to the "Software Usage Metrics feature". I already followed the advice to grant permissions for the SQL Server service account. However the error message keeps appearing and I don't want Microsoft to collect data anyway.

Here are my questions:

  1. Is that the same feature as the CEIP stuff or something else?
  2. How do I deactivate Software Usage Metrics correctly?

1 Answer 1


I'll point out that disabling SQLCEIP's service is not a supported configuration, so while you can disable sending information to Microsoft in the paid versions of SQL Server 2016+, the proper mechanism for doing this is documented here:


(This would leave the SQLCEIP service running and not emitting information to Microsoft). Microsoft recommends you follow documented procedures to make sure that when you are engaged with customer support on an issue they can help fix that issue quickly.

As to your specific question about what this "extra" session is, that feature is not something that is emitting information out to Microsoft. It is a feature that enables a tool that customers can use to determine how many copies of SQL they have running in their organization. The data emitted from SQL goes into a file on the local Windows machine. You can use the tool yourself to see what it does - it is called the Microsoft Assessment and Planning Toolkit, and you can download it here:


As for whether SQLCEIP is "spyware", I'll try to make sure that you have full information about what kinds of information is collected/not collected through the SQLCEIP mechanism. Microsoft does not try to capture keystrokes, customer data, or otherwise use information we collect to market to customers at all (as you might find in a traditional definition of spyware such as https://simple.wikipedia.org/wiki/Spyware ). The information collected through SQLCEIP is used to make sure that features are working well for customers both during the development cycle of a new version of SQL/new features and to make sure that we understand how our customers use the product so we can make it better. We don't collect information to personally identify anyone and we don't want to know who you are or what you do individually. We are interested in "how many people use Columnstore indexes?" and "how many rowgroups inside of a Columnstore index are optimally packed so that the customer is likely to get a good performance experience?". The information collected help us make sure that our engineering teams have done a complete job at making each feature work for customers.

You can audit all the information collected by SQLCEIP to see this for yourself. The instructions are here:


Furthermore, we document our privacy policies about what kinds of information we collect/do not collect. Microsoft recently re-vamped all parts of the company to use a single privacy statement, but SQL has a supplement which is aligned closely with its former separate privacy statement since we wanted it to be easy to read/understand and not get lost in the data collection policies for the other consumer services Microsoft provides.

Here's the top-level Microsoft privacy statement:


Here's the privacy supplement for SQL Server:


I hope that this answers your questions as to what the software usage metrics mechanism is and why it is not sending information to Microsoft/related to SQLCEIP.

  • Your first link goes to SSDT, not SQL Server. I don't have those registry keys on my clean SQL Server box without VS or SSDT etc
    – gbn
    Commented Oct 2, 2018 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.