Windows Server 2022 will not join windows 2019 DC domain

[AdminLovesLEarning]

Chip Chip Chin Chin.

Recently upgraded my physical Hyper-V host to server 2022 so i can use FoD tools and Hyper-V manager from server core with the GUO option provided by FOD something that 2019 didn't offer which I've bee cursing for years about since 2012 R2 the ability to turn off GUI and have a core version running or simulated core version of windows server however 2016, 2019 removed the GUI Hyper-V GUI from core installs so I finically have my dream. hip hip chin chin so I though however;

Note: everything was working on server 2019 servers both VMs and Physical without issues this is only a 2022 to 2019 issue since the upgrade.

Issue: Every attempt to join the new 2022 psychical server to the the VM DC fails at all attempts.

infrastructure: Physical server running server core 2022 DC and all VMs are hosted on a NAS (qnap tvs-1688x) via connected via ISCSI (testing will use DAS later but Techies will be Techies). The AADC is DNS and DHCP is which relayed via UDM SE with DHCP set to Server Relay and all devices are getting and IP address including the new server 2022 server so the ADDC VM is operational and contactable. the VM is a AD DC running server core 2019 DC to which I have other servers GUI or Core connected which are 2019, W11 or W10 all good fun.

Plan: I was planning to create a new 2022 DC and transfer the FMSO roles to it afterwards once everyone was singing from the same domain songsheet however alias here i am.

I have an incline it may be the forest function level however when i started test DCDIAG i encountered strange issues or reports should i say.

nltest /dsgetdc: (used server name without domain, no FQDN) /force
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

PS C:\> nltest /dsgetdc: (used domain name) /force
DC: \\servername.doaminname appear
Address: \\IP Address is displayed
Dom Guid: 308b9212-02fe-4e4c-b588-db243baffd47
Dom Name: domain name is display
Forest Name: domain name is display
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 KEYLIST
The command completed successfully

PS C:\> nltest /dsgetdc:Server Name /force
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

As you can see from the result the domain name resolves with issues however when i use just the server name it fails. I could be using the command wrong but the fact it reports no such domain when i only use the domain name and not FQDN could be the issue but the domain query works and reports ADDC Server, IP and FQN, etc so its presents.

I'm at a lose as its only server 2022 which has this issue.

here is a screenshot of the message and as you can see it just say failed to join, no error nothing just failed. its a strange one indeed

All help apricated in advance

 

[ChatGPT]

Hi Chip Chip Chin Chin,
Your issue is definitely a head-scratcher—especially when everything worked flawlessly on 2019 until the 2022 upgrade. The key clue here is that using the fully qualified domain name (FQDN) with nltest returns valid information, while using just the server name results in the "ERROR_NO_SUCH_DOMAIN (1355)" error.
This behavior suggests that the new Server 2022 machine isn’t automatically appending your DNS suffix when you simply specify the server name. Here are a few troubleshooting steps you might consider:

1. Verify DNS Settings:
   • Ensure that the new server’s primary DNS is set to the IP address of your 2019 domain controller.
   • Check that the DNS suffix is correctly configured on the NIC (either via DHCP suffix options or manually under the Advanced TCP/IP settings). A misconfiguration here might prevent the machine from resolving the domain correctly unless the FQDN is explicitly provided.
2. Time Synchronization:
   • Confirm that the new server’s clock is synchronized with your DC. Even small time discrepancies can lead to domain join failures.
3. Use FQDN for Domain Join:
   • Since your diagnostic with nltest shows that the FQDN resolves properly, try joining the domain using the FQDN rather than the short name. This can sometimes bypass issues caused by missing DNS suffixes.
4. Firewall/Network Checks:
   • Temporarily disable the Windows firewall (or ensure the necessary AD ports are open) on the new server to rule out any network-level blocks.
   • Run basic connectivity tests (ping, nslookup) to confirm that the server communicates properly with the DC.
5. Additional Diagnostics:
   • Use the “netdom join” command with the proper parameters from an elevated prompt—it may provide more verbose error information.
   • Check the event logs on both the 2022 and 2019 servers for any additional domain join related errors.

It sounds like once you get past this DNS/suffix hurdle, your plan to create a new 2022 DC and transfer the FSMO roles should go smoothly. Let us know if you need further assistance or if additional logs or error messages come to light—sometimes the devil’s in the details!
Cheers, and happy troubleshooting!
—ChatGPT

 

[AdminLovesLEarning]

Verify DNS Settings:
• Ensure that the new server’s primary DNS is set to the IP address of your 2019 domain controller.
All done and working I can confirm. the primary DNS is the ADDC only with no secondary sent then I use conditional forwarding on the DC DNS to resolve

• Check that the DNS suffix is correctly configured on the NIC (either via DHCP suffix options or manually under the Advanced TCP/IP settings). A misconfiguration here might prevent the machine from resolving the domain correctly unless the FQDN is explicitly provided.
Time Synchronization:
Th NIC is DHCP from ADDC Server and can ping the ADDC. not using static just test DHCP from ADDC to Server. all is good

IPv6: turned off on both servers

• Confirm that the new server’s clock is synchronized with your DC. Even small time discrepancies can lead to domain join failures.
Use FQDN for Domain Join: OK will do. I use the Guest Services on all which sync time with Server and VMS. I Can confirm the time is sync on both to be the same

• Since your diagnostic with nltest shows that the FQDN resolves properly, try joining the domain using the FQDN rather than the short name. This can sometimes bypass issues caused by missing DNS suffixes.
Firewall disable on both AD and Physical server, temp.
Set-NetFirewallProfile -Profile Domain, Public, Private -Enabled False

Firewall/Network Checks:
• Temporarily disable the Windows firewall (or ensure the necessary AD ports are open) on the new server to rule out any network-level blocks.
All done same results

• Run basic connectivity tests (ping, nslookup) to confirm that the server communicates properly with the DC.
All done, first point of call

Additional Diagnostics:
• Use the “netdom join” command with the proper parameters from an elevated prompt—it may provide more verbose error information.

still failed

• Check the event logs on both the 2022 and 2019 servers for any additional domain join related errors.
will do, looking how to check event logs on server core

 

[ChatGPT]

Hi Chip Chip Chin Chin,
Thanks for running through those steps and sharing additional details along with your screenshots (66846 and 66847). It sounds like you've been meticulous with your DNS setup, time sync, firewall configuration, and connectivity tests—all of which are solid.
Since the standard checks are all in order and you’re still facing issues with the domain join (even when using the FQDN), here are a few additional troubleshooting ideas:

1. Event Logs Insight:
   With server core, you can check the event logs to get more context. Use PowerShell commands such as:
   • Get-WinEvent -LogName System | Format-List -Property *
   • or using wevtutil: wevtutil qe System /c:5 /f:text
   Inspect both the System and the Directory Service logs for any error or warning events that occur around the time you attempt the join. Often, these logs reveal more specific error codes or messages that aren’t immediately visible in the netdom output. Once you see any particular error codes, that can help narrow down the root cause.
2. Local Computer Account Check:
   Ensure that there isn’t already a stale computer account in AD for your new 2022 server. Sometimes a prior attempt can leave behind an account that needs to be cleaned up in Active Directory Users and Computers. Deleting the existing account (if found) and then retrying the join can sometimes clear the issue.
3. DNS Suffix Verification:
   Although you’ve stated that DHCP is handling it fine, it might be worth double-checking the output of ipconfig /all on the 2022 server to confirm that the "Connection-specific DNS Suffix" is correctly set to your domain name. Even a minor misconfiguration here (like a typographical error) could cause issues when the system attempts a standard join operation.
4. Netdom and Verbose Output:
   When using the netdom join command, consider adding the /verbose switch, if available, to see if it outputs more detailed information. Although the current screenshot (66847) didn’t reveal extra error details, sometimes a verbose run can help pinpoint an issue (such as authentication failures or mismatch in expected names).
5. Reset Secure Channel:
   If for some reason the underlying secure channel is compromised or misconfigured, you could try resetting it using:
   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
   Though this is typically used post-join, it might yield additional useful errors when things fail.
6. Alternative Join Method:
   As a workaround, you might try joining the domain from a Management Workstation (using Remote Server Administration Tools) to see if joining the 2022 server via that method makes any difference. This can help isolate if the issue is specific to server core’s configuration.

Since you’ve already verified the fundamental network settings, your next clue should be in the event logs. If you can post any specific error codes or events you discover, we can delve deeper into what they mean.
Keep us updated with what you find in the event logs, and we’ll work through the next steps together.
Cheers, and happy troubleshooting!
—ChatGPT

 

[AdminLovesLEarning]

Hi Chip Chip Chin Chin,
Thanks for running through those steps and sharing additional details along with your screenshots (66846 and 66847). It sounds like you've been meticulous with your DNS setup, time sync, firewall configuration, and connectivity tests—all of which are solid.
Since the standard checks are all in order and you’re still facing issues with the domain join (even when using the FQDN), here are a few additional troubleshooting ideas:

1. Event Logs Insight:
   With server core, you can check the event logs to get more context. Use PowerShell commands such as:
   • Get-WinEvent -LogName System | Format-List -Property *
   • or using wevtutil: wevtutil qe System /c:5 /f:text
   Inspect both the System and the Directory Service logs for any error or warning events that occur around the time you attempt the join. Often, these logs reveal more specific error codes or messages that aren’t immediately visible in the netdom output. Once you see any particular error codes, that can help narrow down the root cause.
2. Local Computer Account Check:
   Ensure that there isn’t already a stale computer account in AD for your new 2022 server. Sometimes a prior attempt can leave behind an account that needs to be cleaned up in Active Directory Users and Computers. Deleting the existing account (if found) and then retrying the join can sometimes clear the issue.
3. DNS Suffix Verification:
   Although you’ve stated that DHCP is handling it fine, it might be worth double-checking the output of ipconfig /all on the 2022 server to confirm that the "Connection-specific DNS Suffix" is correctly set to your domain name. Even a minor misconfiguration here (like a typographical error) could cause issues when the system attempts a standard join operation.
4. Netdom and Verbose Output:
   When using the netdom join command, consider adding the /verbose switch, if available, to see if it outputs more detailed information. Although the current screenshot (66847) didn’t reveal extra error details, sometimes a verbose run can help pinpoint an issue (such as authentication failures or mismatch in expected names).
5. Reset Secure Channel:
   If for some reason the underlying secure channel is compromised or misconfigured, you could try resetting it using:
   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
   Though this is typically used post-join, it might yield additional useful errors when things fail.
6. Alternative Join Method:
   As a workaround, you might try joining the domain from a Management Workstation (using Remote Server Administration Tools) to see if joining the 2022 server via that method makes any difference. This can help isolate if the issue is specific to server core’s configuration.

Since you’ve already verified the fundamental network settings, your next clue should be in the event logs. If you can post any specific error codes or events you discover, we can delve deeper into what they mean.
Keep us updated with what you find in the event logs, and we’ll work through the next steps together.
Cheers, and happy troubleshooting!
—ChatGPT

resolved finally. undertook some house keeping and removed various servers from DHCP and DNS, checked AD and removed non used DC. restarted and updated as done before however this time it all resolved now. thankfully, now to create a new DC VM as 2022 and transfer FSMO roles

 

[ChatGPT]

Great news, Chip Chip Chin Chin! It sounds like the good old-fashioned digital housekeeping—cleaning up those DHCP, DNS, and AD leftovers—did the trick, and your Server 2022 is now happily in the domain. Kudos for staying persistent through the troubleshooting process!
As you move on to creating your new DC VM and transferring FSMO roles, feel free to drop any questions if you need pointers or run into any snags during the transition. Congratulations on resolving the issue, and happy upgrading!
Cheers,
—ChatGPT