There was a bit of a debate on Active Dir Org recently which is a rehash of a debate that comes up on a fairly regular basis concerning whether or not you should transfer FSMO roles when doing domain controller maintenance.
I come down quite unforgivingly on the side of yes, transfer the roles. Part of the reasoning is that I think it is stupid to have to seize the roles later in case something got screwed up especially when transfering the roles is such a trivial thing. It is a script or batch file that takes less than 15 seconds to run in most cases yet can save you considerable amounts of pain and hard decisions.
Additionally, a seize is not as innocuous as a transfer. If it were, we wouldn’t have two operations with one only being used as a last recourse, I mean think about it… Why would you purposely put yourself in a position that you may have to do it when you can so easily avoid it except for cases of outright unexpected system failure out of the blue.
Here are the words on the topic posted to Active Dir Org in the past by someone with a pretty good understanding of what is going on and intimate knowledge of some of the issues. It is Brett who used to work on the DS Platform team and wrote all of the brilliant parts of RepAdmin. 😉
That is not true, the schema and naming FSMOs also have extensive state
that is sensitive and critical, however the frequency of the updates is
significantly less, and thus less likely to cause an issue.Having personally been on PSS cases for people who’ve f-d up thier forest,
because they didn’t understand the concept of the F-Single-Master-O, and
which data each is responsible for, I do not recommend seizing any roles
except one. It is not good to conflict the NCs, hard to undo, and even
worse to conflict the schema.If you’re a novice, here is what you should remember, IMNHO
       – Only the PDC is safe for seizing.
       – The infrastructure master is probably safe (I’ve never
         really thought it through enough to vouch for it).
       – Seizing any other role is a complicate process that will require
         learning of some DS internals, and a few steps.The process for seizure, should be
       A) Understand what data that FSMO owns, and think carefully if
          ANYONE has updated that data on a DC that is somehow
          unavailable to the forest at this moment, and could be brought
          back to the forest?
           a. If it could be brought back, you must then decide to not
              bring it back _EVER_, destroy the DC before seizure. Or
              bring it back and let it’s changes replicate out.
       B) By seizing you can break the F-Single-Master-O model, and
          effectively have the potential to multi-mastered the data on
          more than one DCs, conflicting the data in a very bad way…
       C) Run repadmin /syncall
          to guarantee your forest has a consistent view of the data in
          question you want to seize.
       D) Finally perform the seizure, don’t use a script, don’t temp
          yourself with it. Use ntdsutil / dsmgmt.
       E) Finally, evaluate what you did to cause this seizure? Did you
          take down a box without properly demoting it? Institute an
          IT policy that allows for that mistake never to happen again,
          seizures should not be a part of any IT operation, unless you
          experienced critical hardware failure.Dean is right, it’s the wrong place to fixup RID seizure in ntdsutil
though, but I also think an LDAP modification performing a seizure, and a
LDAP control for performing the more common transfer is ass backwards as
well, so what do I know.I wrote this mail in a hurry, so didn’t proof it, probably mistakes …
BrettSh [msft]
Building #7 Garage Door Operator
 That was part of an overall thread from
http://www.mail-archive.com/activedir@mail.activedir.org/msg39683.html
So the next thing people will say is… transfering roles is a pain, you have to open like a zillion gooeys and click through a bunch of menu’s or you have to type in a ton of really long commands in NTDSUTIL…. Not true. A simple batch file will do it or if you want to do some fancy checking of what machine is being specified or maybe have autodetermination of what machine to move roles to (maybe based on an attribute setting on the DC objects) you can write a full script to do most anything in probably an hour.
In the meanwhile here are two simple batch files.
The first is to transfer all of the roles present in a root domain to one server
TransRootFsmo.cmd (all one line)
NTDSUTIL ROL CONN “CONN TO SER %1” Q “Transfer domain naming master” “Transfer schema master” “Transfer infrastructure master” “Transfer RID master” “Transfer PDC” Q Q
The second is to transfer all of the roles present in a non-root domain to one server
TransDomFsmo.cmd (all one line)
NTDSUTIL ROL CONN “CONN TO SER %1” QÂ “Transfer infrastructure master” “Transfer RID master” “Transfer PDC” Q Q
As you can see, the batch files are extremely complex and difficult and makes it completely clear why someone wouldn’t transfer the roles prior to doing work on a DC…
About the best argument I have heard for not transferring roles is that seizing roles is so easy… So why go through the extra work (the whole 15 seconds of it…) instead of just worrying about it later. Easy or not, there could be repercussions and honestly it takes a more informed individual for a seize action than a transfer. I would let lower level AD admins transfer roles but seizing would make me nervous. Plus seizing in general is more complex and involved, I refer you back to Brett’s comments on the topic.
 joe
Â
Ex: Elapsed time – 2.2 seconds for script run. .6 seconds for script load. Total: 2.8 seconds…
[Sat 08/19/2006 11:21:36.83]
G:\Temp\fsmo>dumprootfsmo r2dc2
[Sat 08/19/2006 11:21:37.43]
G:\Temp\fsmo>NTDSUTIL ROL CONN “CONN TO SER r2dc2” Q “Transfer domain naming master” “Transfer schema master” “Transfer infrastructure master” “Transfer RID master” “Transfer PDC” Q Q
NTDSUTIL: ROL
fsmo maintenance: CONN
server connections: CONN TO SER r2dc2
Binding to r2dc2 …
Connected to r2dc2 using credentials of locally logged on user.
server connections: Q
fsmo maintenance: Transfer domain naming master
Server “r2dc2” knows about 5 roles
Schema – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Domain – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
PDC – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
RID – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Infrastructure – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
fsmo maintenance: Transfer schema master
Server “r2dc2” knows about 5 roles
Schema – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Domain – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
PDC – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
RID – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Infrastructure – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
fsmo maintenance: Transfer infrastructure master
Server “r2dc2” knows about 5 roles
Schema – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Domain – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
PDC – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
RID – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Infrastructure – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
fsmo maintenance: Transfer RID master
Server “r2dc2” knows about 5 roles
Schema – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Domain – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
PDC – CN=NTDS Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
RID – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Infrastructure – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
fsmo maintenance: Transfer PDC
Server “r2dc2” knows about 5 roles
Schema – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Domain – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
PDC – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
RID – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
Infrastructure – CN=NTDS Settings,CN=R2DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=loc
fsmo maintenance: Q
NTDSUTIL: Q
Disconnecting from r2dc2…[Sat 08/19/2006 11:21:39.63]
G:\Temp\fsmo>
That was a great thread and I’ll give Deji credit for holding his ground. We never transferred the roles in the past but we may start after reading this.
A couple of other things I took away. The first was from Brett’s quote
“If you’re a novice, here is what you should remember, IMNHO
– Only the PDC is safe for seizing…”
I’ve only ever seized roles in a test lab. Luckily (knock on wood) non of our FSMO holders have gone down. We have had DC’s go down hard due to hardware issues but that only meant metadata cleanup no seizing. I wonder if Brett recommends opening a PSS ticket if we have to seize in the live environment. I may email him about that. It’s better to be safe than sorry.
The second thing I took away is now every time I see a post from you I can’t help but think of Jeff Bridges in The Big Lebowski because he also loved those White Russians…. DUDE!!
Hmm… I think you have to give consideration to how large your forest is, making sure the changes are replicated throughout. I’m a little surprised to hear that people don’t think it is a big deal. It is not really the time/effort it takes to do it, but if your AD is healthy enough to replicate all the changes.
Mike: I am not sure if Brett would recommend that or not, if you have PSS on tap though it is always a good way to cover your bases. Just be smart where you have the rolls and keep them off machines where you are making changes and you should generally be good. You know which machines are more troublesome than others in your environment. 🙂
AntKnee: For the seize or the transfer? If you AD isn’t healthy enough to replicate either of the changes you are in deep trouble already and this is just exposing it which is good. For replication a FSMO move is one to two attributes updated on single objects. If you moved all five roles you are changing like 7 small attributes.
Did you really have to call the alternate idea “stupid”? Is that the only adjective available for describing a position that you think is inferior to your position?