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.
From a security perspective this is not really a best practice, but sometimes you get into this horrible situation where you cannot logon to a server using RDP, and you don’t have access to the server console… sometimes necessity knows no law…
When you try to logon to a remote server using RPD an authentication error occurs, and you are not able to logon the following error is shown:
An authentication error has occurred.
The function requested is not supported
This could be due to CredSSP encryption oracle remediation
Unfortunately, the link provided in the error message points to a non-existing page on the Microsoft website…
In March 2018 Microsoft released a fix that addresses a CredSSP, “Remote Code Execution” vulnerability (CVE-2018-0886) that could impact RDP connections. If the host you are working on has this fix, and the server you are connecting to does not have this fix (can occur when deploying new VM’s remotely) the error shown above pops-up.
The best solution is to update the host you’re connecting to, but if it’s not possible to get access to the console for whatever reason, you can also lower the security on your own host (ouch!).
To do this, add the following registry entry to your own host:
Autodiscover redirect to autodiscover site (often used by hosting companies)
Autodiscover SRV records in DNS (sometimes used by hosting companies)
Autodiscover redirect to Office 365 (outlook.com)
If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:
Preliminary information and subject to change! Will update when more information becomes available.
When installing MS13-061 on Exchange Server 2013 CU1 or CU2 issues with the Content Indexing (can) occur. Content Indexing for Mailbox Databases are in a failed state and the existing “Microsoft Exchange Search Host Controller” seems to be missing. Instead there’s a new service called “Host Controller Services for Exchange” on the box.
Right now it looks like it doesn’t affect Exchange Server 2007 or Exchange Server 2010.
There’s a workaround to get this fixed:
Open the Registry Editor and navigate to the following path:
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search Foundation for Exchange”
Go to the DataDirectory string and give it the following value: