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 <target-Seizer-DC> <NC-related-to-FSMO>
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
On Mon, 13 Feb 2006, Dean Wells wrote:
> Having chatted offline on this topic, I'm reminded that it's worth
> mentioning an exception pertaining to the RID FSMO. Extensive state is
> maintained for this particular role, state which is sensitive and requires
> modification when the role is seized. Unfortunately, these modifications
> are handled client-side by NTDSUTIL (a mistake in my opinion), as such, any
> manual seizure of the RID Master should be either conducted using NTDSUTIL
> (again, in a controlled manner) or supplemented with the necessary RID
> allocation pool modifications.
> --
> Dean Wells
> MSEtechnology
> * Email: dwells <mailto:[EMAIL PROTECTED]> @msetechnology.com
> <http://msetechnology.com/> http://msetechnology.com
>
>
>
> _____
>
> From: Dean Wells [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 13, 2006 9:06 AM
> To: Send - AD mailing list ([EMAIL PROTECTED])
> Subject: RE: [ActiveDir] Script to transfer FSMO roles.
>
>
> A few thoughts --
>
> I'm not entirely adverse to the idea of throwing commands at NTDSUTIL and
> seizing roles (and relying upon the mandatory pre-emptive transfer attempt)
> but I prefer not to perform such actions when the capability to trap
> failures within a sequence of events is beyond my control, e.g. the transfer
> fails and the seize continues without confirmation or regard for my input.
>
> Although I realize that your goal here is to seize a role, a single slip of
> the finger may inadvertently cause seizure to occur. I would suggest
> scripting the operation to _manually_ attempt a transfer first, trap the
> error and confirm your intention to proceed with a seize (remains achievable
> with NTDSUTIL). Of course, the implications of _not_ doing it this way are
> entirely dependent upon either or both the FSMO role in question and/or your
> particular infrastructure.
>
> The commands below outline an alternative approach for attempting a FSMO
> transfer of the domain naming master -
>
> admod -h <target DC FQDN> -b "" becomedomainmaster::1
>
> ... and the equivalent seizure -
>
> admod -h <target DC FQDN> -b cn=partitions,cn=configuration,dc=<root DN>
> fsmoroleowner::"<NTDS Settings DN of recipient DC>"
>
> ... e.g. -
>
> admod -h machine1.adcorp.lan -b
> cn=partitions,cn=configuration,dc=adcorp,dc=lan fsmoroleowner::"CN=NTDS
> Settings,CN=MACHINE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi
> guration,DC=ADCORP,DC=LAN"
>
> This approach provides more control at the expense of requiring slightly
> more specific knowledge of the directory.
> --
> Dean Wells
> MSEtechnology
> * Email: dwells <mailto:[EMAIL PROTECTED]> @msetechnology.com
> <http://msetechnology.com/> http://msetechnology.com
>
>
>
> _____
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto,
> Jorge de
> Sent: Monday, February 13, 2006 5:09 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Script to transfer FSMO roles.
>
>
>
> run the script on the DC that should host the FSMO role(s) or replace
> %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an
> argument. Make sure to adjust the script concerning the FSMO roles that
> should be seized/transfered
>
> --> Seize-Domain-FSMO-Roles.cmd
>
> NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize
> infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT
>
>
>
> --> Seize-Forest-FSMO-Roles.cmd
>
> NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize
> domain naming master" "Seize schema master" QUIT QUIT
>
>
>
> --> Transfer-Domain-FSMO-Roles.cmd
>
> NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer
> infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT
>
>
>
> --> Transfer-Forest-FSMO-Roles.cmd
>
> NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer
> domain naming master" "Transfer schema master" QUIT QUIT
>
>
> cheers,
> Jorge
>
> _____
>
> From: [EMAIL PROTECTED] on behalf of Simon Bembridge
> Sent: Mon 2006-02-13 10:52
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Script to transfer FSMO roles.
>
>
>
> Hi All,
>
> Can somebody point me in the right direction as to how to use a scripted
> solution for seizing the FSMO roles in case of a site failure?
>
> What we have is a W2K3 Domain, with two core sites and 60 branch offices. In
> the case of site 1 failing we want a procedure of activation a script so on
> the standby DC to seize the FSMO roles.
>
>
> Site 1
>
> 1 X DC Sch, Inf, DNM, PDC, GC
> 1 X DC RID, GC
>
> Site 2
>
> 1 X DC Standby FSMO role holder, GC
> 1 X DC GC
>
>
> Regards,
>
> Simon
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
