Category Archives: Exchange

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

 

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

 

Autodiscover in an Exchange interorg migration with Quest QMM

Outlook clients get their configuration information using the Autodiscover protocol from the Exchange server where their mailbox resides and the underlying Active Directory. This works fine, until you are in an interorg migration scenario using the Quest Migration Manager (QMM) for Exchange.

When using Microsoft tools (ADMT, Prepare-MoveRequest.ps1 and New-MoveRequest) the source Mailbox in Exchange is converted to a Mail-Enabled user at the moment of migration finalization. At the same moment the Mail-Enabled User property targetAddress is stamped with the SMTP address of the Mailbox in the new forest. SMTP works fine now, and also Autodiscover will follow the SMTP domain that’s in the targetAddress property. This is true for an interorg migration on-premises, but it is also true when moving Mailboxes from Exchange on-premises to Exchange Online in a hybrid scenario.

When using Quest tooling things are a bit different. The source Mailbox is not converted to a Mail-Enabled User, but it continues to exist at a regular Mailbox. The Outlook profile on the desktop is converted using the CPUU tool using local Autodiscover.xml files so that the Outlook client no longer connects to the old Mailbox but to the new Mailbox.

This works fine for the existing client, but when a user gets a new laptop, or has to configure the Outlook profile again, Outlook will use the Autodiscover process and thus connect to the old Mailbox. Since this isn’t converted to a Mail-Enabled User, Outlook will find the (old) Mailbox, it will stop searching (and thus will not follow the targetAddress property) and return the configuration information for the old Mailbox.

To fix this, we have to export the Autodiscover information from the new Exchange organization to the old organization. I found an old blogpost written by Andread Kapteina (Senior Consultant at Microsoft) in the Google cache (since his blogs no longer exist at the Microsoft Technet Site) about this scenario in an interorg Exchange 2007 to Exchange 2010 migration, but I found that it is also valid in an interorg Exchange 2013 to Exchange 2016 migration. And it should be valid in every interorg Exchange migration from Exchange 2007 and higher.

Export-AutodiscoverConfig

To export the Autodiscover configuration from the new Exchange 2016 to the old Exchange 2013 organization, execute the following commands on the Exchange 2016 server:

$OldCred = Get-Credential OldForest\administrator
Export-AutodiscoverConfig -DomainController <NewForestFQDN> -TargetForestDomainController <OldForestFQDN> -TargetForestCredential $OldCred -MultipleExchangeDeployments $true

The -MultiplExchangeDeployments options should be set to $true since both forests contain an Exchange organization.

The Exchange Management Shell does not report anything back, so no need to show it here 😊

When we look in the AD Configuration container we can now see two SCP records:

  • One record can be found under CN=Services, CN=Microsoft Exchange, CN=<Organization>, CN=Administrative Groups, CN=Exchange Adminstrative Groups (FYDIBOHF23SPDLT), CN=Servers, CN=<ServerName>, CN=Protocols, CN=Autodiscover, CN=<ServerName>. This will contain the regular SCP information that Outlook needs to connect to the existing Exchange organization to retrieve its information.
  • The second record can be found under CN=Services, CN=Microsoft Exchange Autodiscover, CN=<FQDN of new Forest>. This will contain information regarding the target (i.e. new Exchange 2016) forest that the Outlook needs for migrated Mailboxes.
    This second record can be seen in the following screenshot:

CN=Microsoft Exchange Autodiscover

The keywords property of the SCP record contains the Accepted Domains of the new Exchange 2016 organization, like Exchangefun.nl, Corporate.Exchangefun.nl and target.qmm (the Quest target domain). This means when a new Accepted Domain is added to Exchange 2016, the Export-AutodiscoverConfig command needs to be run again.

The serviceBindingInformation property contain an LDAP link to the Exchange 2016 forest where Outlook clients can find information from the migrated Mailboxes.

Granting permissions

To avoid issues with Outlook clients of not migrated Mailboxes (that need to retrieve information from the old Exchange 2013 organization) we have to hide the exported SCP for these users. At the same time, we have to hide the original SCP record in Exchange 2013 for Mailboxes that have been migrated to Exchange 2016 (and where Outlook should NEVER receive old Exchange 2013 information).

To achieve this, create a Universal Security Group with a name like “Migrated_Users”, remove the Authenticated Users group from the exported SCP and grant the Migrated_Users Security Group Read permissions on this object as shown in the following screen shot:

Remove Authenticated Users

At the same time we have to grant an explicit deny Read permission to the Migrated_Users Security Group on the original SCP record as shown in the following screenshot:

Explicit Deny

Summary

Now when a Mailbox is migrated using QMM and the CPUU tool, add the user to the Migrated_Users Security Group. At this moment its Outlook client will no longer find the original (Exchange 2013) SCP record but the exported SCP record. Outlook will then connect to the target Active Directory forest with Exchange 2016 and retrieve the correct information.

Note. It took us quite some time when testing this scenario with different versions of Outlook (2010, 2013 and 2016) but the scenario explained here turned out to be working fine with these versions. But please test in your own test environment with various clients as well.

More information