DynamicSiteName not updating to RoDC Site

[BrentStobbs]

I have 2 Active Directory Sites, the first site (Corporate) has my RW DCs, while the second (DMZ) only has a RoDC.

The two sites are separated by a firewall which allows Domain Traffic (53, 389, etc etc) between my RoDC and my RWDCs.  Traffic from other devices in the second site is blocked, so they can only talk to the RoDC (GC, DNS. DHCP).

If I join a device to the domain while it is connected to the Corporate site, the DynamicSiteName registry entry is set to Corporate-Site. I then move to the DMZ and attempt to log in, but it cannot find a DC to authenticate against.

I then change the DynamicSiteName to DMZ-Site, and attempt to log in again, it can find the RoDC, authenticate and everything is happy.  I can restart the device and do what I like and all is well.

If I then move the device back to the Corporate-Site.  DynamicSiteName gets updated automatically based on the IP address and everything is still happy.

Moving the device back to the DMZ, DynamicSiteName does not get updated, and I am unable to authenticate again until I manually update DynamicSiteName.

Obviously if I set a registry entry of "SiteName" the device can physically move between the Sites, but will always be bound to the DMZ-Site.

If I open up the firewall and allow domain traffic from the client to the RWDCs, the DynamicSiteName is updated and the user can be authenticated correctly.

What am I missing that is stopping the client from detecting the correct site and updating DynamicSiteName from the RoDC when connected to the DMZ?

[#2]

And the ip-subnet of the device is linked to the DMZ Site? Normally a client discovers it but it has to be able to talk and get a response back..

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client.

If the client is communicating with a domain controller that isn't in the closest (most optimal) site, the domain controller returns the name of the client's site. If the client has already tried to find domain controllers in that site, the client uses the domain controller that isn't optimal. For example, the client sends a DNS Lookup query to DNS to find domain controllers in the client's subnet.

Otherwise, the client does a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the domain controller isn't in the optimal site, the client flushes the cache after 15 minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/how-domain-controllers-are-loc...

[#3]

Thanks for your reply, unfortunately though I think you missed the point. The process works flawlessly if the client can contact the RWDC in another site. However, if that link is broken or blocked, The site is not updated to the correct site (with the RoDC).

[#4]

I was trying to show the process which is partly DNS. The client connects to DNS and gets a domain controller back and then it checks if it talks to the closest one based on subnet. I guess the normal DC is higher preference and is being connected first...

[#5]

Any update ?

[#6]

Check if you're RODC is in DNS entry "_ldap._tcp.dc._msdcs.<FQDN AD DOMAIN>", if not add it.
RODCs do not register domain-wide SRV records by default, and again by default register only the site-wide SRV records and also do not perform automatic site coverage