Monday, 25 July 2016

Intune and SCCM behind forward and reverse proxies


Last week I spent many hours trying to troubleshoot Intune with SCCM as a management point. The infrastructure in subject contains NDES server which should request certificates from on premise CA and push them do devices. One of the customer requests was that the SCCM server should connect to manage.microsoft.com only through their forward proxy. The other request was that NDES should be published through their reverse proxy.

Everything went fine initially, the devices enrolled successfully and applications installed correctly. However, we could not get certificates to install. At one point, certificates would get issued and visible in Certificate Authority but never pushed to the device. At other times, we would receive this error in CRP.log on SCCM:

Key usage in CSR: "160" and challenge: "224" do not match for CertRequestId: ModelName=ScopeId_4599798C-283A-4BB1-9860-0968EE55B8A9/ConfigurationPolicy_b97bbe55-4fcb-4f25-8516-208eb5945ee8;Version=1;Hash=1524076804 CertificateRegistrationPoint 7/11/2016 3:24:39 PM 12 (0x000C)

I tracked the issue down to caching reverse and forward proxies. When the request from device reached NDES public endpoint, it would forward the cached request to NDES and not the actual one. Also, regarding forward proxy, SCCM pushes and pulls the data from manage.microsoft.com. It seems that it received incorrect data from forward caching proxy and that is why we got Key usage mismatch although we were positive that Key usages were correctly set in the certificate template and SCEP policy.

Anyway, we have turned of reverse proxy caching for NDES server and forward proxy caching for SCCM Site Server role and everything works perfect now.

Wednesday, 4 November 2015

MessageRateLimit on Exchange 2013 Receive Connector


A couple of days ago a customer contacted me saying that he had the following issue when sending authenticated SMTP e-mail messages from an external host: 

4.4.2 Message submission rate for this client has exceeded the configured limit.

Some of the messages would pass through okay, but the majority of them would receive the error. The first thing he checked was MessageRateLimit property on the Receive Connector on the Exchange 2013 CAS server which was configured like this:

 

 However, he did not check the Receive Connector on the backend Exchange 2013 Mailbox servers.

This is how it was configured:

[PS] C:\Windows\system32>Get-ReceiveConnector -Server EXMBX01 | select identity,*messageratelimit,bindings | ft -AutoSize

Identity                                              MessageRateLimit Bindings
--------                                              ---------------- --------
EXMBX01\Receive Connector - Mailbox Transport Service Unlimited        {[::]:25, 0.0.0.0:25}
EXMBX01\Receive Connector - From CAS Proxy Client     5                {[::]:465, 0.0.0.0:465}

 The MessageRateLimit here is set to 5 which is clearly an issue if the host needs to send more than 5 messages per minute. We configured this to 100 on each of the Exchange 2013 Mailbox servers:

[PS] C:\Windows\system32>Set-ReceiveConnector -Identity "EXMBX01\Receive Connector - From CAS Proxy Client" -MessageRateLimit 100 

[PS] C:\Windows\system32>Get-ReceiveConnector -Server EXMBX01 | select identity,*messageratelimit,bindings | ft -AutoSize

Identity                                              MessageRateLimit Bindings
--------                                              ---------------- --------
EXMBX01\Receive Connector - Mailbox Transport Service Unlimited        {[::]:25, 0.0.0.0:25}
EXMBX01\Receive Connector - From CAS Proxy Client     100              {[::]:465, 0.0.0.0:465}


And the problem went away.

When the mail flows from the host on the Internet it reaches SMTP Receive Connector on CAS 2013 on port 587 which is used only for authenticated SMTP traffic. CAS 2013 role proxies the request to Receive Connector on Exchange 2013 Mailbox server on port 465 to deliver the mail. That is the reason why we actually need to configure MessageRateLimit on the backend Mailbox and not on the frontend CAS server.