An interesting update on the story of SQL 2016 auto-updating and phoning home

An architect of the SQL Server team, Conor Cunningham, responded to Brent Ozar’s post from last week.  In it he states that the information that Brent posted was not entirely accurate.

First, the auto-update issue.  Conor says that when you run the setup program, if the system is connected to the internet, it will look for certain critical hotfixes and download them for you.  They had problems with the VC runtime.  Otherwise, any patching after installation is controlled by the server administrator through the usual Windows Update methodology.

He also notes that SSMS 2016 is now a discrete product and has monthly update pushes that may not correspond to updates for the actual database engine or other DB components.

Next, the ‘phone home’ issue.  It appears that it is indeed opt-out, but it’s easy to configure to not send telemetry UNLESS you’re using the free version.  I’m unclear whether that’s just the SQL Express edition or if it would include the Developer edition.  He also states that this telemetry can easily be blocked by firewalls.

The full text of Conor’s reply is below this cut, and this link will take you back to the original post.

Brent, with respect I think your post is mixing a few things and could be clearer to avoid confusing SQL users. I will attempt to clarify here, but I hope you will consider separating/editing this post into separate topics and more crisply cover the details.

First, SQL Server 2016 contains a setup-time feature we call “smart setup”. On servers connected to the Internet, the setup will check to see if there are any critical hotfixes that are needed and download them for you. It so happens we ended up needing to use this capability- we had a problem with the RTM bits that we discovered at the end of the development cycle where a needed patch to the VC runtime was not properly installed. The smart setup feature will download and auto-install this for you if you are connected to the Internet, avoiding crashes in production. You can read about that patch here: . So, you can avoid having to install this patch manually if setup can connect to the Internet and get this patch for you.

We also have other avenues to install the patch via Windows Update and through a release of a full new installer which can work in environments that don’t connect to the Internet. There is no requirement that you be connected to the Internet to run setup, but in this case it helps you avoid a manual step during the installation process.

Regarding usage data collection, we did make a change to the product to move from an opt-in to an opt-out model for this collection in SQL Server 2016. Note that SQL Server 2014 and prior also send usage data to Microsoft when sending usage data is enabled. We’ve published a KB article explaining how to disable the feature for each component for customers that have any concerns or regulatory issues. The capability to disable can not be turned off in free editions, and this is a change from prior releases. It is also possible for firewalls to block telemetry transmission if the customer’s network is set up with such a capability (even with free editions, if you are so inclined).

Please note that this is _not_ a mechanism for delivering features to customers (a la Windows forcing upgrades to Windows 10 or forcing feature packs on customers). It might be clearer if your post separated the smart setup capability from the telemetry capability to make it more obvious that these are not the same features are not identical to what Windows did with Windows 10.

It is also worth noting that some features in SQL Server, such as Management Studio, have moved to shipping regularly (monthly) outside of a given release of SQL Server. So, please note that there are separate capabilities for how some of those are disabled vs. how SQL Server’s relational engine or Analysis Services components are disabled. We expect to deliver features much more quickly in those components going forward – the reason for splitting them is unrelated to usage data.

We’re working on improving/clarifying the usage data documentation (which we described to you on the internal MVP forum before you made this post but are not 100% done with yet) so that we can address any concerns that customers may have about this change. Microsoft is not collecting sensitive information about your data in the data sent to Microsoft – most of what is being collected is of the form “are you using feature X” and “is the performance of working as we expected?” or “what errors are happening on this instance of SQL?”. Microsoft is not collecting your passwords or values from inside of user tables in the usage data sent to Microsoft.

Like in prior versions, sending crash dumps to Microsoft shares the memory state of your server in the crash sent to Microsoft and that _can_ contain user data. Microsoft has policies to restrict the usage of the crash data to improve the product (fix the bug that caused the crash, assuming it is a product bug) and to keep that data within Microsoft. We don’t look through crash dumps except to determine how to fix bugs in our code so that you can get fixes more quickly than you might otherwise get them.

We are happy to talk with any concerned customers directly if there are specific regulatory concerns about usage data being shared with Microsoft. We are working on a more detailed document to cover questions of the kinds of data collected and specifically not collected to address customer concerns about what is being collected, and we hope to make that far more visible to customers in subsequent updates so that you can evaluate what data is being sent more easily. Microsoft has been able to find and fix significantly more bugs in SQL Azure than in earlier versions of SQL Server by using usage data more proactively to identify and fix problems, often before customers even know they have a problem. For example, we have been able to tell customers that they have performance problems or corrupt indexes proactively in our service, and customers have been extremely happy when we tell them about problems proactively. We’ve also found and fixed bugs that otherwise would require CSS cases to get fixes, costing customers time and effort to get a patch from Microsoft. We are hopeful that we will be able to more proactively help our customers have a great experience on SQL Server 2016 and beyond with this updated policy for customers who send usage data.

I hope this clarifies some of the confusion on this thread. We will continue to work on improving the documentation to help inform customers about what kinds of data is collected and how it is used to make sure that each customer can make informed choices about whether they wish to enable or disable telemetry collection.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s