Started out Trying to apply Cumulative Update CU14 to Exchange 2013, failed due to error:
> Error: Setup can't use the domain controller 'Default-First-Site-Name'
> because it belongs to Active Directory site ''. Setup must use a
> domain controller in the same site as this computer
> (xxxxx.xxxxxxxx.com). For more information, visit:
> http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DomainControllerIsOutOfSite.aspx
So I looked at the link, and it says:
> The schema master is not running Windows Server 2003 Service Pack 1 or
> later_DomainControllerIsOutOfSite
but both my Domain Controllers are running Win Server 2016.
The error message says:
> *because it belongs to Active Directory site ''*,
with a blank. What's that about?
So I started checking out my DCs. I ran DCDiag on my Primary DC (Asgard), and it reported an error.
> D:\ExchangeCU14>dcdiag
>
> Directory Server Diagnosis
>
> Performing initial setup: Trying to find home server... Home
> Server = Asgard * Identified AD Forest. Done gathering initial
> info.
>
> Doing initial required tests
>
> Testing server: Default-First-Site-Name\ASGARD
> Starting test: Connectivity
> ......................... ASGARD passed test Connectivity
>
> Doing primary tests
>
> Testing server: Default-First-Site-Name\ASGARD
> Starting test: Advertising
> Warning: **DsGetDcName returned information for** **\\Elsinore.areteind.com, when we were trying to reach**
> **ASGARD.**
> **SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.**
> **......................... ASGARD failed test Advertising**
So I checked, and Asgard is set as the PDC, and it is a Schema Master, and has all five FSMO roles assigned to it. Elsinore is the backup or secondary DC, and is also a schema master. Both have DNS running on them and Replication appears to be running in both directions.
Why is DsGetDcName …. returning information for Elsinore …. (the backup) when it is ….trying to reach Asgard … (the PDC) ?
When I checked, the Active Directory SItes and Services "Cannot Locate Primary Domain Controller"
I checked Dns and they are both Asgard and Elsinore are properly registered with the correct IPs.
On a hunch, I ping them both, and the results were interesting.
(Asgard IP4 is set to 192.168.87.2 and Elsinore is 192.168.87.3)
> D:\ExchangeCU14>ping 192.168.87.2
> Pinging 192.168.87.2 with 32 bytes of data:
> Reply from 192.168.87.2: bytes=32 time<1ms TTL=128 Reply from
> 192.168.87.2: bytes=32 time<1ms TTL=128
> D:\ExchangeCU14>ping Asgard
> Pinging Asgard.areteind.com
> [fe80::f410:6f29:783e:9b6d%9] with 32 bytes of data:
> Reply from fe80::f410:6f29:783e:9b6d%9: time<1ms Reply from
> fe80::f410:6f29:783e:9b6d%9: time<1ms
Why is ping by FQDN use the IPv6 address and not the IPpv4 address?
This is IpConfig /all from Asgard: ( there are two NICs in the machine and they are on a TEAMed connection named TeamAsgard:
> D:\ExchangeCU14>ipconfig /all
>
> Windows IP Configuration
>
> Host Name . . . . . . . . . . . . : Asgard Primary Dns Suffix .
> . . . . . . : areteind.com Node Type . . . . . . . . . . . . :
> Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy
> Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . :
> areteind.com
>
> Ethernet adapter TeamAsgard:
>
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Driver
> Physical Address. . . . . . . . . : 00-1F-29-C9-1E-52
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
> Link-local IPv6 Address . . . . . : fe80::f410:6f29:783e:9b6d%9(Preferred)
> IPv4 Address. . . . . . . . . . . : 192.168.87.2(Preferred)
> Subnet Mask . . . . . . . . . . . : 255.255.255.0
> Default Gateway . . . . . . . . . : 192.168.87.1
> DHCPv6 IAID . . . . . . . . . . . : 201334569
> DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-2D-CF-83-00-1F-29-C9-1E-52
> DNS Servers . . . . . . . . . . . : 192.168.87.2
_______________________192.168.87.3
> NetBIOS over Tcpip. . . . . . . . : Enabled
>
>Tunnel adapter isatap.{FDE8723C-2280-4314-8A87-E79DE2C1A433}:
>
> Media State . . . . . . . . . . . : Media disconnected
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
> Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
If I run NLTEst /DCName, I get:
> D:\ExchangeCU14>nlTest /DCName:Areteind.com NetGetDCName failed:
> Status = 2453 0x995 NERR_DCNotFound
The error says:
> Active Directory Domain Services was unable to establish a connection
> with the global catalog.
Any ideas about where I should go next?
Performed additional tests as recommended by @Greg Askew:
(All tests were run from Exchange Post Office – where Exchange CU14 setup initially failed from)
C:\Windows\system32>netdom query fsmo
Schema master Asgard.areteind.com
Domain naming master Asgard.areteind.com
PDC Asgard.areteind.com
RID pool manager Asgard.areteind.com
Infrastructure master Asgard.areteind.com
The command completed successfully.
C:\Windows\system32>nltest /dsgetdc:areteind.com /server:asgard
Getting DC name failed: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF
C:\Windows\system32>nltest /dsgetdc:areteind.com /server:elsinore
DC: \\Elsinore.areteind.com
Address: \\192.168.87.3
Dom Guid: c6193583-51f3-41b3-8681-2085733d6ea1
Dom Name: areteind.com
Forest Name: areteind.com
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: GC DS LDAP KDC WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE F
ULL_SECRET WS DS_8 DS_9 0x10000
The command completed successfully
The last two seem to offer a hint as to why all this is happening, (but now how to fix it). The system seems to not be able to connect to Asgard as a PDC using dsgetDC, even though it is registered in dns by the correct ip address and definitely designated as the PDC.
To address dns, here is a screen shot of SRV records in DNS:
Best Answer
That can be caused by the NETLOGON service not running. The only reason I can think of that it would be stopped/set to manual is someone (perhaps temporarily) did not want the DC to serve authentication requests.