Inline ...
--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com
-----Original Message-----
From: [EMAIL PROTECTED]
Sent: Tuesday, February 14, 2006 7:57 PM
To: ActiveDir@mail.activedir.org
Cc: Send - AD mailing list
Subject: RE: [ActiveDir] Script to transfer FSMO roles.
>> 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.
- what's not true .. yes it is? :o)
- schema FSMO, domain naming FSMO -- state? I guess this is a matter of
perspective then ... personally, I don't consider an entire partition to be
state (or a crossRef or an NC head or ...), they are IMO the result of a
mostly controlled, single-mastered update not the state of the role holder
that introduced the change(s). State, in this context, defines something
particular to the role that indicates its position within a sequence of
events ... or knowledge of what it did last time ... or information relevant
to "what to do next" ... or ...
>> 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
- nod, I imagine many have a sadly similar experience.
>> and which data each is responsible for, I do not recommend seizing any
roles except one.
- neither do I ... but the need does arise (seizing I mean). That's not to
say I advocate scripting it (per my original post) though scripting a
transfer has, to date, been a non-issue.
>> It is not good to conflict the NCs, hard to undo, and even worse to
conflict the schema.
- good point, most (including the relatively inexperienced) are aware of
this (I hope).
>>If you're a novice, here is what you should remember, IMNHO
>> - Only the PDC is safe for seizing.
- don't agree, for example -
: think impact on BDCs ... they do still exist
: timesync; most will forget the necessary reconfiguration
: AOB
>> - The infrastructure master is probably safe (I've never
>> really thought it through enough to vouch for it).
- I've seized it often (under test conditions) and occasionally in
production = no problems or observed side effects of any kind.
- 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.
- the seizure approach is odd IMO though the transfer approach makes sense
(at least to me). I would also very much like to see all necessary related
directory mods. made server-side.
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/
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/
