Location: List Archives

List Archives

This forum is an archive of all posts to our mailing list over the past few years.  The forum is set read only therefore to contribute you will need to join our list community.  See more info about this here.

List Archives

Subject: [ActiveDir] FSMO role transfer
Prev Next
You are not authorized to post a reply.

Page 3 of 4<< < 1234 > >>
AuthorMessages
AndrewCace@xxxx.yyy

11/30/2005 9:31 AM  
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

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?

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/
Attachment:
smime.p7s
sbradcpaUser is Offline

Posts:317

11/30/2005 9:41 AM  
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

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?

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/
michael@xxxx.yyy

11/30/2005 9:48 AM  
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
>
>
>
> 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?
>
> 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/
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/
jfigueroaUser is Offline

Posts:13

11/30/2005 10:06 AM  
I think what was meant about the "trivial" part is around the seizing of
the roles not the transfer. I would love to have much of the ntdsutil
functionality built into the UI, even if at some point it requires you
to reboot/restore, whatever.

I don't think either camp is going to convince the other that you should
or shouldn't transfer roles prior to some maintenance. It is almost a
personality thing. I prefer not to transfer the role and deal with the
possibility that I may need to seize it, on the rare case that something
goes drastically wrong that I can not recover from before the role is
actually needed. You architected the roles on specific DCs for a reason,
if I forget to move it back I may end up with a DC hosting a role for a
long time that I never meant to. Also, I don't consider transferring
roles around part of the normal operating procedures.

But that's just me.

Thanks

-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Cace, Andrew
Sent: Wednesday, November 30, 2005 2:26 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer

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

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?

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/
AD00000804User is Offline

Posts:0

11/30/2005 10:09 AM  
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] To: ActiveDir@xxxxxxxxxxxxxxxxxxSent: Wed, 30 Nov 2005 13:38:43 -0800Subject: 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: 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 > >  > > 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? > > 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 &
gt;>> 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 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: 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: Activ
eDir-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 >>>&
gt;> [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 >>>>> >>&
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:* 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 >>>>> >>>>> >>>>> >>>>> >>>> //------------------------------------------------------------ >>>> ---------- >>>> -/// >>>> &
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:* 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 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/
habrUser is Offline

Posts:25

11/30/2005 10:17 AM  
Susan,

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

There are a >LOT

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?

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
<