A lot more is going on behind the scenes when transferring FSMOs besides checking boxes -- Also there's more to moving to Domain Naming Master --
Chuck
-----Original Message-----
From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wed, 30 Nov 2005 13:38:43 -0800
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
&g t;
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Susan Bradley, CPA
> aka Ebitz - SBS Rocks [MVP]
> Sent: Wednesday, November 30, 2005 3:09 PM
> To: [email protected]
> 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: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED]] On Behalf Of Bahta >>> Nathaniel V Contractor NASIC/SCNA
>>> Sent: Wednesday, November 30, 2005 12:32 PM
>>> To: [email protected]
>>> 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: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED]] On Behalf Of David Adner
& gt;>> Sent: Wednesday, November 30, 2005 1:24 PM
>>> To: [email protected]
>>> 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 matte r 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: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED]] On Behalf Of >>>> [EMAIL PROTECTED]
>>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>>> To: [email protected]
>>>> 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: Activ [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED]] On Behalf Of Susan >>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>>> Sent: 30 November 2005 15:29
>>>> To: [email protected]
>>>> 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.
>>>>
>>>> [EMAIL PROTECTED] 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:* [EMAIL PROTECTED]
>>>& gt;> [mailto:[EMAIL PROTECTED]] *On Behalf Of
>>>>> >>>>> >>>> *David Adner
>>>> >>>> >>>>> *Sent:* 29 November 2005 23:26
>>>>> *To:* [email protected]
>>>>> *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
>>>>> >>& gt;>> >>> 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:* [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED]] *On
>>>>> >>>>> >>> Behalf Of *Rich
>>> >>> >> >>> Milburn
>>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>>> *To:* [email protected]
>>>>> *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
>>>>>
>>>>>
>>>>> >>>>> >>>> //------------------------------------------------------------
>>>> ----------
>>>> -///
>>>> & gt;>>> >>>>> ///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:* [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED]] *On Behalf Of
>>>>> *[EMAIL PROTECTED]
>>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>>> *To:* [email protected]
>>>>> *Subject:* Re: [ActiveDir] FSMO role transfer
>>>>>
>>>>> If something went wrong you could still seize the FSMO
>>>>> >>>>> >>>> roles as an
>>>> >>>> >>>>> option rathe r 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 u pon 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 3 5. Registered Office: 1 St
>>>>> >>>>> >>> Martin's-le-Grand, London,
>>> >>> >>>>> EC1A 4NP. A member of the Nomura group of companies.
>>>>> >>>>> >>>> List info : http://www.activedirorg/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 int ended 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.or g/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/
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
&g t;
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Susan Bradley, CPA
> aka Ebitz - SBS Rocks [MVP]
> Sent: Wednesday, November 30, 2005 3:09 PM
> To: [email protected]
> 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: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED]] On Behalf Of Bahta >>> Nathaniel V Contractor NASIC/SCNA
>>> Sent: Wednesday, November 30, 2005 12:32 PM
>>> To: [email protected]
>>> 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: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED]] On Behalf Of David Adner
& gt;>> Sent: Wednesday, November 30, 2005 1:24 PM
>>> To: [email protected]
>>> 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 matte r 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: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED]] On Behalf Of >>>> [EMAIL PROTECTED]
>>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>>> To: [email protected]
>>>> 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: Activ [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED]] On Behalf Of Susan >>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>>> Sent: 30 November 2005 15:29
>>>> To: [email protected]
>>>> 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.
>>>>
>>>> [EMAIL PROTECTED] 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:* [EMAIL PROTECTED]
>>>& gt;> [mailto:[EMAIL PROTECTED]] *On Behalf Of
>>>>> >>>>> >>>> *David Adner
>>>> >>>> >>>>> *Sent:* 29 November 2005 23:26
>>>>> *To:* [email protected]
>>>>> *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
>>>>> >>& gt;>> >>> 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:* [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED]] *On
>>>>> >>>>> >>> Behalf Of *Rich
>>> >>> >> >>> Milburn
>>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>>> *To:* [email protected]
>>>>> *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
>>>>>
>>>>>
>>>>> >>>>> >>>> //------------------------------------------------------------
>>>> ----------
>>>> -///
>>>> & gt;>>> >>>>> ///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:* [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED]] *On Behalf Of
>>>>> *[EMAIL PROTECTED]
>>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>>> *To:* [email protected]
>>>>> *Subject:* Re: [ActiveDir] FSMO role transfer
>>>>>
>>>>> If something went wrong you could still seize the FSMO
>>>>> >>>>> >>>> roles as an
>>>> >>>> >>>>> option rathe r 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 u pon 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 3 5. Registered Office: 1 St
>>>>> >>>>> >>> Martin's-le-Grand, London,
>>> >>> >>>>> EC1A 4NP. A member of the Nomura group of companies.
>>>>> >>>>> >>>> List info : http://www.activedirorg/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 int ended 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.or g/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/
