Now the way you told me your interview question, it involved the server crashing at 6:30pm when you had a 7pm dinner-date with a super-model... when did your blog get all politically correct?

Nice article, Brian. In reference to the whole Schema master role - I'm HUGELY in favor of making that role completely and totally "Install when needed, de-install when done".

Make no mistake - this would have saved me many cross-forest migration hours, as the folks that couldn't have figured out how to install the role were typically the same folks who fire-bombed their schema.

Well, since I got dinged for competitive urgency on my last review (whatever the hell that is), I guess for me the right answer is never do I get to go back to sleep. But then I don't have 150 DCs either.

Seriously, nice article Brian. I asked my team the question, and every one said PDCE. Makes me feel all warm inside :-)

I think the person who wrote you the email argument kind of falls down based on its own info. If the forest roles aren't that important so what if they are on the box with the domain roles and that box fails. If looking at critical work load, it doesn't do anything to increase it because as he and you indicated, you can leave it for a while, possibly even a long while.

I have never been a fan of spreading out the roles, when you put them together you don't have an "all your eggs in one basket" situation like some people like to say because, IMO, they aren't all eggs. Or maybe they are all eggs but not all raw eggs, some are hardboiled and some are plastic. Spreading out the roles just means you have to keep track of them all over the place. If you have them all on one server (with maybe IM as exception for GC reasons), you know right where they are.

In a large org, it is generally a good idea to keep RID and PDC together especially if you have legacy systems or, and this is important, newer systems that operate like legacy systems because that is how the developers knew how to write the code. I have seen apps that used LDAP but used PDC Location API calls to find the PDC to contact for the LDAP calls. They had no idea that there were other better ways of locating domain resources because they did a simple upgrade of their old NT4 app and tried to change as little as possible.

When I did ops and we ran AD just for NOS, the PDC was the only DC I would run for. Fortune 5 company I was lead for had too many things that used PDC based functionality. Once we added Exchange 2K, I would run for PDCs and all DCs in the Exchange sites.

On the time point... Obviously that is just for the forest root domain but I always set all DCs that could potentially become the PDC for the root domain to use the same AD-external time source. One less thing to think about when moving the role.

Alright, AD oldtimers quiz. Do you remember what FSMO _originally_ stood for? And why it was so whacked dev had to change it?

Floating Single Master Operations was the original name.  I don't know the specifics as to why it was changed but I think it is pretty obvious.  Don't really want them to float -- rather have them flexible.

PingBack from http://jeftek.wordpress.com/2006/09/10/fsmo-roles-if-you-could-only-save-one-which-would-it-be/