You Are Not Smarter Than The KCC

I had this discussion with a fellow PFE David Gregory , who use to be out of Chicago but now has moved to a better place (read Southern California), at a Polo Loco in Compton, CA. The same one 2Pac rapped about, you know the one I'm talking about. This is what us PFEs do sometimes, eat at fast food places (In-N-Out) and discuss odd technology issues. The topic came up was how often do we see customers that have manually configure connections objects for their DCs? The answer was way too much. If you have properly defined your AD sites and site costing, you shouldn't have to create manual connection objects. Most of the time you just end up making more of a problem for yourself by defining this. Let the KCC automatically create and remove connection objects as it needs to. A manual created connection object is not managed by the KCC at all. If you really want to know how the KCC does decide what to connect I highly recommend you read this, https://technet.microsoft.com/en-us/library/cc755994(WS.10).aspx.

(This is what it should look like if you would just stop monkeying with it)

 

Ok so what does it look like if "someone" actually made a manual connection object?

 

(It's horrible looking)

 

Ok so the next thing we discussed was how do help customers fix this is the best way possible. The easiest way is pretty straight forward, right click the connection object, delete. Seems pretty simple. But there is a better way to do this. And this is what David and I talked about. What if that manual connection object was correct? The KCC will then see that it needs a connection and re-make one. So what. The problem is that when a new connection object is made a VVJoin has to be done https://technet.microsoft.com/en-us/library/cc758169(WS.10).aspx. This can be a semi-painful process. If you have to do it thats fine but why do it if you dont have to do it? So the solution you really want to do is make that manual connection object to be managed by the KCC.

To do this follow these steps

1.) Open ADSIEdit and go to the Configuration partition.

2.) Drill down to Sites, the site where the manual connection object is, Servers, the server where the manual connection object is created, NTDS Settings

3.) Right click on the manual connection object and go to properites

4.) Go to the Options attribute and change it from 0 to 1

5.) Either wait 15 minutes (that's how often the KCC runs) or run repadmin /kcc to manually kick it off

 

Just like that it will be managed by the KCC. If that is the best connection object it will continue to use it with no VVJoin, if not it will tear it down and then make the best connection object.

 

UPDATE: Fellow PFE Tom Moser blogs.technet.com/b/tommos let me know that if you have an RODC manual connection object the options attribute will need to be changed from decmial value 64 to 65. It will then show up as IS_GENERATED | RODC_TOPOLOGY 

 

Mark "Insert Your Favorite 2 Pac Lyric" Morowczynski

Comments

  • Anonymous
    January 01, 2003
    How are your sites set up? What are you making a manual connection to?

  • Anonymous
    January 01, 2003
    Yes, it's a Great tip to fix certain Replication issues. THANKS a LOT Mark.

  • Anonymous
    January 01, 2003
    Thanks Mark. There are a lot if issues at play. The big plan is to move to fresh 2012 dcs and stop mucking with the settings so much. As they upgrade the DCs to 2012, (because thats the big plan here), should we make the first new 2012 the FSMO master?

  • Anonymous
    January 01, 2003
    Thanks Santhosh

  • Anonymous
    January 01, 2003
    Michael, Lot going on there. Sounds to me like manual COs are not the biggest concern. What types of kerberos errors? I'm also confused you say that all servers see the new FSMO role master but are still getting time from the old one?

  • Anonymous
    January 01, 2003
    Mark, Well, all the fsmo roles were moved from server 02 to 02A . Looking at the fsmo role report (aduc/addt) at each domain controller, they all report that server 02A is now the fsmo master. I restart the time service on each of the domain controllers and they all want to sync on 02, even server 02A (the pdc emul) will sync to 02. They should all sync to 02A the new PDC emulator and server 02A will get time from clock until you configure it for external ntp source. There will also be a warning in system event log about configuring the server to external time. Hope that resolves confusion with that. What is the best method for deleting the manual connection object and then forcing the KCC to generate a new connection object. I've had the most luck doing it at the server console I am modifying sites and services for. For example, if i were to destroy the manual connection objects on server 4, I would RDP onto server 4 and do this work. What's your technique?

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Mark, I have a client forcing a hub and spoke replication with MANY manually created connection objects. At the center of this hub and spoke is a server that was probably upgraded from 2000 to 2003 (the windir is WINNT) and reporting many kerberose errors. This was the FSMO master until recently when it was moved to a new 2003 dc, but while all the other dcs say "yep, the fmso master is moved to this new server", they all get their time (I cycled the service) from the old FSMO master. What say you about all these shenanigans?

  • Anonymous
    January 01, 2003
    For one site where the dc a w2k3 this works. For the other site with the dc w2k8r2 the manually created connection disappears after running repadmin /kcc. Any idea? Thanks!

  • Anonymous
    January 01, 2003
    Michael, If you follow this post, if you flip them from Manual to managed by the KCC, the KCC will then delete them if they are not necessary. However if you do want to delete them your method is fine. The KCC runs every 15 minutes or you can force it by running repadmin /kcc. The time issue you state is correct if the time source is set to NT5DS for domain hierarchy these may not be configured this way. I'm not familiar with that kerberos error.  You may want to open a case.

  • Anonymous
    January 01, 2003
    No problem Mr. X. Keep posting in the forums. I wish I had more time to.

  • Anonymous
    January 01, 2003
    Nice tip! Thank You Mark :)

  • Anonymous
    January 01, 2003
    @Megoon This would be expected behavior as the KCC will remove any of your converted manual site links that are not needed. If they are needed it will continue to use them.

  • Anonymous
    January 01, 2003
    That's how I like to do it but you don't have to.

  • Anonymous
    January 01, 2003
    Excellent Post!.. Title is catchy.. ;) Mohan R Server Engineer

  • Anonymous
    January 01, 2003
    @megoon without running repadmin /kcc the connection had been changed to <automatically created>.

  • Anonymous
    January 01, 2003
    Nice blog Mark.  

  • Anonymous
    October 09, 2011
    Thanks for sharing

  • Anonymous
    August 17, 2012
    Tremendous, but is this not an incorrect generalisation as some organisations use manual connections because they don’t have a fully routable network.

  • Anonymous
    August 01, 2014
    Thanks Mark,I have fixed my issue with this

  • Anonymous
    August 15, 2014
    Very Helpful

  • Anonymous
    May 14, 2015
    I came across this because I wanted to find the best practices for setting up the replication settings. I just knew our site at this new job was not quite set up correctly.
    The automatic connections are doing a hub and spoke apology to some minor remote site. And then after reading this and other articles as realize, the prior idgit didn't properly configure the site links and site costs.

  • Anonymous
    May 19, 2015
    HI,

    After adding forest trust and few sites i have noticed that my NTDS settings goes to Object GUID name not

    Also Found that Options was set to 0x4=(Override_Notify_default)

    Now i'm having with issues with take longer to replicate changes?

    No errors but take longer?

    As

  • Anonymous
    March 14, 2016
    Great tip! One for the bookmark.