Questions[exchange-server](server)

I am an admin for a 365 site.

I received an email that was not sent to me nor CCed. It looks like I am in the BCC so we are not sure how the email came to me.

I am wondering if there is a policy somewhere that triggered this. Is there a way I can back-trace the email to see if an event was triggered or a policy was invoked for me to get a BCC of this email?

I tried Mail Trace, Mail Flow and Rules but there is nothing there .

TL;DR; How to discover what is wrong with OCSP response on Windows?

I am trying to install a new certificate in on-premises Exchange Server 2019. But Exchange always reports that the new certificate fails the revocation check and will not use it. The new certificate has a chain of trust from the new cert, through an intermediate CA to my root ca. When I open the new cert in certmgr.msc, I see that that chain, and all certificates are reported as OK in certmgr. I have installed my root CA into the “Trusted Root Certification Authorities” store. I have installed the intermediate CA into the “Intermediate Certification Authorities” store.

The new cert’s Authority Info Access URL specifies my own OCSP responder. I know this is not a connection nor proxy problem, because I watch the OCSP logs real-time, and I know the connection is made, and my OCSP responder sends cert “OK”. I have tested with openssl-ocsp on a linux host, and that validation succeeds, when I use this openssl command:

   openssl ocsp 
      -issuer "$ca_sub_cert_file" 
      -cert "$exchangeCert" 
      -resp_text 
      -CApath "$CA_ROOTS_HASHES_DIR" 
      -url "http://$hostNameFull:$ocsp_port/"

Please note that the above openssl command explicitly refers to the issuer, and the CApath, and that enables trust upon the intermediate CA. On Windows, I expected that installing the root-ca and the intermediate CA would similarly enable trust for the OCSP response. But I do not know how to test this.

It should not be necessary, but I also “installed” a certificate for the ocsp-responder. I allowed the wizard to choose the store automatically, and I can not find where it was put. It does not appear when I search for it in certmgr.msc. I have not installed it manually, because I do not know which store I should use.

I suspect that the response from my openssl OCSP responder is wrong for Exchange Server 2019. My theories are:

• A trust chain cannot be built from the new certificate to my root CA
• The chain is built, but one of the certificates for ocsp-responder, the intermediate-ca, or root-ca is not trusted. Even though intermediate-ca, and root-ca are installed.
• The openSSL response is incompatible with Windows and or Exchange Server 2019

How can I test the above theories? I searched the windows event logs but they do not contain any mention of OCSP or revocation.

I am planing a migration from Exchange Server 2010 to Exchange Server 2019. My main problem are 300+ Windows 7 client machines running MS Office 2013. I am aware of the TLS 1.2 issue and I plan to solve it with updates

https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392

There is another possible issue regarding Office 2013 compatibility with Exchange 2019. Outlook 2013 is listed as supported as long as it has the latest updates

https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019#clients

Does anyone have experience regarding this issue? What updates for Office 2013 are actually required for Outlook to successfully connect to Exchange 2019?

I want to get list of all inactive mailboxes with their primary SMTP address and last logon information.

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName, LastLoggedOnUserAccount, LastLogonTime

This command returns all inactive mailboxes with their display name but problem is that I want to get this list with PrimarySMTPAddress of mailbox because there is a possibility that multiple accounts can have same display name. Is there a way to get it with PrimarySMTPAddress?

I have a Microsoft Exchange server for a small business and we just upgraded to 2010. It's now prompting people on Android with:

Activate device administrator?

 - Erase all data: Perform a factory reset, deleting all of your data without any confirmation 
 - Limit Password: Restrict the types of passwords you are allowed to use. 
 - Watch login attempts: Monitor failed attempts to login to the device, to perform some action 
 - Force Lock: Control when device locks, requiring you re-enter its password.

We don't want this. Is there a way in Exchange to turn this off?