A couple of weeks back, a certificate was approaching it's expiration date on an IIS server and the update - although pretty straight forward, caused a major issue for the service running on that server. I had the new certificate in PFX format, I've installed it on the computer certificate store and it was available in the IIS Manager console. All the certificates for the Root and Intermediate authorities were property installed and the clients had access to the CRL urls. However, when I switched the certificate, the clients were not able to communicate property with the website. After going through the logs on the clients and the application, I discovered that the clients were using client certificates in order to authenticate and the validation process was failing for those certificates since my server could not check their revocation. I opened up a command prompt to get more information on the bindings on the website since there are settings that are not available when
Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint Subject ---------- ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB261162F9C8CBE12E0B75D6F06ABB0 CN=Microsoft Exchange Server Auth Certificate 2690324B827A9F2B75D59104F81CAAA57CDD627B CN=WMSvc-Exchange2013A [PS]
The Set-Mailbox cmdlet has two parameters to configure forwarding for a mailbox: ForwardingAddress and ForwardingSmtpAddress. Those two parameters serve the same puspose but in two different ways. There is also a third parameter called DeliverToMailboxAndForward that when set will leave a copy of the message on the mailbox. The "ForwardingAddress" accepts RecipientIdParameter input which means that you have to use the identity of an existing object on your organization such as another mailbox or a mail contact. The "ForwardingSmtpAddress" accepts input in a proxy address format such as plain old email addresses. Although this is pretty straight forward, there's a catch you need to be aware of. This will only work if the remote domain of the recipient is configured to allow message forwarding. Let me elaborate. There's a thing on Exchange, called Remote Domains . Those are used in order to define settings for the communication between your Exchange ser