none
teamed network cards for domain controllers?

    Question

  • can someone help me to resolve a debate we have: my colleage states that domain controllers (in our case Win2003SP2) should "not" have their network cards teamed for high availability (via HP's NIC teaming software).? I've not heard of this and cannot Bing/Google anything like this. I'm under the impression that a domain controller "should" have it's gigabit NICs teamed to make sure that directory services are highly available.
    any information on this would be great. thanks...
    Peter A. Berger Jr.
    Thursday, October 08, 2009 8:27 PM

Answers

  • Fault Tolerance and Network Teaming

     

                    Anyone who has called Microsoft for help with a networking problem has likely heard the question: "Are you using network teaming?" I have often heard this referred to by Microsoft's customers as a "quick out" or an excuse that Microsoft was looking to pass the responsibility on to someone else. As someone that has been on both ends of the phone, and at the highest escalation point within Microsoft's Network queues I can tell you that it is a question born of wisdom and tempered with experience. While working the phones at Microsoft, supporting the largest and most critical systems in the US it was rare to ever get a call about the same problem more than once. Even more rare was for everyone on our group to get the same calls, and have the same experiences. I recall it happening when we fought the blaster worm, and when Microsoft's "Scalable Networking Pack" was released with 2003 SP2. These were bad, but a few months went by and except for a few straggles the phone calls stopped, the world got wise to the issue and the problem was resolved. I was amazed though to experience 1-3 calls a week with network issues CAUSED by network teaming. I could not help but be blown away by the irony of a program meant to avoid network failure so often causing it. I talked to colleagues, (of which I have found no better single source in the industry than at Microsoft), and found that even the old timers having more than 15 years with the company had the same stories of problems caused by networking teaming as we are constantly experiencing today. I am amazed that an industry as wise and agile as the computer industry has been (and is), has stuck with such a poor technology. I always asked my customers as the called with problems, usually critical ones, "What is teaming these network cards getting you". Almost unanimously the answer would come fault tolerance, to which I would reply rhetorically "How often do you NICs or Switches fail and how often has teaming caused network failure?" In my opinion, it is unforgivable for an application to constantly cause the problem that it is written to avoid. It should cause pause and reflection as to whether the technology is well suited for its function, whether it is just written poorly or if all of its implementations have similar problems. Technology today is beyond network teaming. There are far better methods of providing fault tolerance with manual and automatic failover. Most application writers have taken into consideration fault tolerance at the service level superseding anything that network teaming offers, so that network teaming should be a dead technology, because it is killing us.

                   
                    Finally, if you are considering using network teaming, or have had reason to reconsider its use, maybe these questions will help your assessment:

     

                    What is my goal with using network teaming?

                    Can I gain Availability through use of a more capable NIC card?

                    How often have my NIC cards failed?

                    When NIC cards have failed were they the only failure, or was it in conjunction with a Motherboard or other failure causing the service to be unavailable?

                    What are my needs for uptime for these services?

                    Would a manual failover (the simplest of options) be viable for this service?

                    What options for automatic failover do I have (since most applications can have multiple providers through configuration)?

     

                    One other note to add. While working on the phones at Microsoft, and later as a consultant to large and federal organizations, I found one thing that seemed to be true most of the time. When a problem occurred, it was rarely the OS itself, but something unnatural to its processes. Simplicity and minimalism is really one of the keys to a healthy server and environment. Often it is necessary to introduce other applications and services, but I do not think near as often as we do.

    Note: MSFT does not support network teaming, because they do not own the software that provides it. In certain instances though, like with OCS, they flat out will not support OCS if teaming is enabled on the server.

    Note2: I realize my comments above are very general, and so I want to apply these to this exact question. When I consider AD and how to make it fault tolerant, I cannot help but realize that the protocols, clients and services that make up Directory Services, are beautifully fault tolerant. In most cases, the loss of any one DC would not greatly affect the user's ability to authenticate to a computer or service within the domain. Even more, Directory services is inherently so fault tolerant that it can still function with the loss of a major part of the servers that make it up.



    Don't forget to give credit where credit is due, vote this as helpful if it helped you.
    Friday, October 09, 2009 9:55 PM
  • As far as I recall, Microsoft in general does not support teamed network adapter configurations in load balancing mode. Note that this does not mean that such configuration won't be working - it simply implies that if you run into problems and you call PSS, you will likely be asked to break the team as part of troubleshooting process.

    hth
    Marcin

    Thursday, October 08, 2009 10:01 PM
  • This is NOT a recommendation. This is a decision you need to make based on your individual circumstances and with full understanding of its implications - as well as sufficient level of testing that will give you enough confidence to proceed. Note that teaming solutions are dependent on hardware and implemented using third-party drivers - so you would want to also check with the vendor...

    hth
    Marcin
    Friday, October 09, 2009 12:02 PM

All replies

  • As far as I recall, Microsoft in general does not support teamed network adapter configurations in load balancing mode. Note that this does not mean that such configuration won't be working - it simply implies that if you run into problems and you call PSS, you will likely be asked to break the team as part of troubleshooting process.

    hth
    Marcin

    Thursday, October 08, 2009 10:01 PM

  • Hi

    Yep, I will go with Marcin. For the last week we have faced some problem in servers, after braking the teaming and reteaming has been solve the issue.

    So that it’s better not to use teamed network cards for domain controllers.

     

    Regards


    Rajesh J S
    Thursday, October 08, 2009 10:15 PM
  • Hi,

    My vote too for the same. Network Teaming on Domain Controller is not recommended at all. You may run into a lot of Name Resolution, Network related issues which may break a lot of things in AD like Replications, Trusts, DNS etc.

    There are cases where Network Teaming on DC works seamlessly for months but again that's one out ten cases. And yes if you call Microsoft in such cases then at the end you will probably have to break it anyways. I myself have been on that place telling customers to break it for testing purposes and ultimately not to use it.

    Thanks,
    Nitin
    Thursday, October 08, 2009 10:59 PM
  • What about just simple primary and secondary network cards -- one fails, the other takes over -- no load balancing. Here's the exact text from the teaming application:

    "Network Fault Tolerance only (NFT) with Preference Order. NFT provides the safety of an additional backup link between the server and hub/switch. NFT is implemented with a Primary adapter and a Secondary (backup) adapter(s). During normal operations, if the Primary adapter fails, the link to the Secondary adapter automatically takes over. The user sets the priority of the adapters relative to each other within the team. The priority of the adapters is an additional consideration when determining the Primary adapter."

    Seems plausible?

    Peter A. Berger Jr.
    Friday, October 09, 2009 12:50 AM
  • Peter,
    as indicated earlier, I'd stay away from load balanced configuration. Network failover option is rather common - so you might want to give it a try - although my understanding is that the supportability caveat still aplies...

    hth
    Marcin
    Friday, October 09, 2009 1:10 AM
  • Hi,

    is this recommendation still valid for Windows 2008 domain controller?
    We also have this request especially for domain controllers in remote sites with no local administrator on side. If a network cards should fail, there is no other possibility than to give local access to the remote administrator to configure the second network card and this is not very nice in case of security and role segregation.

    Thanks
    omaino
    Friday, October 09, 2009 11:19 AM
  • This is NOT a recommendation. This is a decision you need to make based on your individual circumstances and with full understanding of its implications - as well as sufficient level of testing that will give you enough confidence to proceed. Note that teaming solutions are dependent on hardware and implemented using third-party drivers - so you would want to also check with the vendor...

    hth
    Marcin
    Friday, October 09, 2009 12:02 PM
  • Fault Tolerance and Network Teaming

     

                    Anyone who has called Microsoft for help with a networking problem has likely heard the question: "Are you using network teaming?" I have often heard this referred to by Microsoft's customers as a "quick out" or an excuse that Microsoft was looking to pass the responsibility on to someone else. As someone that has been on both ends of the phone, and at the highest escalation point within Microsoft's Network queues I can tell you that it is a question born of wisdom and tempered with experience. While working the phones at Microsoft, supporting the largest and most critical systems in the US it was rare to ever get a call about the same problem more than once. Even more rare was for everyone on our group to get the same calls, and have the same experiences. I recall it happening when we fought the blaster worm, and when Microsoft's "Scalable Networking Pack" was released with 2003 SP2. These were bad, but a few months went by and except for a few straggles the phone calls stopped, the world got wise to the issue and the problem was resolved. I was amazed though to experience 1-3 calls a week with network issues CAUSED by network teaming. I could not help but be blown away by the irony of a program meant to avoid network failure so often causing it. I talked to colleagues, (of which I have found no better single source in the industry than at Microsoft), and found that even the old timers having more than 15 years with the company had the same stories of problems caused by networking teaming as we are constantly experiencing today. I am amazed that an industry as wise and agile as the computer industry has been (and is), has stuck with such a poor technology. I always asked my customers as the called with problems, usually critical ones, "What is teaming these network cards getting you". Almost unanimously the answer would come fault tolerance, to which I would reply rhetorically "How often do you NICs or Switches fail and how often has teaming caused network failure?" In my opinion, it is unforgivable for an application to constantly cause the problem that it is written to avoid. It should cause pause and reflection as to whether the technology is well suited for its function, whether it is just written poorly or if all of its implementations have similar problems. Technology today is beyond network teaming. There are far better methods of providing fault tolerance with manual and automatic failover. Most application writers have taken into consideration fault tolerance at the service level superseding anything that network teaming offers, so that network teaming should be a dead technology, because it is killing us.

                   
                    Finally, if you are considering using network teaming, or have had reason to reconsider its use, maybe these questions will help your assessment:

     

                    What is my goal with using network teaming?

                    Can I gain Availability through use of a more capable NIC card?

                    How often have my NIC cards failed?

                    When NIC cards have failed were they the only failure, or was it in conjunction with a Motherboard or other failure causing the service to be unavailable?

                    What are my needs for uptime for these services?

                    Would a manual failover (the simplest of options) be viable for this service?

                    What options for automatic failover do I have (since most applications can have multiple providers through configuration)?

     

                    One other note to add. While working on the phones at Microsoft, and later as a consultant to large and federal organizations, I found one thing that seemed to be true most of the time. When a problem occurred, it was rarely the OS itself, but something unnatural to its processes. Simplicity and minimalism is really one of the keys to a healthy server and environment. Often it is necessary to introduce other applications and services, but I do not think near as often as we do.

    Note: MSFT does not support network teaming, because they do not own the software that provides it. In certain instances though, like with OCS, they flat out will not support OCS if teaming is enabled on the server.

    Note2: I realize my comments above are very general, and so I want to apply these to this exact question. When I consider AD and how to make it fault tolerant, I cannot help but realize that the protocols, clients and services that make up Directory Services, are beautifully fault tolerant. In most cases, the loss of any one DC would not greatly affect the user's ability to authenticate to a computer or service within the domain. Even more, Directory services is inherently so fault tolerant that it can still function with the loss of a major part of the servers that make it up.



    Don't forget to give credit where credit is due, vote this as helpful if it helped you.
    Friday, October 09, 2009 9:55 PM
  • Jared -- thank you for the well-crafted (and technical) response to my query. It's good to see that MS employees/MVP's/IT experts, etc. do monitor these forums and help us all out. It can only help us IT people in the end. It is very helpful and definitely instills faith in MS; their products and their support teams. thanks!
    Peter A. Berger Jr.
    Friday, October 09, 2009 10:41 PM
  • That's what i call experience. Very well composed and explained Jared :)

    Thanks,
    Nitin

    Friday, October 09, 2009 11:32 PM
  • Hello Jared, 

             Very Well Drafted.

    Thanks

     

     


    http://technetfaqs.wordpress.com
    Saturday, October 10, 2009 6:52 AM
  • here is a KB for your reference
    http://support.microsoft.com/kb/278431
    Thursday, December 31, 2009 1:42 AM