Category: Windows Server 2012 R2

KB5009624 Causing Some Domain Controllers to Reboot

Update: This issue has been resolved with new updates released by Microsoft.

Today, I had the pleasure of troubleshooting why a domain controller was continually, and randomly, rebooting itself. Though, rebooting is a light term, when the reality was the server was entering a fault state (aka, crashing) and rebooting to recover. Inspection of the event logs revealed Event ID 1074, which stated:

The process wininit.exe has initiated the restart of computer on behalf of user32 for the following reason: No title for this reason could be found

Reason Code: 0x50006

Shutdown Type: restart

Comment: The system process ‘C:\Windows\system32\lsass.exe’ terminated unexpectedly with status code [blank]. The system will now shut down and restart.

One or two Google searches later, refined to display only from the past week, I found a post where someone figured out that Microsoft Window’s Server 2012 R2 Security Update KB5009624 was the cause of the reboots, further detailed here.

Microsoft did release an emergency out of band update (KB5010794) though it is listed as an Optional update. So if you are not in the habit of installing those optional updates, now is a good time to start.

However, if you don’t want to install that optional update (for whatever reason), this fix is simple enough: either go to Windows Update -> Installed Updates -> and select it and click Uninstall; or, go to Control Panel -> Programs and Features -> View Installed Updates -> and select it and click Uninstall. (Note: a reboot will be required).

SMTP Stopped Sending Mail to Office 365

Had a client whose SMTP server suddenly stopped sending scan to e-mails to their domain cloud Office 365 e-mail from their on-premise SMTP server. The queue folder quickly filled up with over a hundred e-mails, so what could have caused this problem?

After three days of troubleshooting, I finally figured it out. In the event log, I was seeing the following issue:

A total of three IP addresses were rejecting the mail, which never even left the queue folder to generate a log in the badmail folder. The three IP addresses were ‘207.46.163.42’, ‘207.46.163.74’, and ‘216.32.180.10’. A cursory search on Google revealed these to be Microsoft servers.

Now this worked perfectly just a few days ago, with no error message like it in the event logs prior to the 23rd of January, 2018. Could it really be this simple of a fix? I tried resetting IIS 6.0, started and stopped the SMTP service many time. I added smtp.office365.com as a smart host, I added a relay as detailed in several websites (including Microsoft’s), and I event played with different settings. Nothing worked… but I did notice occasionally a few e-mails would kick off at a time before failing again as I made changes. Now, I can’t say I know a lot about TLS, but it is my understanding that TLS required authentication and had to go across port 587.

Apparently not. I went back into IIS 6.0 Manager and right clicking on SMTP Virtual server and went to properties. Under the delivery tab, I clicked Outbound Security… at the bottom. There I clicked TLS encryption. I made zero other changes.

I clicked OK and then clicked apply. I didn’t even have to restart the SMTP service – all the e-mail in the queue folder cleared out within moments. Finally, a victory. As a final test, I sent test scans to our domain e-mail account from the Xerox SMTP configuration as well as sending another IT technician to send scans at the printers to themselves. It all worked like it should.

I’m not entirely sure why this works, but I would love if someone could fill me in. Remember, it worked days ago, then suddenly it stopped working until I enabled TLS encryption. I did not configure any ports other than 25.