First published on TechNet on Aug 21, 2017
Hello, my name is Chuck Timon and this is my first blog post as a Premier Field Engineer. Previous to my current position, I posted to the Core Team blog and the System Center: Virtual Machine Manager Engineering Blog . In this post, I examine a customer issue where two cluster network name resources in a 2-Node SQL 2012 Failover Cluster Instance (FCI) running in a Windows Server 2012 R2 cluster failed to come Online on one of the nodes in the cluster. The Network Name resources were associated with an MSDTC Resource Group and the SQL Server Resource Group. When troubleshooting Failover Clusters, where you can reproduce an issue on demand, it is best to examine the System Log (the Failover Cluster provider registers events in the System log) on the Node where the failure occurs and also gather the cluster log itself where more detailed logging is available. To gather the cluster log, use the Get-ClusterLog PowerShell cmdlet. Here is an example of collecting a cluster log on a cluster node where a problem occurred, placing the log in the C:\Temp directory, collecting data from the last 2 minutes (which contained the error) and generating the log using the local time on the host. 
Decoding the 2114 error indicated that one potential cause was the Server Service was not starting.
Initially, this seemed pretty odd because the Server Service is very reliable, but it was worth a look. Opening the services snap-in, showed that the Server Service had not started even thought it was set to start automatically (default setting). We tried starting it, and it failed with the following error –
Inspecting the Properties\Dependencies of the Server Service, showed there was information missing in the customer environment –
Next, I inspected the following registry entries on both nodes in the cluster for differences and found none. HKLM\System\CurrentControlSet\Services\Lanmanserver HKLM\System\CurrentControlSet\Services\Srv2 HKLM\System\CurrentControlSet\Services\SamSs I was specifically looking for a key value that indicated one or more dependent services were 'marked for deletion' like the error message stated. Not finding that value, I used the SC command line utility to query the appropriate services and determined the Lanmanserver service was stopped and could not be started on the cluster node. Normal output using the SC command looks like this –
The customers' output reflected a 'State' of STOPPED. At that point, the decision was made to export the HKLM\System\CurrentControlSet\Services\Lanmanserver registry key (on the problem server) to the desktop, remove the DependOnService entry in the key (so something would be different when re-registering), and reboot the server. Following a reboot, the exported registry key was used to re-register the service, and then the Server Service was able to start. The customer moved all cluster resources to the problematic node and all the Network Name resources that previously failed to come Online, were able to successfully come Online thus making SQl services once again highly available in the 2-Node cluster. Thanks for reading our blog, and I hope you found this helpful.