Announcement

Collapse
No announcement yet.

Disabling KCC for Large Enterprises: a phylosophical view [Long post]

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Disabling KCC for Large Enterprises: a phylosophical view [Long post]

    Hello everyone.

    Me and Luke were recently enjoying a philosophical discussion (as usual, see, http://forums.petri.com/showthread.php?t=3236 ) about how much useful is disabling KCC from generating inter-site topology for connecton objects for reaplication in a Single or Multiple domain Large Enterprise.

    During past 3/4 years we acquired much experience in designing and implementing an Active Directory infrastructure for Enterprises with more than 10.000 users. We had the opportunity to design and implement Single Forest with many (more than 15) child domains, and Single Forests with Single Domain world-wide-spread; sometimes for political reasons, due to a not-fully-trusted-administrator at remote sites, some other times for technical reasons (bandwidth), we always had the necessity to disable KCC. We needed the full control over generation of connectors and a new Domain Controller creation should have not triggered KCC from running again, so we just stopped it.

    Discussing more generally, we realized that usually KCC is designed to run normally and Microsoft designed KCC to run also for many sites (more than 500). Also, Windows 2000 pre-SP2 had many problems generating an inter-site topology for domains with more than 400 sites. Windows 2003 introduced a new feature for KCC Inter-site Generation Topology when raising to Windows 2003 Native Forest Functional Level.

    Recently we are working with one of our customers which is going to consolidate current Windows 2000 Active Directory Structure (1 Empty Root Domain with 6 Child Domain, one per Region) to Windows 2003 Active Directory Structure made-up by 1 single domain worldwide. We are not project designer for this project and we have seen that actual project designer made a choice we consider "absolutely-unexplainable-choice": 1 Domain, 1730 subnets in 690 Sites, 550 Sitelinks displaced in a hub-&-spoke topology, KCC still running for inter-site topology and Bridging of all site links enabled .....
    We don't really understand this choice. Leaving KCC enabled AND Bridging of All Site Links enabled has the same result as just creating 1 single SiteLink displaced in a backbone topology with all 500 sites put inside this single SiteLink. The only reason we can imagine is that with hub-n-spoke topology you can set different schedulation and latency. Sorry that for some political reasons we cannot ask these project designers the reason for this choice

    In your experience, how frequent is to disable KCC in such environment? Are we completely wrong when we decide to have a full control over topology generation or is there some systems engineer out there that has the same feelings?

    So the question is: "is it really useful / frequent behaviour, the practice of disabling KCC from generating inter-site connectors for Large Enterprises?"
    Luke and Max Hit the Road

  • #2
    Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

    > Leaving KCC enabled AND Bridging of All Site Links enabled has the same result as just creating 1 single SiteLink displaced in a backbone topology with all 500 sites put inside this single SiteLink.

    Not so. The hub-spoke topology (just one hub?) make sure that all branches will create connection objects to the hub, and vice versa. The bridge-all-she ite-links setting makes it possible to create co's between branches IF the hub is down. I admit I would have disabled that setting with such a simple topology to exclude accidents.

    If you put all sites in a single sitelink, the resulting topology is onpredictable (at least, undocumented). The chances of it generating the correct hub-spoke topology is basically zero, of course.

    I would definitely leave the KCC on, unless I absolutely had to disable it. Consider: the fewer manual (scripted!) configuration, the better. For such a simple topology, the ISTG will probably not waste too much time. You can increase KCC logging to see how much time a KCC cycle takes. You probably can also see it in the taskmanager.

    > is it really useful / frequent behaviour, the practice of disabling KCC from generating inter-site connectors for Large Enterprises?"

    With W2003, yes. Push it to the limits.

    Another interesting question: did they optimize DNS to make sure that branche offices will never log on to each other?

    Comment


    • #3
      Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

      Originally posted by wkasdo
      Another interesting question: did they optimize DNS to make sure that branche offices will never log on to each other?
      If site's DCs are down the client can hit any DC in the enterprise - in this case the DNS will not be able to use the sort-order feature and can give any DC in the enterprise at random.
      Guy Teverovsky
      "Smith & Wesson - the original point and click interface"

      Comment


      • #4
        Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

        If site's DCs are down the client can hit any DC in the enterprise - in this case the DNS will not be able to use the sort-order feature and can give any DC in the enterprise at random.
        That's not what I meant. I referred to the possiblity to not publish certain SRV records anywhere but in its own site. So what you do is to have the hub site publish generally, so that ALL clients can find the hub, but publish branch DC's only locally.

        Comment


        • #5
          Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

          Originally posted by wkasdo
          So what you do is to have the hub site publish generally, so that ALL clients can find the hub, but publish branch DC's only locally.
          Oh !!! I knew I was missing something...
          Guy Teverovsky
          "Smith & Wesson - the original point and click interface"

          Comment


          • #6
            Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

            Originally posted by wkasdo
            > Not so. The hub-spoke topology (just one hub?)
            Yes, just one Hub

            Originally posted by wkasdo
            make sure that all branches will create connection objects to the hub, and vice versa. The bridge-all-she ite-links setting makes it possible to create co's between branches IF the hub is down.
            Sorry to tell you're wrong
            Or, at least, what I see now is that KCC is creating connectors between one branch and another branch, not only between branch and central hub. This is quite unexplainable.

            Originally posted by wkasdo
            I admit I would have disabled that setting with such a simple topology to exclude accidents.
            And that's what we usually do.


            Originally posted by wkasdo
            If you put all sites in a single sitelink, the resulting topology is onpredictable (at least, undocumented). The chances of it generating the correct hub-spoke topology is basically zero, of course.
            Yes, but the fact I am remarking is that currently, in this configuration, KCC is NOT creating hub-n-spoke connectors! It is creating a mesh topology. So that's where my doubts come from.

            Originally posted by wkasdo
            You can increase KCC logging to see how much time a KCC cycle takes. You probably can also see it in the taskmanager.
            That's a good point.

            Originally posted by wkasdo
            With W2003, yes. Push it to the limits.
            So we are not so crazy at the end

            Originally posted by wkasdo
            Another interesting question: did they optimize DNS to make sure that branche offices will never log on to each other?
            Well, this is an easy question, as you can imagine the only work you have to do to grant correct DC auth, is ensuring that sites, subnets and SRV records are correctly registered. You just need at least 1 DC+DNS at each site (and that's the current configuration) and subnets correctly mapped in AD Sites.
            Luke and Max Hit the Road

            Comment


            • #7
              Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

              > Or, at least, what I see now is that KCC is creating connectors between one branch and another branch, not only between branch and central hub. This is quite unexplainable.

              That will only happen if the central hub is not responding. Possible causes:
              - DC overload
              - WAN overload
              - blocked ports

              I'd pick a site that is creating 'wrong' connection objects, and start looking for trouble.

              > Well, this is an easy question, as you can imagine the only work you have to do to grant correct DC auth, is ensuring that sites, subnets and SRV records are correctly registered.

              You can do better than just this default config; see my previous post, and more in particular: the branch office deployment guide for Active Directory.

              Comment


              • #8
                Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

                > It is creating a mesh topology

                One more thought: are perhaps all sites still in default-first-site-link? That would nicely explain it.

                Comment


                • #9
                  Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

                  >You can do better than just this default config; see my previous post,
                  >and more in particular: the branch office deployment guide for
                  >Active Directory.

                  I think you refer to this: "I referred to the possiblity to not publish certain SRV records anywhere but in its own site. So what you do is to have the hub site publish generally, so that ALL clients can find the hub, but publish branch DC's only locally"

                  I do not think it is a good practice, you loose fault tolerant features
                  BTW, if link briges are on, and obviously routing is on, why should I disable one branch to contact another's branch DC in case needed?
                  If KCC is correctly configured, and costs are correctly set, whenever one branch's client need to find a DC and it cannot find its site's DC, it will ask for central HUB dc; then if central hub DC is down, it will try to contact another branch DC. What's wrong with this?
                  Luke and Max Hit the Road

                  Comment


                  • #10
                    Re: Disabling KCC for Large Enterprises: a phylosophical view [Long post]

                    > I do not think it is a good practice, you loose fault tolerant features

                    Not really. If the local branch is down AND the hub is down, then wtf is going on? Also, to have triple redundancy you need to do something clever with client DNS settings. Where will they point?

                    > it will try to contact another branch DC. What's wrong with this?

                    WAN lines to branches are not usually equipped to bear the traffic load.

                    Comment

                    Working...
                    X