So, today I found out that outbound mail from my jaapwesselius.com did not have a DKIM signature (after mail was blocked by prodigy.net). I have my jaapwesselius.com running on WordPress.com. To do this, WordPress requires to have DNS hosted with them. No problem, but adding a DKIM record in WordPress DNS is not possible, it fails with a TXT records may not exceed 255 characters error message as shown below:
The solution is relatively simple. You can add a CNAME record for the original DKIM record. For example, have safemail._domainkey.jaapwesselius.com point to something like safemailhop.exchangelabs.nl (I own that domain too, and DNS is hosted at my provider Argeweb).
While installing the Exchange 2019 Management Tools (only the Management Tools) on a server, I ran into the error message “A reboot from a previous installation is pending. Please restart the system and then rerun Setup”
Normally a reboot fixes this problem, but unfortunately this time it did not fix it.
The option to reboot is also logged in the registry of the server. There is a key called PendingFileRenameOperations located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager which in this case has a certain data that was not cleaned up previously:
When you check the data you can even see which process did not clean up. Remove the data from the key (or remove the entire key) and continue with the installation.
When running a hybrid deployment or when using Exchange Online Archiving in combination with Exchange on-premises, make sure you run the latest CU or one version older (i.e. Exchange 2013 CU23, Exchange 2016 CU18/CU19 or Exchange 2019 CU7/CU8)
No schema changes in these CUs but there are changes to AD, so make sure you run the Setup.exe /PrepareAD command
And as always, test thoroughly in your lab environment, and when deploying make sure your servers are in maintenance mode (especially the DAG).
On December 8, 2020 Microsoft released a number of security updates for Exchange server. Despite the fact that Exchange 2010 is out of support at all, an important security update for Exchange 2010 was released as well.
Last September Microsoft released their quarterly Cumulative Updates for Exchange, Exchange 2016 CU18 and Exchange 2019 CU7. This was quickly followed by a security update, KB4581424 that addresses the CVE-2020-16969 Microsoft Exchange Information Disclosure vulnerability.
Unfortunately, the Exchange 2016 CU18 and Exchange 2019 CU7 contain a nasty bug. If you use OWA, open a shared mailbox and try to access an attachment, OWA redirects to Office 365 instead of the on-premises Exchange 2016/2019 server to download it. This happens in an hybrid environment, but also in a pure on-premises Exchange deployment without any Office 365 connection.
Microsoft is aware of this issue and it will be fixed in the next Cumulative Updates for Exchange 2016 and Exchange 2019. Looking at the quarterly cadence this should be by the end of this year.
If you have a Microsoft Premier support contract and this is an issue that impacts your business you can open a support ticket and request a fix for this. This service is available for Premier support customers only.
This fix is a replacement for the KB4581424 security update, as such it contains all the fixes in KB4581424, plus the OWA Attachment hotfix. If you are a Premier support customer and do have this fix available, make sure that you uninstall the KB4581424 first before installing this update. One workaround that I’ve seen in a newsgroup is not to open the Shared Mailbox as “Open another mailbox” but as “Add shared folder”. This should work also, but I have not tested it. I do have a customer with a Premier support contract, I can confirm the problem is fixed in the interim update.