It can be. It's easily scripted.
-----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:39 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] FSMO role transfer
That's my point.
If this is .....according to some of the threads on this, it is normal,
regular, and part of a risk management process to just move these roles
around, yes? Why not one click?
Cace, Andrew wrote:
> It is available in the AD snap-ins. In AD Domains & Trusts, you can
> transfer the Domain Naming master by right-clicking the name of the
snap-in
> in tree-view and choosing Operations Master. In ADUC, right-click the
name
> of the domain and choose Operations Master to transfer the RID, PDC,
and
> Infrastructure masters. In the Schema Management snapin, you can
transfer
> the Schema master by right-clicking Active Directory Schema and
choosing
> Operations Master.
>
> Next question...Why isn't there a single place to click all of these?
>
> -Andrew
>
> -----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 3: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/
>
--
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/
|
