+ Reply to Thread
Results 1 to 25 of 25
  1. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #1

    Default Quick FMSO question

    How do you implement redundancy in FSMO roles? Is that the point where you need to Cluster your DC's in a domainlet? What about in the real world, is that what people actually do or do you just hope that your IT team is proactive enough to seize roles or actively transfer away from failing DC's?
    Last edited by elaverick1981; 01-12-2009 at 06:31 PM. Reason: Cus I just can't seem to type properly tonight...
    Reply With Quote Quote  

  2. SS -->
  3. New Member royal's Avatar
    Join Date
    Jul 2006
    Location
    Chicago, IL
    Posts
    3,373
    #2
    You don't cluster DCs. FSMO are not redundant. If you need to shut down a DC for a while, you transfer your FSMO role. If your FSMO role is located in a Datacenter that was hit by a meteor, then you sieze the role.
    Reply With Quote Quote  

  4. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #3
    Ok cool. I remeber reading something in the 293 exam cram book about clustering DC's but having had a look around the advice seems to be "you can... but don't... ever".
    Maybe I'm just getting paranoid reading about so many scenarios with single points of failure
    Reply With Quote Quote  

  5. New Member royal's Avatar
    Join Date
    Jul 2006
    Location
    Chicago, IL
    Posts
    3,373
    #4
    And just an FYI, if you thought you could cluster DCs, you have A LOT to learn about how AD works and are nowhere near ready for an exam on Wednesday. Just figured I'd give you my 2 cents about your other post. <1 week is not nearly enough time without real world experience.
    Reply With Quote Quote  

  6. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #5
    When so much of AD is geared around protecting the infrastructure it just seemed strange that the FSMO roles were truely unique. As I said the last of the study resources I was reading made reference to clustered DC's but it neglected to point out that these were just for supporting the infrastructure of the cluster.
    As I said you can cluster the DC's, but I see that it offers no actual failover support.
    Last edited by elaverick1981; 01-12-2009 at 06:59 PM.
    Reply With Quote Quote  

  7. Senior Member meadIT's Avatar
    Join Date
    Aug 2006
    Location
    Central VA
    Posts
    579

    Certifications
    Ran out of room :(
    #6
    Quote Originally Posted by elaverick1981 View Post
    When so much of AD is geared around protecting the infrastructure it just seemed strange that the FSMO roles were truely unique. As I said the last of the study resources I was reading made reference to clustered DC's but it neglected to point out that these were just for supporting the infrastructure of the cluster.
    As I said you can cluster the DC's, but I see that it offers no actual failover support.
    If I'm reading that article correctly, that scenario doesn't have clustered DC's, it only has a cluster node(s) that also has a DC as one of its roles. Normally, in a cluster, you specify one name/address for the cluster and it could go to any one of the nodes. In the linked scenarios, you aren't actually using the cluster name/address, you would only use the name/address for the specific hosts that hold the DC role.
    Reply With Quote Quote  

  8. Senior Member
    Join Date
    Mar 2007
    Posts
    12,308
    #7
    That article is about setting up clustering where the nodes are also DCs. It's not clustering DCs the way you're thinking of it, which is why there is no failover.
    Reply With Quote Quote  

  9. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #8
    Quote Originally Posted by dynamik View Post
    That article is about setting up clustering where the nodes are also DCs. It's not clustering DCs the way you're thinking of it, which is why there is no failover.
    Yeah I see it's the difference between installing DC's for a cluster compared to clustering the DC's.
    Reply With Quote Quote  

  10. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #9
    So go on then, I've asked the question and already made myself look a fool, so I might as well find out the answer.
    Why is clustering FSMO components such a stupid idea? I appriciate the fact that it can't be done at the moment, at least not in a meaningful way.
    However...
    AD is a transactional database, I'm not talking about replacing Multimaster replication with a Load-balancing cluster, rather augmenting FSMO with log shipping aware fail-over clustering.
    I also appriciate why Operations Masters are single entities within the domain or forest the serve, and why latency of communication would also totally screw up AD replication, but I can't for the life of me see why (in theory at least) FSMO clustering shouldn't be possible if the DC's were made cluster aware and if you could guarrentee the latency in small site local clusters?
    Other realtime transactional databases seem to support clustering so why can't AD?
    Reply With Quote Quote  

  11. Senior Member
    Join Date
    Mar 2007
    Posts
    12,308
    #10
    The FSMO roles aren't as critical as things like Exchange or SQL. The PDC emulator is usually the only one that might cause noticeable problems.

    Schema: replicates schema modifications
    Domain naming: can't rename or create new domains.
    Infrastructure: manages cross-domain object references
    PDC emulator: very important for NT4, otherwise group policy changes and time synchronization
    RID: allocates in pools, so you shouldn't need more RIDs unless you create a large number of objects

    How long would a DC be down for? If it's critical, seizing the role is trivial.
    Reply With Quote Quote  

  12. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #11
    Quote Originally Posted by dynamik View Post
    The FSMO roles aren't as critical as things like Exchange or SQL. The PDC emulator is usually the only one that might cause noticeable problems.

    Schema: replicates schema modifications
    Domain naming: can't rename or create new domains.
    Infrastructure: manages cross-domain object references
    PDC emulator: very important for NT4, otherwise group policy changes and time synchronization
    RID: allocates in pools, so you shouldn't need more RIDs unless you create a large number of objects

    How long would a DC be down for? If it's critical, seizing the role is trivial.
    Ah ok, so what you're saying is cus the FSMO's only really come into effect when something has changed (such as account creation of group membership changes) it's only really likely to be the domain/enterprise admins who are affected rather than the end users. Its not that these couldn't have been written so they were clusterable, its just not actually all that important, unless you had some hideously complex AD structure in a constant state of flux.

    Looks like I was just going HA crazy then. Thanks
    Reply With Quote Quote  

  13. New Member royal's Avatar
    Join Date
    Jul 2006
    Location
    Chicago, IL
    Posts
    3,373
    #12
    PDC is also needed for 9x clients unless the Directory Services client is installed in which 9x clients can use any DC for passwords. Also, PDC emulator gets notified immediately of password changes so if something hasn't replicated throughout the environment, and someone enters a wrong password, PDC emulator is checked before refusing connection.
    Last edited by royal; 01-13-2009 at 12:28 AM.
    Reply With Quote Quote  

  14. Senior Member hustlin_moe20's Avatar
    Join Date
    Jun 2008
    Location
    Wichita, Kansas
    Posts
    225

    Certifications
    CISSP, MCITP:EA, MCSE:S, MCSA:S, ITILv3, Security+, Network+, A+, 2x-MCP, 4x-MCTS
    #13
    wouldn't it be easier to make a copy of your AD by making a system state backup instead of trying to cluster some DC's? what do you guys do in the real world? im not even a sys admin
    Reply With Quote Quote  

  15. Senior Member
    Join Date
    Mar 2007
    Posts
    12,308
    #14
    You should obviously have backups, but the entire purpose of things like clusters is to prevent any interruption in service. You could get by with a single domain controller and keep an up-to-date system state backup. However, if that went down, you'd be without a DC until you fixed it or reinstalled and restored your backup.
    Reply With Quote Quote  

  16. Senior Member hustlin_moe20's Avatar
    Join Date
    Jun 2008
    Location
    Wichita, Kansas
    Posts
    225

    Certifications
    CISSP, MCITP:EA, MCSE:S, MCSA:S, ITILv3, Security+, Network+, A+, 2x-MCP, 4x-MCTS
    #15
    Yes I know that much I was just saying keeping some backups is easier than clustering a DC which makes no sense. If you have extra DC's then one going down shouldn't be that big of a deal with a decent backup copy.
    Reply With Quote Quote  

  17. Senior Member
    Join Date
    Mar 2007
    Posts
    12,308
    #16
    If you have extra DCs, you won't need a backup copy because all the information will be replicated to the new machine after you promote it to a domain controller.
    Reply With Quote Quote  

  18. Coffee anyone? rossonieri#1's Avatar
    Join Date
    Jun 2003
    Posts
    800

    Certifications
    a few...
    #17
    dear royal and dynamik,

    i think elaverick has the point.
    its an interesting discussion. why cant FSMO or perhaps DCs be clustered?

    its been a long time ago since my MCSA 2000.
    i know that we dont cluster DCs - but, technologically - the question is why cant/dont?

    is it to keep a single DC NTDS.dit as a solid 1 man written?
    so the other writer wont disturb its content?

    or perhaps - you guys have any better idea?
    Reply With Quote Quote  

  19. Member
    Join Date
    Aug 2008
    Location
    Birmingham, UK
    Posts
    85

    Certifications
    MCSE 2003:M, MCSA 2003:M, MCTS, MCITP:EA, HyperV, SCVMM, QMMAD QMMEX
    #18
    I dont see how clustering dc's is even a possibility. For fault tolerance you would just have another dc? Am i just missing point? If you FSMO role holder fail then its not really an issue. Each Dc from memory can create about 500 objects from its own rid pool before needing a replenishment. If schema on the rarest instance needs to be modfied it can be seized on failure. Domain naming master is only really for creating new domains / trees and likewise can be seized of transfered. PDC emulator can cause group policy issues or time sync issues if it fails. Infrastructure similar to a gc will hold a replica of objects in other domain. I can see why they would need to be clustered or how. I can even see how they could be clustered. How KDC / Kerberos / intersite topology generator could work?
    Reply With Quote Quote  

  20. Senior Stupidboy stupidboy's Avatar
    Join Date
    Nov 2007
    Location
    UK
    Posts
    470

    Certifications
    What Ever+
    #19
    The clue is in the name Flexible Single Master Operations

    The best practices for FSMO role "failover" is to ensure that you have a DC with no roles assigned, which also is not a Global Catalog (to avoid issues when all DCs are not GCs). This standby should have direct replication with the role holder(s) so that it is as up-to-date as possible should you need to seize a role.

    Obviously, seizing roles is not something you are going to right out of the blocks, and in most cases reparing the current role holder is the best option. Where possible a migration is the best option, but this is not always going to happen.

    Know what the roles are for and how long you can live without them, this article was a great help for me Planning FSMO Roles in Active Directory hope it helps. There are other links at the bottom that cover overlapping areas.

    Hope this helps.
    Reply With Quote Quote  

  21. Senior Member
    Join Date
    Mar 2007
    Posts
    12,308
    #20
    Like I said here, there's just not a real need for it. AD has fault-tolerance built into it, and the things that aren't redundant, can easily be moved around. I don't think there's any technical limitations that prevent it, more that it just doesn't to be worth the time developing and complexity managing.
    Reply With Quote Quote  

  22. Senior Stupidboy stupidboy's Avatar
    Join Date
    Nov 2007
    Location
    UK
    Posts
    470

    Certifications
    What Ever+
    #21
    Quote Originally Posted by dynamik View Post
    Like I said here, there's just not a real need for it. AD has fault-tolerance built into it, and the things that aren't redundant, can easily be moved around. I don't think there's any technical limitations that prevent it, more that it just doesn't to be worth the time developing and complexity managing.
    I agree that there is little (read no) point, except where you have to show that you have made preparations (some non-technical managers worry way to much). As long as you know what will happen with a role off-line (not a great deal) at least you have all the facts. Understand that seizing a role means you should not bring the original server back online without first doing a clean install (oh how I love a good metadata clean-up at 03:00 in the morning that'll teach me for not testing the backups once a month)

    One of the companies that we do business with have taken this whole idea to a whole new level .... it is totally bonkers, over the top, superfluous and honestly it will never work in a million years but hey the customer knows best.
    Reply With Quote Quote  

  23. Senior Member elaverick1981's Avatar
    Join Date
    May 2008
    Location
    UK
    Posts
    161

    Certifications
    MCITP:EA, MCSE, MCSA, MCTS, MCP, 70-121, 70-134, 71-505
    #22
    Wow this one's developed legs hasn't it? The reason I had originally asked was because I had misunderstood who was really getting the benefits of the FSMO roles. I had assumed they were integral to AD operation at all stages rather than just being available in the event of changes to the directory (and fairly large ones at that). While it would probably not be beyond the wit of Microsoft Developers to add support for clustering of FSMO role holders, I suspect the reason they've not done it is to avoid having people new to the subject (as I was) trying to create unmanageablely complex setups.

    This is with the possible exception of the PDC in an NT4 mixed environment, but I think MS were trying to wean people away from NT4 even back in 2003. (Its completely gone in 2008 I see)
    Reply With Quote Quote  

  24. Coffee anyone? rossonieri#1's Avatar
    Join Date
    Jun 2003
    Posts
    800

    Certifications
    a few...
    #23
    wow ... turn out to be much interesting topic now
    ok, this is just for discussion guys,
    so no push - just enjoy the idea

    @ graham
    you brought plenty of valid points there :
    I dont see how clustering dc's is even a possibility.
    no offense, but i'm wondering why you did not see a possibility? at which side of DC to be exactly?

    For fault tolerance you would just have another dc? Am i just missing point?
    nope. you are very true that we only need another DC & wait for that db replications. and that was also the only fault-tolerant method provided.

    If you FSMO role holder fail then its not really an issue. Each Dc from memory can create about 500 objects from its own rid pool before needing a replenishment.
    if i'm not mistaken - a single DC can hold about 1000000 object attributes - am i correct?

    PDC emulator can cause group policy issues or time sync issues if it fails.
    now that is my previous point of view - i mean that was my one acceptable excuse why we dont cluster DCs.

    Infrastructure similar to a gc will hold a replica of objects in other domain. I can see why they would need to be clustered or how. I can even see how they could be clustered. How KDC / Kerberos / intersite topology generator could work?
    i dont see KDC would be a big problem - since you can log in to domain using member DC am i right?

    @ dynamik
    more that it just doesn't to be worth the time developing and complexity managing.
    i know and agreed. but - i think its the same complexity : clusters 2 DCs versus managing 2 non-clustered DCs. just imagine this way : you can create bigger transaction using 2 as a single unit like those web servers farm - right?
    Reply With Quote Quote  

  25. Senior Member meadIT's Avatar
    Join Date
    Aug 2006
    Location
    Central VA
    Posts
    579

    Certifications
    Ran out of room :(
    #24
    Quote Originally Posted by rossonieri#1 View Post
    if i'm not mistaken - a single DC can hold about 1000000 object attributes - am i correct?
    Active Directory can hold a million objects. What he was talking about was a normal DC can create that many objects by itself if the RID Master goes down. Each non RID Master DC gets an allotment of 750 to create new objects. When they get down to 250, they request more from the RID Master.
    Reply With Quote Quote  

  26. One Man Wolfpac NetAdmin2436's Avatar
    Join Date
    Mar 2008
    Location
    Minnesota
    Posts
    1,077

    Certifications
    AAS in Computer Networking, MCSE 2003, Network+, Security+, A+
    #25
    I think the simple and easy answer to why you can't Cluster FSMO roles is because Active Directory isn't designed that way. Similarly to why cars can't fly.....they are not designed to (at least not the practical ones they mass produce). There would be the possibility that conflicting data would be written by two or more DC's holding the same FSMO role and then they would try to replicate the conflicting data to each other. I would think data corruption would be prevalent and things in Active Directory would break, making it very hard to try and resolve.

    Understanding FSMO Roles in Active Directory
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks