Monday, March 26, 2018

Binding a Certificate breaks IMAP or POP on Exchange - NO LOGIN failed error

A customer of mine running Exchange 2013 CU17 went to renew the Exchange Certificate after it expired.  The customer even though they were not using secure IMAP bound the new certificate to IMAP, POP and IIS.

The customer has a line of business application which uses unsecured PlainTextLogin on the internal network to a single mailbox to receive invoices and email traffic.  When using PlainTextLogin without encryption you want to ensure this is not exposed to the Internet.  In my case, my customer did not have IMAP directly exposed to the Internet and was kept secure.

The following screenshot shows the new certificate installed on the Exchange server bound to IMAP and POP services.

As soon as the customer bound the certificate to POP and IMAP services, it broke IMAP.  From my reading the same symptom is also experienced for POP.

There are many forum threads on the Internet about this issue none with a resolution.  For example:

Symptoms of the Issue

The Test-ImapConnectivity command returned the following error:

RunspaceId                  : ecef0b6b-183e-4211-929d-e046af7c062f
LocalSite                   : Default-First-Site-Name
SecureAccess                : False
VirtualDirectoryName        :
Url                         :
UrlType                     : Unknown
Port                        : 993
ConnectionType              : Ssl
ClientAccessServerShortName : Server
LocalSiteShortName          : Default-First-Site-Name
ClientAccessServer          : Server.domain.local
Scenario                    : Test IMAP4 Connectivity
ScenarioDescription         : Connect to server using IMAP4 protocol, search for the test message, and delete it along
                              with any messages that are older than 24 hours.
PerformanceCounterName      : ImapConnectivity-Latency
Result                      : Failure
Error                       : IMAP Error: aYKG NO LOGIN failed.
UserName                    : administrator
Latency                     : 00:00:00.0368441
EventType                   : Error
LatencyInMillisecondsString :
Identity                    :
IsValid                     : True
ObjectState                 : New

The IMAP4 Protocol Logs on the Exchange Server showed the following HealthMailbox error over and over again:

22T07:30:46.994Z,0000000000000003,2,,,HealthMailbox1f3addd86ba64b7c84868136b32a82f9,1196,78,97,login,HealthMailbox1f3addd86ba64b7c84868136b32a82f9@DOMAIN.COM *****,"R=""z NO [Error=ProxyNotAuthenticated Proxy=EXCHANGESERVER.DOMAIN.COM:1993:SSL] LOGIN failed."";Msg=Proxy:EXCHANGESERVER.DOMAIN.COM:1993:SSL;ErrMsg=ProxyNotAuthenticated"

Microsoft Outlook clients configured using IMAP would prompt for authentication in an infinite loop despite entering the correct details.

Get-ServerHealth would return all IMAP services on the Exchange server in an unhealthy state.

When performing a Telnet to the IMAP Service using Plain Text Login I would get "NO LOGIN failed" also visible in the IMAP protocol log.

Issue Explanation

For this issue to take effect you must have two things consistent in your Exchange environment.
  1. You must be using PlainTextLogin instead of SecureLogin
  2. You must have bound a custom certificate to IMAP.

Also unfortunately if you bind a custom certificate to IMAP, you cannot unbind it according to Microsoft - great feature.

So how do we fix this, what happened?

The X509CertificateName should be the common name of the certificate that's enabled for IMAP.

By default the X509CertificateName is the FQDN of the server, (whatever it is called in your environment.

As soon as we bound the certificate to IMAP, Exchange Automatically updates the X509CertificateName to the common name of the new certificate.  Now if you have SecureLogin enabled, this does not cause an issue.  However if your using PlainTextLogin, as soon as you bind the certificate IMAP breaks even if we are connecting to unsecured IMAP on 143 (secure IMAP is on 993).

If your using PlainTextLogin IMAP or POP must be set to reference the default "self signed certificate" generated by the Exchange installation process which matches the FQDN on the service.

To reset the IMAP service to reference the default self signed certificate, we simply need to change the X509CertificateName back to the FQDN of the server.

Set-ImapSettings -X509CertificateName ServerFQDN

After making this change restart the IMAP4 backend and frontend services.

Test again using an IMAP client or Telnet.  We can see that it now works as it is referencing the self signed issue.

Final Thoughts

In theory because the X509CertificateName matched the common name on the new certificate, and because we weren't even using secure IMAP at all, it should have worked.  It appears to be a bug in the source code around how these services were coded.

I hope this post has been helpful to other people experiencing this same issue.

Saturday, March 24, 2018

SCCM - TS environment is not initialized

I was in a process of upgrading a customer to the latest SCCM 1710 build for rolling out Windows 10 across the companies network.

To upgrade to SCCM 1710 you must first upgrade to SCCM 1702 then do the next upgrade in the SCCM console.

While upgrading a client to SCCM build 1702, we ran into an issue where the following error was generated in the smsts.log file on the SCCM Distirbution Point.  This error was experienced when imaging a client with our existing Windows 7 deployment task sequence via PXE Boot.

"TS environment is not initialized"

On the client being imaged, the following error was experienced:

The Windows Boot Configuration Data (BCD) file from the PXE server does not contain a valid operating system.  Ensure the server has boot images installed for this architecture.

Error Code: 0xc0000098

This issue occured because I installed The Windows Assessment and Deployment Kit (Windows ADK) version 1709 on the server.

SCCM 1702 does not support ADK 1709.

To fix the issue, I simply performed the next step of the upgrade - using the SCCM console to perform an in-place upgrade of SCCM to 1710.

For future reference:

If your running SCCM 1702, make sure you run ADK 1703.

If your running SCCM 1710, use ADK 1709.
Hope this post was helpful.

Friday, March 16, 2018

Remote Desktop Services 2016 Microsoft Office Not Aligning

I came across an issue with Remote Desktop Services 2016 on Server 2016 where Microsoft Office applications did not align properly when deployed via a RemoteApp.

A small bar on the left and top of the applications is present and whilst not a big deal, was annoying for users.  I have shown this in the following screenshot, notice the black bar on the top and left of the window.

This issue was flagged as a bug in Server 2016.  Microsoft released the fix under KB4013429 along with a whole lot of other updates.

The patch can be downloaded from here:

After installing this patch and rebooting the server, the users will not longer experience this issue.

Hope this post has been helpful.