Exchange Server Setup asks for organization name during migration

When installing new Exchange 2019 servers in an existing Exchange 2016 organization, I came across the following error. The Exchange 2019 setup asked for the organization name during the installation of the first Exchange 2019 server. The request for the organization name must not appear when installing into an existing Exchange organization, because the new servers are to be installed into the existing Exchange 2016 organization. The request for the Exchange organization name therefore normally only appears if it is a new Exchange organization, i.e. when installing the first Exchange server in an Active Directory in which there has not yet been an Exchange installation:

I then canceled the setup and looked at the Exchange setup log (C:\ExchangeSetupLogs\ExchangeSetup.log). Here I noticed the following lines:

[01.23.2023 18:44:45.0533] [0] Setup is choosing the domain controller to use
[01.23.2023 18:44:58.0018] [0] Setup is choosing a local domain controller...
[01.23.2023 18:45:00.0080] [0] [ERROR] Setup encountered a problem while validating the state of Active Directory: Active Directory operation failed on . The supplied credential for 'USERNAME' is invalid.  See the Exchange setup log for more information on this error.
[01.23.2023 18:45:00.0080] [0] [ERROR] Active Directory operation failed on . The supplied credential for 'USERNAME' is invalid.
[01.23.2023 18:45:00.0096] [0] [ERROR] The supplied credential is invalid.
[01.23.2023 18:45:00.0096] [0] Setup will use the domain controller ''.
[01.23.2023 18:45:00.0096] [0] Setup will use the global catalog ''.
[01.23.2023 18:45:00.0221] [0] No Exchange configuration container was found for the organization. Message: 'Active Directory operation failed on . The supplied credential for 'USERNAME' is invalid.'.

Based on the messages, I initially suspected that the user I used for the installation did not have sufficient permissions in the Active Directory. I then started the Active Directory users and computer MMC on the Exchange Server to check the permissions (fortunately, I did this on the Exchange Server itself). When checking the group memberships, I then encountered the following error message:

Incidentally, this message does not appear on the domain controller itself with the same user. If I had not started the console on the Exchange server to be installed, I would probably not have noticed the error message. So I just quickly checked the authorizations and then concentrated on the error:

A global catalog cannot be contacted to retrieve the icons for
the member list because access was denied. Some icons may
not be shown.

I then checked the usual suspects: DNS, Secure Channel and Event Log. However, I couldn't find any errors here. At some point I thought of group policies that might be preventing something. I therefore moved the Exchange Server computer account to a new OU and deactivated inheritance on the OU. I then only linked the "Default Domain Policy" GPO to the new OU and also reset all local GPOs on the server to be on the safe side:

secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose
RD /S /Q "%WinDir%\System32\GroupPolicy"
RD /S /Q "%WinDir%\System32\GroupPolicyUsers"

After restarting the server, I was able to list the group members from the Exchange Server again. The error that no global catalog was accessible no longer occurred. I then restarted the Exchange setup as a test and the request for the organization name also disappeared. The Exchange setup log now also shows the correct values:

I then canceled the Exchange setup anyway, as I did not yet know which GPO was causing the problems. I then proceeded according to the process of elimination. I gradually attached the GPOs of the original OU to the test OU and always tried to list the group memberships. After a few attempts, I found the problematic GPO:

In a GPO which is responsible for hardening the operating system, RC4_HMAC_MD5 was switched off as a permitted encryption type for Kerberos and only AES encryption was permitted. In my case, however, this was problematic as the domain and the domain trusts were not (yet) configured for AES. I therefore created a new GPO for the Exchange servers, which allows RC4 again:

The Exchange setup ran smoothly after activating RC4. Solved a problem and gained a new task: Converting the domains and trusts to AES. But that's another topic.