Exchange 2013 / Exchange 2010, Windows Server 2012 – SChannel Event ID:36888 (1203) – TLS/SSL error – The root cause

I have problems in some environments, where these SChannel errors are generated. Well. It took me several days to find reasonable “why” it is logged.

Problem:

The event ID from the picture can be seen from time to time:

EventID-Error

Solution:

Based on several articles I have read and some discussions. First you have to make sure, that the process causing this error is LSASS.exe, which is by the way local security authentication server (authenticating users to winlogon service, using authentication such as msgina.dll and so on). To make sure it is LSASS.EXE. Open Event ID and check the Event ID details, Click on Details tab -> Expand System while friendly view is selected. Check Process ID.

EventID_Details

Then use powershell and run:

Get-Process | select name,id | sort id

Result should give you the name of the processes. It will be lsass.exe.

Why:

Reason is simple. Not standard or corrupted behavior of web browsers or users. The problem behind SChannel and Exchange 2012 is, that sometimes users use HTTP protocol, but on port 443, which expects certificates exchange rather than GET command.

How to test:

Option 1#:

Test is easy. For example you can input URL to your browser address bar, which is obviously wrong and see the results: HTTP://MAIL.DOMAIN.LOCAL:443/OWA – It says to use HTTP protocol (not HTTPS) on the 443 port and it generates errors immediately.

Option 2#:

Run Telnet and test command:

Telnet localhost 443 (to connect to HTTPS)

In Telnet window:

Get /index.htm (on HTTPS SSL must be established first so it will generate errors immediately. Result will not be seen in telnet window)

What is the solution?

Solution #1:

Some IT guys recommend to disable SCHannel logging to get rid of these events, but I cannot recommend that. To be honest. It is better to see, that somebody is trying to connect using HTTP on HTTPS port, because this might be some attempt to DoS attack or info, that users don´t know how to type OWA URL correctly. Shortly it is better to know something is wrong than disable logging.

Solution #2:

I suspect wrong redirect configuration for the websites from HTTP to HTTPS. I would check IIS if redirect is set correctly. For those having this issue without redirect I would suspect problem in web browser area.

Links:

To test SSL via command line:

http://www.bearfruit.org/2008/04/17/telnet-for-testing-ssl-https-websites/

LSASS description:

http://www.neuber.com/taskmanager/process/lsass.exe.html

How to revive Exchange server 2013 + Windows Server 2012 DC from ash – part 2. – DC installation

This part has been done in GUI in my case, however, better is to do it in PowerShell and here are the steps. To install DC on Windows Server 2012 we just need to:

1. Install windows feature Active Directory Domain Services
Open PowerShell and type “Add-WindowsFeature AD-Domain-Services” Enter

Add-WindowsFeature AD-Domain-Services

2. Install windows feature DNS
type “Add-WindowsFeature DNS” Enter

Add-WindowsFeature DNS

3. Install windows features for administration (RSAT*)
type “Add-WindowsFeature RSAT*” Enter

Add-WindowsFeature RSAT*

Once windows features are installed, we can promote computer to DC:
4. Install new DC to existing forest / domain / Site
DC should be GC as well.

Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'domain.local' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Default-First-Site-Name' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$true -Force:$true -Credential (Get-Credential) -ReplicationSourceDC Server2.domain.local

Next step is to recover Exchange server on the DC.