I'm in the process of retiring an old SBS 2011 server that currently hosts all fsmo roles. I do have an additional DC/GC running Server 2016 that will become my only DC until I add an additional DC/GC running Server 2019 or newer. Prior to performing the tasks to decommissioning the legacy SBS 2011 server, I've run several dcdiag tests to make sure AD, DNS and replication are all fine. The SBS 2011 server is sending DNS errors when I run DCDIAG /test:DNS /DNSALL /e /v from an elevated cmd prompt. The other server completes the dcdiag command without errors, however. Both servers are only using each other for DNS on their NICs. Primary points to the other DC and secondary points to itself. No public DNS servers are listed in the NICs. I am using forwarders on each server in DNS, however. Network time is perfect and both servers have internal firewall disabled for Windows. Replication between both servers is quick and good with AD accounts in both directions. For the DNS errors with Basc, I'm getting WMI connectivity issues that I don't quite understand. I've confirmed that both servers have host A records that are valid in each DNS for both servers. The server names are SBS (sbs 2011) and DC1 (Windows 2016 Server). Any input or suggestions would be appreciated.
TEST: Basic (Basc) Error: No WMI connectivity [Error details: 0x80070005 (Type: HRESULT - Facility: Win32, Description: Access is denied.) - Connection to WMI server failed] No host records (A or AAAA) were found for this DC
Summary of DNS test results: Auth Basc Forw Del Dyn RReg Ext _________________________________________________________________ Domain: ce.local sbs PASS PASS PASS PASS PASS PASS PASS dc1 PASS FAIL n/a n/a n/a n/a n/a
Summary of DNS test results: Auth Basc Forw Del Dyn RReg Ext _________________________________________________________________ Domain: ce.local sbs PASS PASS PASS PASS PASS PASS PASS dc1 PASS PASS PASS PASS PASS PASS PASS
Can you check if Remote Registry is running on both servers?
Remote registry service was not running on DC1 (Server 2016) and I have manually started it. The service is set to run as an automatic (triggered start) service. The old SBS server has remote registry service set to automatically start and not triggered.
I did re-run the DCDIAG /test:DNS /DNSALL /e /v command but the error still is present with DNS in the Basic section.
Thanks.
Ken
Set Remote Registry to start automatically and reboot both servers. Run a dcdiag after doing this
I will do so over the weekend during non-production hours. Thanks for the help.
You may also try this from an elevated Powershell prompt, do this on both servers.
Restart-Service NTDS -Force repadmin /syncall /APeD
I ran these commands on both servers. The repadmin was successful on all syncs with no errors. However, dcdiag diag is still sending the same error for basic on the one DC1 server when I run dcdiag from SBS. Running dcdiag on DC1 returns no errors, however.
I am wondering if you actually promoted the new DC? Did that really happen already? Can you check in server manager for warnings that the server needs to be promoted?
Also run this and report back:
repadmin /showrepl
This command does run properly on both servers. And I'm certain the promo was successful. Results are below from both servers.
==== INBOUND NEIGHBORS ======================================
DC=ce,DC=local Default-First-Site-Name\SBS via RPC DSA object GUID: 2621b791-6b38-45b1-81e2-6795e6447837 Last attempt @ 2023-02-17 07:07:40 was successful.
CN=Configuration,DC=ce,DC=local Default-First-Site-Name\SBS via RPC DSA object GUID: 2621b791-6b38-45b1-81e2-6795e6447837 Last attempt @ 2023-02-17 06:51:06 was successful.
CN=Schema,CN=Configuration,DC=ce,DC=local Default-First-Site-Name\SBS via RPC DSA object GUID: 2621b791-6b38-45b1-81e2-6795e6447837 Last attempt @ 2023-02-17 06:51:06 was successful.
DC=DomainDnsZones,DC=ce,DC=local Default-First-Site-Name\SBS via RPC DSA object GUID: 2621b791-6b38-45b1-81e2-6795e6447837 Last attempt @ 2023-02-17 06:53:48 was successful.
DC=ForestDnsZones,DC=ce,DC=local Default-First-Site-Name\SBS via RPC DSA object GUID: 2621b791-6b38-45b1-81e2-6795e6447837 Last attempt @ 2023-02-17 06:51:06 was successful.
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32>repadmin /showrepl
Repadmin: running command /showrepl against full DC localhost Default-First-Site-Name\SBS DSA Options: IS_GC Site Options: (none) DSA object GUID: 2621b791-6b38-45b1-81e2-6795e6447837 DSA invocationID: 2621b791-6b38-45b1-81e2-6795e6447837
DC=ce,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: e1838dcb-4d67-4a21-8831-67ed1831a604 Last attempt @ 2023-02-17 07:11:44 was successful.
CN=Configuration,DC=ce,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: e1838dcb-4d67-4a21-8831-67ed1831a604 Last attempt @ 2023-02-17 06:56:12 was successful.
CN=Schema,CN=Configuration,DC=ce,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: e1838dcb-4d67-4a21-8831-67ed1831a604 Last attempt @ 2023-02-17 06:56:12 was successful.
DC=DomainDnsZones,DC=ce,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: e1838dcb-4d67-4a21-8831-67ed1831a604 Last attempt @ 2023-02-17 06:56:12 was successful.
DC=ForestDnsZones,DC=ce,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: e1838dcb-4d67-4a21-8831-67ed1831a604 Last attempt @ 2023-02-17 06:56:12 was successful.
C:\Windows\system32>
OK, let us wait for a reboot of both until doing more troubleshooting.
The reboot of both servers did not resolve the problem with dcdiag dns basic tests. However, I did some further digging into the "no WMI connectivity" error I'm getting in the output of the dcdiag with error 0x80070005. It turns out that Microsoft broke forward compatibility: older versions of Windows cannot query WMI over DCOM to later ones that have received the DCOM hardening patch. Microsoft KB5004442 explains the timeline of the patches released and the impact to older versions of Windows that try to connect and query using WMI over DCOM. Obviously, Windows Server 2008 R2 has been retired and really shouldn't be used in production anymore. But it's good to know the cause of the dcdiag and DNS test failures. In my case, replication is still working fine and tests with repadmin /replsum and repadmin /showrepl proves this fact. My Windows Server 2016 (DC1) does have these DCOM hardening patches so this is the cause. For now, you can add a reg key to allow the behavior but it will become permanent March 14, 2023 with those patches.
KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) - Microsoft Support
Update release
Behavior change
June 8, 2021
Hardening changes disabled by default but with the ability to enable them using a registry key.
June 14, 2022
Hardening changes enabled by default but with the ability to disable them using a registry key.
November 8, 2022
In response to your feedback, the November 8,2022 update includes a client-side (device, application, or service acting as a DCOM client) patch. This patch automatically raises the authentication level of all non-anonymous activation requests to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. If you use third-party Windows DCOM client applications and are dependent on the software providers to raise the activation authentication level to support DCOM hardening changes, this patch removes the dependency. This allows the activation authentication level to be raised automatically at the Windows OS level. This prevents the activation requests from being rejected by DCOM servers that have enabled DCOM hardening changes.
March 14, 2023
Hardening changes enabled by default with no ability to disable them. By this point, you must resolve any compatibility issues with the hardening changes and applications in your environment.
OK, yes I have read this before but not thought about this. We should have migrated any server that runs Windows 2008 (r2) ages ago. There will be a moment that a migration is impossible.
Makes sense. For these types of issues when a newer DC/GC has already been added to a legacy domain running SBS 2011, I presume the only option will be to seize the fsmo roles and delete the old SBS 2011 server from ADUC and possibly clean-up after taking it offline. I understand this isn't the preferred method but it kinda works.