Can I configure automatic server connections in ADSS for our RODC's?

Lets say, as long as the DCs are able to talk to each other, demoting them should take them clearly out of the domain.
And promoting them will also put them clearly back into the domain again.
You just have to make sure, that - if a firewall is between them - all needed ports are open.
If there are reasons not to used the automatically created connections, you can create them manually.
It is just not recomended, as the automatic repairment mechanism doesn't work for manually configured connections. 

Can we delete the manually created site connections and run "repadmin /kcc" from the RODC's and automatically generate new site connections to one of our newer DC's in the "VPN", even though the RODC's are in a separate site?

Yes. As long as there is comms between the DC's - the KCC will do its job.

How long should it take KCC to create a connection?  I know the RODC has access to the original DC at a minimum.  But it "should" have access to all three DC's given they all have the same firewall rules applied.  I ran "repadmin /kcc" from the RODC as well as from one of the newer writable DC's in the neighboring site.

The connection is not the issue, the question is, how much data they have to exchange until the DCs are in sync.
And this depends from your AD size as well as from the speed of the connection.
But as long as the DCs are not in sync, the clients will take one of the others as far as reachable.
As far as the AD is in sync, the new DC will accept logon attempts. 

It's been several hours and AD has not created a new connection between my RODC and any of the writable DC's in the neighboring site.  It appears I can (re)create a manual connection.  But I'd rather have AD automatically create it.

What do I need to check first?

NOTE: There is a second RODC in the same remote site that I've not touched.  It still has its manual connection to a writable DC in the same neighboring site.

Have you run repadmin or just promoted the DC?

New DC's had been promoted over a week ago.  I ran "repadmin /kcc" today from the RODC and from a writable DC I hoped it would connect to.  All writable DC's show up when I start the wizard in ADSS to manually create the connection for the RODC.  But I've not completing the wizard.

As you said, the DCs are in different sites...
Have you defined site links in AD Site and Services - Site - Inter-Site Transports?

Yes, there's a site link for these two sites.  There's a working manually created site link between the other RODC and the soon to be retired DC in the other site.

Site : DMZ
RODC1
RODC2

Site : VPN
Old-DC1
New-DC1
New-DC2

Current site connections:
RODC1 - Old-DC1

No new connection has been created between RODC2 and any of the DC's in site "VPN".

Confirmed with our network engineer that all ports are open between the RODC's and the writable DC's in site "VPN".

I haven't found any event log errors in DFS nor the System logs.

Have you created the subnets according to the sites?
Can you see a Inter-Site-Transport - IP - Site Link Bridge?

Yes and yes.

Just found this one..
https://www.microsoft.com/en-us/download/details.aspx?id=30005

This is a GUI replacement for repladmin /showrepl .
Just to validate the current replication topology. 

There is a good technet article linked there:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755994(v=ws.10)

To generate the intersite connections, run the KCC from the server, which is defined as Bridgehead for the site.

So here's a question for you.  The AD Replication Status Tool shows a successful sync between my read-only DC in my "DMZ" and a writable DC in my "vpn" site despite the fact that ADSS shows no such link between the two.  

But I just looked at the event log for my RODC and found the following events repeating ever since I deleted the existing connection back on Friday

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          6/7/2021 4:21:06 PM
Event ID:      2843
Task Category: Knowledge Consistency Checker
Level:         Error
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      RODC2
Description:
The Knowledge Consistency Checker was unable to locate a replication connection for the read-only local directory service.  A replication connection with the following option must exist in the forest for correct FRS system behavior.
 
Additional Data
Option:
64
User Action
Restore the original replication connection for the local directory service instance on a writable directory service instance.


Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          6/7/2021 4:21:06 PM
Event ID:      1435
Task Category: Knowledge Consistency Checker
Level:         Warning
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      RODC2
Description:
The Knowledge Consistency Checker (KCC) encountered an unexpected error while performing an Active Directory Domain Services operation.
 
Operation type:
KccSearch
Object distinguished name:
CN=NTDS Settings,CN=RODC2,CN=Servers,CN=DMZ,CN=Sites,CN=Configuration,DC=xxxx
 
The operation will be retried at the next KCC interval.
 
Additional Data
Error value:
0 No Error.
 
Internal ID:
f0407b4
Event Xml:

The following article describes exactly what I did and (hopefully) what fixes the situation - Events 6804 and 2843 are logged and RODCs do not replicate SYSVOL

What I'd like to know is why the connection isn't automatically created?  

Here is another article according your two errors.

The background here is, that beside the AD synchrononisation, there is a (D)FRS snyc relationship to snyc the sysvol folders.

You can use the DFS Management MMC snap in to see them...

Have a look there what you see or even not see, maybe there are left over fragments from the old connection. 

And here the article:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/facce838-a820-4710-885c-5dc39be299f1/repeated-kcc-errors-on-rodc-event-id-1435-and-2843

I see one replicated folder for each of my DC's in the DFS Management .console  It looks similar to your screenshot.

I saw the 2847 error once more from the early a.m. hours today.  But the other pair of errors have stopped.  I guess all I can do is continue to monitor the event log for more 2847 errors?

I don't understand why AD insists on replicating through the old DC to my RODC despite the fact that I configured the connection to use one of the newer DC's in ADSS.  "repadmin /showrepl RODC" confirms the (succesful) replications.

Usually, if you promote a DC, the NTDS connetion as well as the DFSR connection is set.
If AD is not completely set up, means AD Sites and service -- Site, Subnets, Intersite Transports etc are not setup in the right way or just not complete or due to other reasons, it may happen that one of the task do not completely finish.
Also if folders changes something may break.
The same if you remove connections, it may happen that the DFSR connection is still there.
Left over fragemnts from the past, even if you are not aware anymore. 
Also older DCs may play a role if they use FSR and where never migrated to DFSR.

Both connections are visible as AD objects in AD or can be made visible by the tools (above).

This is the reason, why one of the hints (article above) is to force a demotion, clean up all fragments and promote again.

If you check your connections, you have to make sure, that all existing NTDS as well as DFSR connections are fitting together. If there are fragment left over from earlier connection, they may prevent the automatism to work as expected.
 

So I keep finding one thing after another with these W2K12 RODCs (replication, DNS errors, duplicate DNS service location records).  I'm thinking the best thing would be to demote each RODC, make sure all fragments and DNS remnants are gone, and replace it with a new W2K19 server-core RODC.  

That said, do you have a go-to doc on creating a RODC on W2K19 server-core?  I have what I used to create these W2K12 server-core RODCs. But my references are a little dated at this point.

Hello,
I don't really use server-cores, even could not find a lot as I guess you need some scripting.
For the GUI you can find more, i.e....
https://dailysysadmin.com/KB/Article/3947/how-to-create-a-windows-server-2019-rodc-or-read-only-domain-controller/

But possibly you may create another question asking exactly for that, I guess the one or other expert here may have some articles or scripts to support you.
The general procedure is the same, you just can not use the GUI.

Why server-core?

According to 2019 DC in general, be aware that not all applications will work with 2019 DCs, so you may inspect your environment just to avoid, running into issues. Especially if you use AD integrated applications like Exchange, Lync, SharePoint etc. 

We're using RODC's b/c this is a perimeter network (DMZ) where the servers in there need DNS.  There's also one hosted application that needs the ability to do LDAP against our AD.  We went with server-core to reduce the footprint since this is a perimeter network.

If there's a way to convince me, my network engineer, and our security officer, that we don't need server-core on this perimeter network, I'll listen.  It certainly would make this task a lot easier.  The server-cores are difficult to manage comparatively.

> the server-cores are difficult to manage comparatively
Thats the point.
It is my personal opinion, but if a hacker tries to hack your RODC, i would not assume he uses the AD GUI. He would need  a RDP connection which can easily blocked from outside.
They use more native protocols like LDAP, and this works even in the core version.
Also hacking attacs are usually scripted.
The core version just has some advantages because it is more slim, you need a little bit less resources, but from the security perspective, I do not see really advantages to switch the GUI off.

For a perimeter network you can even setup DNS without a DC as well as you can pass LDAP requests through an inner firewall, so I would put the DC in the DMZ generally into question.  
Another option maybe to use an ADLDS, but then you also may need a kind of synchronisation.

The older Exchange Edge server working this way.