Quick FMSO question

elaverick1981

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?

Find more posts tagged with

Comments

royal

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.

elaverick1981

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

royal

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.

elaverick1981

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.

meadIT

elaverick1981 wrote: »

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.

dynamik

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.

elaverick1981

dynamik wrote: »

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.

elaverick1981

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?

dynamik

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.

elaverick1981

dynamik wrote: »

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

royal

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.

hustlin_moe20

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

dynamik

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.

hustlin_moe20

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.

dynamik

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.

rossonieri#1

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?

Graham_84

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?

stupidboy

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.

dynamik

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.

stupidboy

dynamik wrote: »

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.

elaverick1981

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)

rossonieri#1

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?

meadIT

rossonieri#1 wrote: »

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.

NetAdmin2436

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