Do Not Allow a Domain Controller to Authenticate Users

Even though I changed the weight and priority of the SRV record in about a dozen areas in DNS, that original SRV record keeps appearing. Any idea why? Where would I go to change it in the registry?

Because you are doing it wrongly, by default netlogon reregister all srv records every 24 HRS or if restarted manually or during server reboot and if it don't find registry for same, it restores default value

look below thread
https://www.experts-exchange.com/questions/28489554/Changing-the-Weight-and-Priority-of-a-Domain-Controller-problem.html

Do I create the new DWORD (32 bit)  LdapSrvWeight registry entry only on the DR domain controller?

yes, but why you want to create it, simply restart netlogon service on that DC and remove any custom entry you created afterword's

concentrate on AD sites and service and your issue will gte resolved

You won't achieve anything by modifying weight and priority in this case since DC is located in DR location

So you're saying in Sites and Services, if I add all the server and user subnets to the main office site, those subnets should not look at the DR DC?

Easy, block AD ports to all but DCs using the Windows Firewall

yes, that is true

also same time for DR there should be AD site and DR DC should be part of that site

Agree, but without disabling publishing generic SRV records clients will still go to DR once in a while

clients will not go to DR DC as long as subnet to site attachment is correct unless there is malfunction happens on network front

In Sites and Services, I linked all the server/user subnets to the office site. The only subnet linked to the DR site is the DR subnet.

On the DR DC, I also edited the registry to give that DC a weight of 80 which should make it last on the list.....even though this is not recommended I figured it couldn't hurt. Making this change populated in DNS. I deleted the SRV record I created manually in several areas on DNS.

If sites and subnets are correctly configured, no client will go to DR site DC and you don't need to modify any registry there
registry would be helpful if at DR site few other DC's and users sitting there as well and you want to control how users authenticated between DR DCs

If sites and subnets are correctly configured, no client will go to DR site DC and you don't need to modify any registry there

Sorry, this is not correct

it may be worth just clarifying a couple of quick points here:

There is no such thing as a DR Domain Controller (not since way back in the PDC/BDC days of Windows NT).
Any active/valid domain controller is able to serve DC tasks and will be used in a fairly random/distributed way by design

The ONLY way to control which DCs are used in any given situation is by providing AD with a topology that specifies which servers are preferred due proximity to any given logical location.
This is where AD Sites & Services comes in.

This facility allows you to assign subnets to logical locations within your infrastructure. This includes Domain Controllers and the network links between them.
Using this info, AD can establish the most efficient (quickest, least cost, preferred) Domain Controller for any given source subnet.
In your case, you may be able to configure your topology in a way which ensures this 'DR' server is the least preferred DC. it still isnt a DR as such and may still serve DC tasks, but is less likely to identified as the preferred server in any given scenario.

On that basis, I recommend looking at your topology as recommended by Mahesh above.
We're happy to assist if you'd like :-)

No, Topology alone will not achieve this. You need to disable the appropriate record publishing using the DC Locator DNS records not registered by the DCs option, test it if you do not believe me.

Firewalling the DC off is by far the easiest solution without doing weird tricks. That said, irrespective of this, topology should be defined correctly.

Shaun, by making that registry change I was able to change the weight on all SRV records pertaining to that domain controller in DNS. Is this sufficient to what you are saying?

Steve, sorry for the confusion. I know there is no such thing as a DR DC. I was just trying to clarify by stating it was located at the DR site to give a picture on the issue I was having. I followed Mahesh's steps and linked all the server/user subnets to the main office site in Sites and Services.

still your users are authenticating with DR DC?

I'm not seeing any but just want to make sure everything was correctly configured.

Firewalling the DC off is by far the easiest solution without doing weird tricks. That said, irrespective of this, topology should be defined correctly.

I don't recommend this. Firewalling a DC doesnt stop clients trying to reach it, but failing. This delays and slows down the network in general as a percentage of DC requests will fail.

Steve, sorry for the confusion. I know there is no such thing as a DR DC. I was just trying to clarify by stating it was located at the DR site to give a picture on the issue I was having. .

Trying to prevent a DC being a DC is a grey area that usually results in issues at a later date.

I followed Mahesh's steps and linked all the server/user subnets to the main office site in Sites and Services

Are all of the server/user subnets in the main office? if not this may not be the best approach as the topology you've configured in AD doesn't match what you actually have. It will probably achieve what you're asking for, but may have other implications later on.

Don't play with registry
Don't play with firewalls
Only setup AD sites and service correctly, I believe you only have mail site and DR site, so what you did is right. with this 99% issue will get sorted out - 1% you must leave for any unknown reasons.

Shaun, by making that registry change I was able to change the weight on all SRV records pertaining to that domain controller in DNS. Is this sufficient to what you are saying?

DC Locator DNS records not registered by the DCs is a GPO setting

I don't recommend this. Firewalling a DC doesnt stop clients trying to reach it, but failing. This delays and slows down the network in general as a percentage of DC requests will fail.

This delay is milliseconds and reticketing is every 12 hours

Trying to prevent a DC being a DC is a grey area that usually results in issues at a later date.

No, it won't. You should still allow all other DCs to communicate

Don't play with registry

Every GPO setting is a Registry value, are you advocating that we shouldn't use GPOs?

Don't play with firewalls

Blocking a host/port is what exactly what it is indented to do

I do not want it to be authenticating users

Only setup AD sites and service correctly, I believe you only have mail site and DR site, so what you did is right. with this 99% issue will get sorted out - 1% you must leave for any unknown reasons.

You will not achieve OPs desired effect with sites and services, authentication will still occasionally happen cross-site. Like I said go and test it

Entire point is that DR DC is already isolated in separate site with no production subnets and thus providing expected results - OP can confirm...

Hence other workarounds are not required or simply overkilling

Entire point is that DR DC is already isolated in separate site with no production subnets and thus providing expected results - OP can confirm...

Sure, OP can confirm in a week or two that authentication still bleeds to DR DC

Shaun, I would make the change on the domain controller GPO for the DC located at the DR site correct? In the attached file, would the highlighted policies be the ones to change?
Capture2.PNG

Looks like the best way to set this policy is to create a Child OU off the Domain Controller OU. Then move the DR DC into that Child OU and attach a new GPO.

My questions is what Mnemonics do I add? For example if my DR DC server name is serverDR

Think we have a difference of opinion going on here and I certainly don't want to get into a battle, but I'm not an advocate of making changes to stuff without the right justification.
The recommendations being made by Shaun are valid and are likely to result in achieving the effect requested, but they could also have other implications. (Note, I'm not saying they WILL, just they MIGHT)

On that basis, and from what we know about the OP's setup so far, I'm with Mahesh on using ADs build-in topology to ensure the 'DR' site is rarely used based on topology, but still fully functioning and usable.

if the DC(s) at the primary site go down, this DR site's DCs would seamlessly serve DC tasks without any interaction.
Shaun's steps prevent this and mean the DR site's DC would not work in a DR situation without manual intervention.

Incorrect, you allow all DC-to-DC communication and allow all DR subnets though the Windows firewall, so no manual intervention if you move resources over to DR

You say might because of an opinion, I say won't because I have actually tested it.

Also, I have seen cross-site authentication at many clients if you do not set DC locator settings, even when sites and subnets are correctly defined.

what will you do when you have multiple active AD sites ? You can't simply deregister SRV records for those DCs...and you can't play with SRV weight and priority as well. U has to rely on AD sites and services only in that case

You set DC locator settings so that generic DNS service records are not published. This way only DNS service records are published within the actual size

For the DR DC, lets say I do set the DC locator settings so that generic DNS service records are not published. Whenever it's time for a DR drill, will this cause any issues because now we are relaying on the DR DC for authentication.

Depends on your DR strategy. Explain your order and I will give you the steps

The plan is to not bring up the other domain controllers during a DR drill. The only DC that will be up is the one currently running at the DR site.

So during a DR drill, you disable the GPO that does the DC locator settings and you cut the line/drop the link/firewall of the production environment