Event ID: 36888 The following fatal alert was generated: 10. The internal error state is 10

Question

We are experiencing the following schannel errors most frequently on our Remote Desktop Terminal Servers.

Log Name:      System
Source:        Schannel
Date:          11/18/2015 1:04:56 PM
Event ID:      36888
Task Category: None
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      RD2.{removed}.com
Description:
The following fatal alert was generated: 10. The internal error state is 10.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" />
    <EventID>36888</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2015-11-18T18:04:56.498068400Z" />
    <EventRecordID>1969389</EventRecordID>
    <Correlation />
    <Execution ProcessID="572" ThreadID="48732" />
    <Channel>System</Channel>
    <Computer>RD2.{removed}.com</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="AlertDesc">10</Data>
    <Data Name="ErrorState">10</Data>
  </EventData>
</Event>

Occasionally we will get this on our Exchange server or an IIS server, however it is mostly from our Remote Desktop Terminal Servers that are running 2008 R2 64bit. As you can see by the following graph that we get spikes such as this semi frequently. This graph is of 1 terminal server for the past 12 hours which gave us 407 errors.

Any suggestions on how to find out what is causing these issues? Should we just disable schannel debugging?

Solution

I wouldn't disable logging those, but I would not be concerned about them. I believe this page should give more information: https://msdn.microsoft.com/en-us/library/windows/desktop/dd721886%28v=vs.85%29.aspx.

Apparently this is connected to SSLv3, so maybe it's related to older clients connecting, or network issues between the clients and the RDP server.

You could try to investigate who actually logs on during those times and attempt to correlate the schannel error with a successful or failed logon.