Tag Archives: Registry

Check Server Core for Exchange 2019 Security Updates

When you want to check which updates are installed on an Exchange server you can navigate to Control Panel | Programs | View Installed Updates and you will see a list of installed updates, including the Exchange Security Updates.

When running Exchange 2019 on Windows 2019 Server Core there is no Control Panel and you can view the registry to check which updates are installed. Use the following command to view all installed Updates:

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*| select-object displayname

Or more specifically for Exchange Server:

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*| ?{$_.DisplayName -like "*Exchange Server*"} | Select DisplayName

This will show all software and updates for Exchange as shown in the following screenshot:

A reboot from a previous installation is pending. Please restart the system and then rerun Setup

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.

This could be due to CredSSP encryption oracle remediation

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:

cred-ssp-issue

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:

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

cred-ssp

I strongly recommend raising security again when you have updated the remote server.

Improve autodiscover performance

Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.

The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:

  • Service Connection Point (SCP) in Active Directory. This is used by domain clients.
  • Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
  • Autodiscover.contoso.com (standard autodiscover mechanism)
  • 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:

image

Continue reading Improve autodiscover performance

Installing MS13-061 breaks CI on Exchange Server 2013

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:

C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data

image

Note. If your Exchange binaries are in a different directory use change the path accordingly.

In the registry navigate to the following location:

“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HostControllerService”

Change the value of “DisplayName” to “Microsoft Exchange Search Host Controller”

Add a new Multi-String Value named “DependOnService” and specify “http” in Value data.

image

The display name will only be changed after a reboot of the server, but the services can be started at this point.