Office 365

2 entries have been tagged with Office 365.

Updating Exchange Server Certs Error Free

One of the most dreaded events that Administrators loath is the updating of SSL certificates in their environment. The process of creating the CRL plus requesting and obtaining the certificate typically is THAT bad, but it’s the application and restart of services then validation of the environment that can be a challenge.

Exchange is no exception, however with many moving parts between client access and mail transport, ensuring we hit each of the key components.

We’ve installed the certificate on the server using the DigiCert tool and ran the necessary Powershell command to assign the certificate

[PS] C:\Windows\system32>Get-ExchangeCertificate | fl Thumbprint,CertificateDomains,IsSelfSigned,Services

Thumbprint         : A3F7F37A3BA1ADC1AAD2AD1A4FC7CCDE2018A1E0
CertificateDomains : {,,}
IsSelfSigned       : False
Services           : IMAP, IIS, SMTP

Thumbprint         : 438F27DB3B7BE7C827A3DACD9D26F27EC2FD7852
CertificateDomains : {s,}IsSelfSigned       : True
Services           : POP, SMTP

Thumbprint         : 25D280F5E9D0E5D629717250F73192C7FF88FA49
CertificateDomains : {WMSvc-SHA2-EX1}
IsSelfSigned       : True
Services           : None

Thumbprint         : E0335F09160EA7B611B38549A399F3EF6AC4AAEA
CertificateDomains : {Federation}
IsSelfSigned       : True
Services           : SMTP, Federation

Enable-ExchangeCertificate -Thumbprint A3F7F37A3BA1ADC1AAD2AD1A4FC7CCDE2018A1E0 -Services POP,IMAP,IIS,SMTP

Reference for certificate update

While client access for our mailboxes in the Cloud works just fine, when we go to perform SMTP relay from the on-premises Exchange server out to Office 365 it fails and we see the following errors in the Application log:

Source: MSExchangeTransport
Event ID: 12014

Microsoft Exchange could not find a certificate that contains the domain name <I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US<S>, OU=IT, O=”Company, LLC”, L=Minneapolis, S=MN, C=US in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Frontend EXGSRV01 with a FQDN parameter of I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US<S>, OU=IT, O=”Company, LLC”, L=Minneapolis, S=MN, C=US. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

Source: MSExchangeTransport
Event ID: 12035

Exchange was unable to load certificate I>CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US<S>, OU=IT, O=”Company, LLC”, L=Minneapolis, S=MN, C=US. More information: Is FrontEnd Proxy enabled: false. Original backend Server: Send Connector Name from the original request: Outbound to Office 365.

So while we updated the Exchange services, we missed an important step of updating the mail transport components that handle the TLS connection (since just about every provider forces its usage today – Microsoft being no exception).

The fix is simple: update the primary Receive and Send Connectors with the certificate name from our new cert & restart the Microsoft Exchange Transport service

$cert = Get-ExchangeCertificate -Thumbprint A3F7F37A3BA1ADC1AAD2AD1A4FC7CCDE2018A1E0

$tlscertificatename = “<i>$($cert.Issuer)<s>$($cert.Subject)”

Set-ReceiveConnector “EX1\Default Frontend EX1” -TlsCertificateName $tlscertificatename

Set-SendConnector -Identity “Outbound to Office 365” -TLSCertificateName $tlscertificatename

Restart-Service MSExchangeTransport

In some cases, the binding for https the Default Web Site can cause errors where login failures are seen as well. You will want to ensure that both https references have the public certificate references, then perform an IISRESET.

Exchange Server 2016 Exchange Administrative Center cannot login

Finally, to test that mail flow is working, we want to send a test email message thru Exchange – we can do this thru Powershell to force a message thru the Receive connector, over to the Send connector to Office 365, and then to the user mailbox.

Import-Module servermanager
Add-WindowsFeature telnet-client

telnet EX1 25
mail from:
rcpt to:
subject: this is a test message
sending a test message via telnet

Quickly Change Authentication models in Azure AD / Office 365

In 2017 Microsoft has made some major improvements to their Managed authentication model to make it a viable competitor to the cumbersome Federated model. As a refresher, Federated identity requires Microsoft ADFS infrastructure deployed (along with ADConnect for AD Sync), and to make it highly available entails multiple servers deployed in multiple datacenters/Azure, global load balancing of the internet-facing URL with Azure Traffic Manager – dependencies on your private cloud to authenticate to the public cloud. Managed identity still uses ADConnect for AD Sync but the biggest drawback is that you didn’t get the “seamless” single signon (SSO) experience that ADFS provides, only “same sign on” (SSO) and needing to reenter your credentials.

Microsoft has recently added Seamless Single Signon and Pass-Thru Authentication (as an alternative to password-hash synchronization in high security environments, but out of scope for this article) to ADConnect, in efforts to further eliminate the ADFS dependencies previously mentioned, and with this I’ve been working a large number of projects in planning / executing a move away from ADFS.

What I’ve found is that it’s always been a grey area on how long this process takes, given most of the documentation calls for using the Convert-MSOLDomainToStandard cmdlet and dealing with the password conversion process. If you follow these steps there’s an easier way to do it.

Step 1 – Check Local Active Directory

The first step is ensuring that you have local AD setup and able to support Password Sync. One of the Microsoft Premier Field Engineers (PFE) wrote a great blog on this in 2016:

“First, ensure your Azure AD Connect Sync ID has “Replicate Directory Changes” and “Replicate Directory Changes All” permissions in AD (For Password Sync to function properly). If you did not set this up initially, you will have to do this prior to configuring”

This can be done thru Active Directory Users & Computers


Continue reading “Quickly Change Authentication models in Azure AD / Office 365” »