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:
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2
I strongly recommend raising security again when you have updated the remote server.
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:
Continue reading Improve autodiscover performance
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
Note. If your Exchange binaries are in a different directory use change the path accordingly.
In the registry navigate to the following location:
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.
The display name will only be changed after a reboot of the server, but the services can be started at this point.