Exchange 2019 on Windows Server Core disk management

When installing an Exchange 2019 Edge Transport server on Windows 2019 Server core I realized there’s no disk management MMC snap-in, so all disk configuration needs to be done using PowerShell.

For this blogpost I added a 20GB disk to my Windows 2019 Server Core server which I want to use as a D:\ drive for my SMTP queue.

You can use the Get-Disk command to retrieve the server’s disk configuration, and you can pipe this disk object into the Initialize-Disk command to bring it online and assign a new partition:

Get-Disk –Number 1 | Initialize-Disk –PartitionStyle GPT New-Partition –DiskNumber 1 –UseMaximumSize

Initialize-Disk

By default, Windows installs on drive C:\ and the DVD is mounted as drive D:\. You can use the Get-WmiObject and the Set-WmiInstance commands to assign it a different drive letter, for example drive Z:\

Get-WmiObject -Class Win32_volume -Filter ‘DriveType=5′ | Select -First 1 | Set-WmiInstance -Arguments @{DriveLetter=’Z:’}

The next step is to assign drive letter D:\ to the newly added disk:

Add-PartitionAccessPath -DiskNumber 1 -PartitionNumber 2 –AccessPath “D:\”

And finally format it using NTFS file system and a block size of 64KB:

Get-Partition –Disknumber 1 –PartitionNumber 2 | Format-Volume –FileSystem NTFS –NewFileSystemLabel “Queue” -AllocationUnitSize 65536 –Confirm:$false

format-disk

Now you can continue with the standard installation procedure for an Exchange 2019 Edge Transport server (which does not differ from an Exchange 2013 or Exchange 2016 Edge Transport server)

DNS Suffix Windows 2019 Server Core

While preparing a Windows 2019 Core server for an Exchange 2019 Edge Transport server I had to set the FQDN of the server. The server name itself is not difficult, you can change this using the SCONFIG tool, but you cannot change the DNS suffix using SCONFIG.

For changing the DNS suffix on a Windows 2019 Core you can use the NETDOM, the REG.EXE or PowerShell:

netdom computername %computername% /makeprimary:%computername%.exchangelabs.nl

or when using the computer name itself:

netdomain computername AMS-EDGE01 /makeprimary:AMS-EDGE01.exchangelabs.nl

To add the registry key needed for the DNS suffix (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain\NV Domain) you can also use the REG.EXE tool:
reg.exe add HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters /v “NV Domain” /t REG_SZ /d “exchangelabs.nl” /f

Or you can use PowerShell:

New-ItemProperty -Path “HKLM:\ SYSTEM\CurrentControlSet\services\Tcpip\Parameters\” -Name “NV Domain” -PropertyType REG_SZ -Value “exchangelabs.nl”

New-ItemProperty DNS Suffix

Reboot the server, run IPCONFIG /ALL and you’ll see the DNS suffix. The server can now be used for installing Exchange 2019 Edge Transport server.
ipconfig all

 

Moving from Exchange 2010 to Office 365 Part III

Exchange 2010 hybrid and Edge Transport Server

In two previous blog posts I explained how to setup an Exchange 2010 hybrid environment. In these blog posts I used the Exchange 2010 (multi-role) server for the hybrid configuration, so both the Exchange Web Services (used for free/busy, Mailbox Replication Service, OOF, mail tips) and the SMTP connection between Exchange Online and Exchange 2010.

Now that Exchange 2010 end of support is getting closer (less than a year!) I get more questions regarding the move from Exchange 2010 to Exchange Online. And several questions include the use of an Exchange 2010 Edge Transport server in front of the Exchange 2010 multi-role server.

This configuration will look something like this:

exchange 2010 hybrid edge transport

Inbound mail from Internet is getting through Exchange Online Protection and when the mailbox is still on Exchange 2010 it is routed via the Edge Transport Server to the internal Exchange organization. Outbound mail is leaving the organization via the Edge Transport server or via Exchange Online Protection, depending of the location of the mailbox.

The challenge when configuring this in Exchange 2010 is shown in the following screenshot:

missing edge transport server

Compared to running the HCW on Exchange 2013 or Exchange 2016 there’s no option to configure the Edge Transport server for secure mail transport in Exchange 2010!!
The only option right now is to run the Hybrid Configuration Wizard, configure it using the Client Access and Mailbox servers option, but use the data for the Edge Transport where needed.

So, run the Hybrid Configuration Wizard, and when you need to enter the public IP address of the transport servers, enter the Public IP address of the Edge Transport server and not the public IP address of the load balancer VIP pointing to the Exchange 2010 internal servers). In my environment, the webmail.inframan.nl points to 176.62.196.253 and the Edge Transport Server smtphost.inframan.nl points to 176.62.196.245. This is the IP address I am going to use as shown in the following screenshot:

hcw public ip address

The next step is to select the certificate that’s used on the Edge Transport Server. By default, the HCW will only look at the internal Exchange 2010 server, so it won’t find any certificate installed on the Edge Transport server. To overcome this, I have imported the certificate of the Edge Transport Server in the certificate store of the internal Exchange 2010 server used by the HCW. In the HWC, click on the drop down box and select the certificate of the Edge Transport server, in my environment the smtphost.inframan.nl certificate:

hcw loading certificates

The last step is where the FQDN of the organization needs to be entered. I have a lot of discussion here because most admins want to enter something like ‘hybrid.domain.com’, but the FQDN of the transport server needs to be entered here, so in my environment this is the FQDN of the Edge Transport Server, i.e. smtphost.inframan.nl. This FQDN is used (together with the certificate information) to create a Send Connector from Exchange Online to the Edge Transport server.

hcw organization fqdn

Finish the Hybrid Configuration Wizard. It will be configured in Exchange 2010 and in Exchange Online and after a short time you can close the HCW:

hcw configure organization relationship

Now, when looking at the Exchange Management Console you can see the Send Connector from Exchange 2010 to Exchange Online. It is configured with the FQDN smtphost.inframan.nl as expected, but the source server of the Send Connector is still the internal Hub Transport server as shown in the following screen shot:

outbound to office 365 connector

Remove the Hub Transport server entry and add the Edge Transport server instead. If you have an Edge Synchronization in place you will see it immediately when you click the Add button.

In Exchange Online, the Receive Connector that’s created will check for any certificate with a wildcard like name, so the smtphost.inframan.nl certificate will automatically be accepted. The Send Connector is also created correctly. The FQDN of the Edge Transport server is used as the server to route message to, and the CN of the certificate that was selected in the HCW is also configured as shown in the following screenshot:

office 365 send connector certificate

We’re almost there. The only thing that needs to be done is to configure the Receive Connector on the Edge Transport Server for TLS from Exchange Online. You should have already configured the Edge Transport Server with the correct 3rd party certificate and when setting up an inbound connection it should use the 3rd party certificate. You can test this using the https://checktls.com tool online.

On the Edge Transport server, execute the following command in the Exchange Management Shell:

Get-ReceiveConnector "smtphost\Default internal receive connector SMTPHOST" | Set-ReceiveConnector -Fqdn smtphost.inframan.nl -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol

This will make sure the cross-premises email will be treated as internal email (SCL=-1). If you omit this step, there’s always the risk the email will be treated as external (I’ve seen SCL=5 in my environment) and will end up in the user’s Junk Email Folder.

Summary

When configuring an Exchange 2010 hybrid configuration it is not possible to configure an Edge Transport Server in the Hybrid Configuration Wizard. It is possible to configure this in the HCW for Exchange 2013 and Exchange 2016, but for Exchange 2010 this needs some manual changes.

In this blogpost I showed you the steps needed to configure an Edge Transport Server for secure messaging between Exchange Online and Exchange 2010. When configured this way cross-premises email will be seen as internal email and thus treated accordingly.

 

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.

The version of the Client Access server selected is not supported

When running the Hybrid Configuration Wizard in an Exchange 2010 environment (I reproduced this with Exchange 2010, but didn’t try this with Exchange 2013 or Exchange 2016) the following error message is generated:

unsupported version

The version of the Client Access server selected, <ServerName>, is not supported. Please go back and select a server that is supported or upgrade the server to a supported version. If Exchange Server 2010, please install the wizard on the same machine.

Note. The HCW is not run on the Exchange 2010 since it requires .NET Framework 4.6.2 and this version of .NET Framework is not supported on Exchange 2010. Even worse, I’ve seen issues with Exchange 2010 after installing .NET Framework 4.6.2 so it’s a bad idea after all.

Running Exchange 2010 on a server with .NET Framework 4.5.x installed is fully supported, but the HCW won’t install on such an Exchange 2010 server since HCW depends on .NET Framework 4.6.2 and the following error message is generated:

unable to install or run this application

So, we are in a deadlock situation. HCW requires .NET Framework 4.6.2 which is not supported on the Exchange server, and when running the HCW on a non-Exchange 2010 server with the correct version of .NET Framework it fails with an error message.

We have been working with Microsoft CSS (product support) on this case. While it should be fixed in the HCW in the first place, under supervision of CSS the following workaround is available.

If you have HCW open and face this error, press F12 and a few other options appear as can be seen in the following screenshot:

HCW Error

If you click Open Logging Folder you get to the folder where the HCW Logs are stored. If you open the correct logfile and search for *ERROR* you can find something similar to:

server error

Obviously the HCW does an incorrect version check (at least when not running on the Exchange 2010 server itself) so it stops. Version checking is something that was built recently into the HCW so Microsoft can check for N-2 version of the implemented Exchange version.

Back to the error message, if you click Open Process Folder a new HCW command prompt is opened on the correct location:

HCW Prompt

Now when you start the Hybrid Configuration Wizard from the Command Prompt you can use the /dv switch (Microsoft.Online.CSE.Hybrid.App.exe /dv) and now the HCW will not do a version check and continue running and finish successfully.

Important note. This was done under the supervision of Microsoft CSS and should not be done by customers directly. If you are running into this issue, please contact Microsoft support to get the right support. Before you know things break beyond repair (and beyond support).

More information

Updated: December 6, 2018

 

Microsoft UC Specialist