While troubleshooting an issue recently on a Windows Server 2016 system, I noticed errors on the System event log about the Data Sharing Service crashing.
Searching online for more information about this service and why it might be failing, I came across a lot of people describing similar problems, but the only explanation and solution I found came from this December blog post by Microsoft Japan. Google translate did a great job making the post understandable to me, but since the information doesn't seem to have been widely publicized I thought I'd share it here to help get the word out.
The Data Sharing Service fails due to a resource conflict with another service included in Server 2016, the User Access Logging Service. Either one of these services alone will run without issue, but if one is already running and you try to start the other, it will fail.
According to an update to the blog post, Microsoft plans to resolve the issue in a future update to Server 2016, but …
CarbonBlack recently released version 3.1 of the 'sensor' for their CB Defense product. This sensor is the client side agent installed on each PC. The CB Defense sensor does not self update, but installing the new version should be as simple as a few clicks in the CB Defense web console or downloading the install package and deploying it using your favorite method. Unfortunately, it's not always so simple.
In many cases, when the installer attempts to remove the old version of the sensor during the upgrade process, the uninstall does not completely remove the old sensor, and installation of the new sensor fails. This leaves the computer with no working version of the CB Defense sensor installed. The old version of the sensor no longer shows up under "Programs and Features", and all attempts to install the new version fail.
Recently, I ran into an issue with computers running windows 10 that would not connect to our WPA2-Enterprise encrypted wifi network. When it failed to connect, there was no indication of why, only the message "Can't connect to this network." The computers were able to connect to unencrypted networks and networks using a Pre-shared key for WPA encryption without issue.
Checking the event logs on the RADIUS server to see why the comptuer failed to connect, there was no log entry for a connection attempt from the affected system. The WLAN-Auto-Config log on the client listed a couple of errors, including Event ID 11006 and 12013, but other than showing that the failure reason was "Explicit EAP failure received", they didn't give much to go on: