Идентификатор события: 36888 Создано следующее критическое предупреждение: 10. Состояние внутренней ошибки - 10.

Мы чаще всего сталкиваемся со следующими ошибками schannel на наших терминальных серверах удаленных рабочих столов.

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>

Иногда мы получаем его на нашем сервере Exchange или сервере IIS, однако в основном это происходит с наших терминальных серверов удаленных рабочих столов, на которых работает 64-разрядная версия 2008 R2. Как вы можете видеть на следующем графике, мы часто получаем всплески, подобные этому полу. На этом графике показан 1 терминальный сервер за последние 12 часов, который дал нам 407 ошибок.

Есть предложения о том, как выяснить, что вызывает эти проблемы? Должны ли мы просто отключить отладку каналов?

windows-event-log schannel

Я бы не стал отключать их регистрацию, но и не беспокоился бы о них. Я считаю, что эта страница должна содержать больше информации: https://msdn.microsoft.com/en-us/library/windows/desktop/dd721886%28v=vs.85%29.aspx.

По-видимому, это связано с SSLv3, поэтому, возможно, это связано с подключением старых клиентов или проблемами сети между клиентами и сервером RDP.

Вы можете попытаться выяснить, кто на самом деле входит в систему в это время, и попытаться сопоставить ошибку канала с успешным или неудачным входом в систему.

Эти ошибки точно коррелируют со сбросом TCP-соединений, когда кто-то пытается подключиться и войти в систему через порт 3389 ms-wbt-server. Если человек выходит из строя «черный ящик» безопасности системы, то входящее соединение прерывается пакетом сброса. Сообщение об ошибке, которое вы видите, затем выводится в системный журнал Windows. Если вы все еще сталкиваетесь с этим в большом количестве, возможно, вы захотите изменить порт прослушивания с 3389 на что-то другое и посмотреть, уменьшатся ли ошибки.