logo       

RE: FSMO role transfer: msg#01214

Subject: RE: FSMO role transfer
Real admins do what they need to do, however works for them.  I use GUI
tools when available & convenient, and cmdline when convenient.
Generally, I would prefer to not have any GUI at all on most of my
servers, but that's just me.

Derek

-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rocky Habeeb
Sent: Wednesday, November 30, 2005 3:18 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer

Susan,

"THANK YOU
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!
!!!!!!!!!!!"

There are a >LOT< of people on this list that do not believe that real
Admins use the GUI.  Some believe that you're not a real Admin if you
do.  I do.  I have to.  I can't allocate time to learn scripting right
now because I'm overworked as is.  I'll just leave it at that.

RH
______________________________________________


-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]On Behalf Of Susan Bradley,
CPA aka Ebitz - SBS Rocks [MVP]
Sent: Wednesday, November 30, 2005 4:09 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] FSMO role transfer


<stupid question alert>

If the task is that trivial
If the benefit is so great
Why isn't it part of the AD snap ins as a one button task?

<sincerely, who needs scripting when you can ask for a gui/wizard or
button instead>

David Adner wrote:
> I'm not debating the effort it takes to make the change.  I'm saying I
don't
> see the point in devoting whatever amount of effort it takes for 
> something that's going to provide benefit only, IMO, an extremely rare

> case.  And if that case happened, the corrective action is also a 
> trivial process.  And again, I'm not saying I don't see your point; I
just don't agree with it.
>
>
>> -----Original Message-----
>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta 
>> Nathaniel V Contractor NASIC/SCNA
>> Sent: Wednesday, November 30, 2005 12:32 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> Subject: RE: [ActiveDir] FSMO role transfer
>>
>> That process is trivial in itself.  It does not take much to transfer

>> the roles before you conduct maintenance on a server.  Why not do it?

>> It will save you cleaning up metadata after you seize a role of a 
>> failed operations master.  Sounds like a stitch in nine saves time 
>> concept to me.  I do not intend on taking every proactive measure 
>> either, but when it comes to the small and quickly implemented 
>> measures that could save plenty of time, I try to utilize all of them

>> available.
>>
>> Is that agreeable?
>>
>> Nathaniel Vincent Bahta
>>
>> -----Original Message-----
>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
>> Sent: Wednesday, November 30, 2005 1:24 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> Subject: RE: [ActiveDir] FSMO role transfer
>>
>> Any proper maintenance plan has a backout plan and a recovery plan, 
>> so I am preparing for the possibility of an unexpected problem.  If 
>> I'm pulled into a dark room because something goes wrong then I 
>> should feel confident I'll leave that room with my hide mostly 
>> intact; it may be slightly singed, but I can live with that.  If 
>> management isn't the reasonable type then that's a different issue.
>>
>> If your philosophy is to take every proactive measure ahead of time 
>> possible, then that's fine.  I just don't see the point with regards 
>> to FSMO roles when the recovery action is a relatively trivial 
>> process.  This is obviously a matter of personal preference so I'm 
>> not trying to convince others to change.  I just found the concept 
>> unusual so I thought I'd share.
>>
>>
>>> -----Original Message-----
>>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of 
>>> neil.ruston@xxxxxxxxxxxxx
>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> Subject: RE: [ActiveDir] FSMO role transfer
>>>
>>> I would rather, as stated earlier, assess the risk and then act 
>>> appropriately. The original poster never defined 'maintenance' in 
>>> detail.
>>>
>>> The original post did state that the box would be down for ~2 hours 
>>> for maintenance. This is clearly more than a patch and a
>>>
>> reboot. We've
>>
>>> been over that scenario and concluded that it carries a lesser risk.
>>>
>>> As joe said, if the maintenance all goes badly wrong, do
>>>
>> you want to
>>
>>> be pulled into a dark room and questioned as to why you did not 
>>> prepare for that eventuality?
>>>
>>>
>>> neil
>>>
>>>
>>> -----Original Message-----
>>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan 
>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>> Sent: 30 November 2005 15:29
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> Subject: Re: [ActiveDir] FSMO role transfer
>>>
>>> Okay define maintenance please?
>>>
>>> Patching?
>>> Service Pack?
>>> Applying QFEs?
>>> Performance tuning?
>>> What?
>>>
>>> Is there a level of maintenance that would cause you to move FSMO's 
>>> and not?
>>>
>>> Like for example, if I'm patching, I've tested the patch, I'm 
>>> reasonably expecting a favorable outcome otherwise I wouldn't be 
>>> deploying, I have a backup.
>>>
>>> neil.ruston@xxxxxxxxxxxxx wrote:
>>>
>>>
>>>> I think we've missed the essence of the original post :)
>>>>
>>> The DCs are
>>>
>>>> not just being rebooted, they are being 'maintained' and
>>>>
>>> will be down
>>>
>>>> for ~ 2 hours. That means to me, that either a s/w or h/w
>>>>
>> change is
>>
>>>> going to occur which could go horribly wrong. Faced with this 
>>>> situation, I would definitely transfer the roles.
>>>> If the DC were merely being rebooted and nothing else is
>>>>
>>> scheduled to
>>>
>>>> occur, I would not transfer roles.
>>>> The above 2 scenarios are very different - if one were to
>>>>
>> perform a
>>
>>>> risk analysis the actions taken to mitigate those risks would be 
>>>> suitably different.
>>>> neil
>>>>
>>>>
>> ---------------------------------------------------------------------
>> -
>>
>>>> --
>>>> *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>
>>> *David Adner
>>>
>>>> *Sent:* 29 November 2005 23:26
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *Subject:* RE: [ActiveDir] FSMO role transfer
>>>>
>>>> I would only agree if you told me your DC's regularly
>>>>
>> fail to come
>>
>>>> back after a reboot. And if you did tell me that I'd have to say 
>>>> you're doing something wrong.
>>>> I suppose I don't consider rebooting a DC to be quite the
>>>>
>> dangerous
>>
>>>> act as others do. To what degree is this taken? If it holds
>>>>
>>> a standard
>>>
>>>
>>>> Primary zone do you transfer that role, too? If it's the
>>>>
>>> PDCE of the
>>>
>>>> forest root domain and you transfer the role, do you also
>>>>
>>> reconfigure
>>>
>>>> the new PDCE to manually synchronize time from an authoritative 
>>>> source? I mean, if we're going to work under the
>>>>
>> assumption that a
>>
>>>> reboot is a regularly catastrophic causing event then
>>>>
>> it's probably
>>
>>>> time to switch OS's.
>>>> Is it possible something unexpectedly horrible can happen
>>>>
>>> as part of a
>>>
>>>
>>>> reboot? Sure. But it better be the exception. And with
>>>>
>>> regards to FSMO
>>>
>>>
>>>> roles, which, barring some specific technical requirement they be 
>>>> readily available, the temporary outage of them is typically a 
>>>> transparent event and shouldn't require added
>>>>
>>> administrative overhead
>>>
>>>> in transferring them back and forth. Accepting that a
>>>>
>> catastrophic
>>
>>>> event is an exception, then you follow your documented and tested 
>>>> activities to recover from that exception; ie: you seize
>>>>
>> the roles,
>>
>>>> restore from backup, etc.
>>>>
>>>>
>>>>
>>> --------------------------------------------------------------
>>> ----------
>>>
>>>>     *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>     [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On
>>>>
>> Behalf Of *Rich
>>
>>>>     Milburn
>>>>     *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>>     *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>     *Subject:* RE: [ActiveDir] FSMO role transfer
>>>>
>>>>     Yeah but having "seize the FSMOs instead of moving
>>>>
>> them" as your
>>
>>>>     fallback plan is like making sure you have a current backup in
>>>>     case "yanking the power cord instead of Start > Shutdown >
>>>>     Restart" causes file system corruption J
>>>>
>>>>
>>>>
>>> //------------------------------------------------------------
>>> ----------
>>> -///
>>>
>>>>     ///Rich Milburn///
>>>>     ///MCSE, Microsoft MVP - Directory Services///
>>>>     Sr Network Analyst, Field Platform Development
>>>>     Applebee's International, Inc.//
>>>>     //4551 W. 107th St//
>>>>     //Overland Park//, KS 66207//
>>>>     //913-967-2819//
>>>>
>>>>
>>> //------------------------------------------------------------
>>> ----------
>>> //
>>>
>>>>     ///"I love the smell of red herrings in the morning" -
>>>>
>>> anonymous//
>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> -
>>
>>>> --
>>>>
>>>>     *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>     [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>     *ChuckGaff@xxxxxxx
>>>>     *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>>     *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>     *Subject:* Re: [ActiveDir] FSMO role transfer
>>>>
>>>>     If something went wrong you could still seize the FSMO
>>>>
>>> roles as an
>>>
>>>>     option rather than doing a transfer. Of course the
>>>>
>>> procedures for
>>>
>>>>     all of these for the 5 FSMOs should be documented just in case
>>>>     needed..
>>>>
>>>>     Chuck
>>>>
>>>>     /
>>>>
>>>>
>>> --------------------------------------------------------------
>>> ----------
>>>
>>>>     *-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY
>>>>
>>> NOTICE-------*
>>>
>>>>     PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this
>>>>     message or any attachments. This information is strictly
>>>>     confidential and may be subject to attorney-client
>>>>
>>> privilege. This
>>>
>>>>     message is intended only for the use of the named
>>>>
>> addressee. If
>>
>>>>     you are not the intended recipient of this message,
>>>>
>> unauthorized
>>
>>>>     forwarding, printing, copying, distribution, or using such
>>>>     information is strictly prohibited and may be unlawful. If you
>>>>     have received this in error, you should kindly notify
>>>>
>> the sender
>>
>>>>     by reply e-mail and immediately destroy this message.
>>>>
>>> Unauthorized
>>>
>>>>     interception of this e-mail is a violation of federal criminal
>>>>     law. Applebee's International, Inc. reserves the right
>>>>
>>> to monitor
>>>
>>>>     and review the content of all messages sent to and from this
>>>>     e-mail address. Messages sent to or from this e-mail
>>>>
>> address may
>>
>>>>     be stored on the Applebee's International, Inc.
>>>>
>> e-mail system./
>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> -
>>
>>>> --
>>>>
>>>> PLEASE READ: The information contained in this email is
>>>>
>>> confidential
>>>
>>>> and intended for the named recipient(s) only. If you are not an 
>>>> intended recipient of this email please notify the sender
>>>>
>>> immediately
>>>
>>>> and delete your copy from your system. You must not copy,
>>>>
>>> distribute
>>>
>>>> or take any further action in reliance on it. Email is
>>>>
>> not a secure
>>
>>>> method of communication and Nomura International plc
>>>>
>> ('NIplc') will
>>
>>>> not, to the extent permitted by law, accept responsibility or 
>>>> liability for (a) the accuracy or completeness of, or (b)
>>>>
>>> the presence
>>>
>>>
>>>> of any virus, worm or similar malicious or disabling code
>>>>
>> in, this
>>
>>>> message or any attachment(s) to it. If verification of this
>>>>
>>> email is
>>>
>>>> sought then please request a hard copy. Unless otherwise
>>>>
>> stated this
>>
>>>> email: (1) is not, and should not be treated or relied upon as, 
>>>> investment research; (2) contains views or opinions that
>>>>
>> are solely
>>
>>>> those of the author and do not necessarily represent
>>>>
>> those of NIplc;
>>
>>>> (3) is intended for informational purposes only and is not a 
>>>> recommendation, solicitation or offer to buy or sell
>>>>
>> securities or
>>
>>>> related financial instruments. NIplc does not provide investment 
>>>> services to private customers. Authorised and regulated by the 
>>>> Financial Services Authority. Registered in England no.
>>>>
>> 1550505 VAT
>>
>>>> No. 447 2492 35. Registered Office: 1 St
>>>>
>> Martin's-le-Grand, London,
>>
>>>> EC1A 4NP. A member of the Nomura group of companies.
>>>>
>>> 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/
>>>
>>>
>>>
>>> PLEASE READ: The information contained in this email is
>>>
>> confidential
>>
>>> and intended for the named recipient(s) only. If you are not an 
>>> intended recipient of this email please notify the sender
>>>
>> immediately
>>
>>> and delete your copy from your system.
>>> You must not copy, distribute or take any further action in
>>>
>> reliance
>>
>>> on it. Email is not a secure method of communication and Nomura 
>>> International plc ('NIplc') will not, to the extent
>>>
>> permitted by law,
>>
>>> accept responsibility or liability for (a) the accuracy or 
>>> completeness of, or (b) the presence of any virus, worm or similar 
>>> malicious or disabling code in, this message or any
>>>
>> attachment(s) to
>>
>>> it. If verification of this email is sought then please
>>>
>> request a hard
>>
>>> copy. Unless otherwise stated this email: (1) is not, and
>>>
>> should not
>>
>>> be treated or relied upon as, investment research; (2)
>>>
>> contains views
>>
>>> or opinions that are solely those of the author and do not
>>>
>> necessarily
>>
>>> represent those of NIplc; (3) is intended for informational
>>>
>> purposes
>>
>>> only and is not a recommendation, solicitation or offer to
>>>
>> buy or sell
>>
>>> securities or related financial instruments.  NIplc does
>>>
>> not provide
>>
>>> investment services to private customers.  Authorised and
>>>
>> regulated by
>>
>>> the Financial Services Authority.  Registered in England no.
>>> 1550505 VAT No. 447 2492 35.  Registered Office: 1 St 
>>> Martin's-le-Grand, London, EC1A 4NP.  A member of the
>>>
>> Nomura group of
>>
>>> companies.
>>>
>>> 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/
>> 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/
>
>

--

Letting your vendors set your risk analysis these days?
http://www.threatcode.com

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/


<Prev in Thread] Current Thread [Next in Thread>