| Author | Messages | |
MThommes
Posts:73
 | | 11/29/2005 10:50 AM |
| Hi David,
I™m with you on this one!
Mike Thommes
-----Original Message-----
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
Sent: Tuesday, November 29, 2005
4:27 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role
transfer
If the insurance is
guarding against apps/services/etc that may need the FSMO holders while they're
offline, then I can agree with this. If it's out of fear that something
unexpected will happen that takes out the FSMO holders completely, then I don't
think it's worth the effort. If the latter does happen then you just
seize the roles.
I would say that many of
the customers I've visited have little experience and even less confidence in
how FSMO roles are transferred or seized. The thought of them touching
the roles for every reboot is making my hair fall out even faster. :/
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of joe
Sent: Tuesday, November 29, 2005
2:51 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role
transfer
In production I always
move the domain roles prior to working on a DC or even rebooting a DC. As
you mention, the role move is trivial and if something does dork up you have
less to think about and aren't wondering at what point you should be seizing. I
am not so worried about the forest roles but will usually move them as well.
Dean and I actually
chatted about this previously as I put something like that in the AD3E book and
he was like, you *always* move the domain roles like that and I was like "
In production, absolutely". The one time you don't you seem to get burned
and you feel very stupid for not doing it when you could have. Once in the
distant past I had a PDC role machine that hung up when shutting down
(it was just a quick reboot so I figured why bother) and started acting very
fishy and I kicked myself for not moving the roles. Why risk that?
It is very cheap
insurance. At one point I had a CMD file called something like
movefsmo that used NTDSUTIL to move the roles, I think it took all of
about 5 seconds to run to move all roles from one machine to another.
I agree with Ed in that I
consider this SOP.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Tuesday, November 29, 2005
11:03 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role
transfer
Sorry, but for peace of
mind, I *would* transfer the roles. If there is opportunity to do so, then why
not transfer? It's a trivial task and will take no time to replicate (assuming
the other DC is in the same site).
More worrying perhaps, is
the fact that if clients point to one (or both) DCs for DNS name resolution,
then they may experience issues when one of the machines is taken down.
Hopefully, the poster has
considered this latter scenario.
hth,
neil
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Craig Cerino
Sent: 29 November 2005 15:54
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role
transfer
Amy,
If it™s what you need to hear (for peace of mind “ or
reassurance) leave the FSMO roles where they are - you™ll be fine.
You don™t need to transfer the rolls if your talking about a timeframe of
2 hours - - -when you bring it back on line - -I would just leave the other DC
online for at least and hour (unless you have adjusted the replication
intervals) to make sure any changes are replicated.
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Amy Hunter
Sent: Tuesday, November 29, 2005
10:43 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] FSMO role
transfer
Hi guys,
We have two DC's, one which holds the Forest FSMO
roles, the other which holds the domain FSMO roles.
I plan to take each server down at different
times so that one of the two servers can provide authentication etc while
the other gets maintained.
Initially, I was planning on moving the FSMO roles to
the other DC while maintainance work is carried out and transferring it back
once it's online again. I would then do the same for the other DC.
I was then told that you don't need to move the FSMO
roles when you perform maintenance on a DC holding the
roles. Each server will be down for about 2hrs.
Does anyone have advice for me? I would like to move
the roles for peace of mind knowing they are available, but if I don't need to
do that, I won't bother
Is there any recommended practice?
Amy
To help you stay safe and secure
online, we've developed the all new Yahoo! Security Centre.
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. | | | |
| Gil
Posts:75
| | 11/29/2005 11:09 AM |
| By definition, the impact of a maintenance task is expected to be low.
But the behavior of a server isn't always predictable after you change
the software and/or configuration and reboot it. Sometimes just the
power or temperature fluctuation is enough to kick a marginal component
over the edge.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Almeida Pinto,
Jorge de
Sent: Tuesday, November 29, 2005 12:16 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx; ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
If you want 100% insurance then yes transfering the FSMO roles prior to
the maintenance task could prevent an eventual seize if the particular
DC dies for some reason.
Maybe dependent on the maintenance task that is performed a decision
should be made if the FSMO roles should be transfered or not. So..
define maintenance task... what is the impact of the maintenance task?
jorge
________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Gil Kirkpatrick
Sent: Tue 11/29/2005 6:20 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
I'd move the FSMOs just in case "something" happens and the DC in fact
doesn't come back in 2 hours. How many times have you done PM on a
machine only to have it completely f***** up and have to restore? It
seems like about a 1-in-25 chance that something will go wrong.
-gil
________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Almeida Pinto,
Jorge de
Sent: Tuesday, November 29, 2005 9:09 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
First, look at each role and see what it does...
Forest FSMOs
* Schema Master --> needed when updating the schema
* Domain Naming master --> needed when adding or removing domains within
the forest
Domain FSMOs
* PDC Emulator --> needed for legacy clients (NT4, W9x) when changing
passwords, used for time sync, is used for pwd checking when a user
enters an incorrect pwd at another DC, used by DFS roots to get DFS info
* RID Master --> needed to distribute RID pools to DCs that have
exhausted their current RID pool for 50% (=250 RIDs)
* Infrastructure --> needed to update references between domains in a
forest (does not do anything in a single domain forest)
If you look at this, there is no need to first transfer the FSMO roles
to another DC, just to carry out maintenance activities. It also depends
on the FSMO role. The most used ones in your case will be the RID and
the PDC FSMO. Only if you create more than 500 security principals
(users, groups and computers) during the moment that the DC with the RID
FSMO is down, you will experience a problem on the DC that is left. If
you still have legacy clients and they want to change the password that
will not be possible. And if those clients have the DSClient installed
that will not be an issue either.
In short: leave as is. it will be OK for those 2 hours
Cheers,
jorge
________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Amy Hunter
Sent: Tuesday, November 29, 2005 16:43
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] FSMO role transfer
Hi guys,
We have two DC's, one which holds the Forest FSMO roles, the other which
holds the domain FSMO roles.
I plan to take each server down at different times so that one of the
two servers can provide authentication etc while the other gets
maintained.
Initially, I was planning on moving the FSMO roles to the other DC while
maintainance work is carried out and transferring it back once it's
online again. I would then do the same for the other DC.
I was then told that you don't need to move the FSMO roles when you
perform maintenance on a DC holding the roles. Each server will be down
for about 2hrs.
Does anyone have advice for me? I would like to move the roles for peace
of mind knowing they are available, but if I don't need to do that, I
won! 't bother
Is there any recommended practice?
Amy
________________________________
To help you stay safe and secure online, we've developed the all new
Yahoo! Security Centre
.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by, any other party. If you are
not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ | | | |
| AD00000804
Posts:0
| | 11/29/2005 11:18 AM |
| I've not worried about transferring the FSMO roles for general maintenance
such as defragmentation or updating SPs, etc. It's up to how flaky or
solid the DCs are -- if they are that flaky then maybe it's time to buy
some newer hardware ...
Chuck | | | |
| davidadner
Posts:0
| | 11/29/2005 11:33 AM |
| 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
MilburnSent: Tuesday, November 29, 2005 4:26 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
MilburnMCSE, Microsoft MVP
- Directory ServicesSr
Network Analyst, Field Platform DevelopmentApplebee's International,
Inc.4551
W. 107th
StOverland
Park,
KS 66207913-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@xxxxxxxSent: Tuesday, November 29, 2005 11:56
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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. | | | |
| habr
Posts:25
| | 11/30/2005 1:20 AM |
| Yeah ....
Thanks a lot Gil !
This is all we need to hear and be reminded of.
For >YEARS needed when updating the schema
* Domain Naming master --> needed when adding or removing domains within
the forest
Domain FSMOs
* PDC Emulator --> needed for legacy clients (NT4, W9x) when changing
passwords, used for time sync, is used for pwd checking when a user
enters an incorrect pwd at another DC, used by DFS roots to get DFS info
* RID Master --> needed to distribute RID pools to DCs that have
exhausted their current RID pool for 50% (=250 RIDs)
* Infrastructure --> needed to update references between domains in a
forest (does not do anything in a single domain forest)
If you look at this, there is no need to first transfer the FSMO roles
to another DC, just to carry out maintenance activities. It also depends
on the FSMO role. The most used ones in your case will be the RID and
the PDC FSMO. Only if you create more than 500 security principals
(users, groups and computers) during the moment that the DC with the RID
FSMO is down, you will experience a problem on the DC that is left. If
you still have legacy clients and they want to change the password that
will not be possible. And if those clients have the DSClient installed
that will not be an issue either.
In short: leave as is. it will be OK for those 2 hours
Cheers,
jorge
________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Amy Hunter
Sent: Tuesday, November 29, 2005 16:43
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] FSMO role transfer
Hi guys,
We have two DC's, one which holds the Forest FSMO roles, the other which
holds the domain FSMO roles.
I plan to take each server down at different times so that one of the
two servers can provide authentication etc while the other gets
maintained.
Initially, I was planning on moving the FSMO roles to the other DC while
maintainance work is carried out and transferring it back once it's
online again. I would then do the same for the other DC.
I was then told that you don't need to move the FSMO roles when you
perform maintenance on a DC holding the roles. Each server will be down
for about 2hrs.
Does anyone have advice for me? I would like to move the roles for peace
of mind knowing they are available, but if I don't need to do that, I
won! 't bother
Is there any recommended practice?
Amy
________________________________
To help you stay safe and secure online, we've developed the all new
Yahoo! Security Centre
.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by, any other party. If you are
not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
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/ | | | |
| listmail
Posts:429
| | 11/30/2005 1:31 AM |
| Yeah my fault, I brought up the reboot. I would and do move
roles in production for reboots. Same logic you state only role moves take
seconds so no reason not to do it for a reboot as well as
maintenance.
Something else I was thinking about last night about this
post when I was doing some photo artwork for this year's holiday
card was that the environments I have done ops for are probably a bit
different from a majority of this list. These are environments that put you in
Change Control meetings for hours a week while you listen to every change that
is going to happen on machines from PC Servers up through Numerical Intensive
Computing on Super Clusters and very high end SGI, Cray's, and Mainframes to
make sure there is nothing that could possibly impact you. An environment where
you are lucky to get a schema modification (even something as silly as linking
Drink to a user) tested and approved in the course of 6 months. Basically, there
really is not time allocated for any domain/forest functions to be down. Doesn't
mean machines can't be down, but all functions of the domain/forest that could
possibly be needed by anyone anywhere need to be up.
Given that, the forest roles aren't critical because they
were owned and used only by our group of 3 people. However roles like say the
PDC which *is used* for far more than legacy password changes must be available
if only for poorly written apps (or even good apps like GPO tools) that
look for the PDC and use it. Keep in mind that one large function of the PDC is
the handling of PDC Chaining which is pretty important in a large environment.
With the PDC down, a password change can take the domain wide replication
latency convergence period to be fully operational (say 30 minutes to an
hour an 15 minutes if changed in a spoke of a hub and spoke
environment with intersite replication reduced to 15 minutes) where with the PDC
in place it is fully operational immediately. This isn't trivial because there
are thousands of password changes daily just from normal password expiration
churn. Also RID Master functionally could be needed at any time as we are
talking hundreds of thousands of users and machines and again, normal churn.
Creation of a batch of several hundred users or computers off of a single DC in
a very short time frame would certainly not be unheard of.
Now lets say there is an issue, no matter how small. If it
impacted anyone, you have to A) Fix it B) Work out why it happened
and why and how it won't happen again C) Stand in a series of meetings that
could very easily drag on for hours and hours over the course of a couple of
months explaining to the nth degree A and B to high level management who last
did anything truly technical when mainframes were the only computing
environment.
All of that being said, I think moving the FSMO roles any
time the FSMO role holder will be unavailable for any period of time is a good
solid exercise. It is such a simple painless exercise when scripted.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
neil.ruston@xxxxxxxxxxxxxSent: Wednesday, November 30, 2005 3:58
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir]
FSMO role transfer
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
AdnerSent: 29 November 2005 23:26To:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
MilburnSent: Tuesday, November 29, 2005 4:26 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
MilburnMCSE, Microsoft MVP
- Directory ServicesSr
Network Analyst, Field Platform DevelopmentApplebee's International,
Inc.4551
W. 107th
StOverland
Park,
KS 66207913-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@xxxxxxxSent: Tuesday, November 29, 2005 11:56
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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. | | | |
| listmail
Posts:429
| | 11/30/2005 1:35 AM |
| There is an old saying (well at least it seems old, I recall first hearing
it in a programming course at Michigan State University back in 1988 or so)
that I have heard various forms of:
If builders made buildings the way programmers wrote programs, the first
woodpecker that came along would destroy civilization.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rocky Habeeb
Sent: Wednesday, November 30, 2005 8:21 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
Yeah ....
Thanks a lot Gil !
This is all we need to hear and be reminded of.
For >YEARS needed when updating the schema
* Domain Naming master --> needed when adding or removing domains within the
forest
Domain FSMOs
* PDC Emulator --> needed for legacy clients (NT4, W9x) when changing
passwords, used for time sync, is used for pwd checking when a user enters
an incorrect pwd at another DC, used by DFS roots to get DFS info
* RID Master --> needed to distribute RID pools to DCs that have exhausted
their current RID pool for 50% (=250 RIDs)
* Infrastructure --> needed to update references between domains in a forest
(does not do anything in a single domain forest)
If you look at this, there is no need to first transfer the FSMO roles to
another DC, just to carry out maintenance activities. It also depends on the
FSMO role. The most used ones in your case will be the RID and the PDC FSMO.
Only if you create more than 500 security principals (users, groups and
computers) during the moment that the DC with the RID FSMO is down, you will
experience a problem on the DC that is left. If you still have legacy
clients and they want to change the password that will not be possible. And
if those clients have the DSClient installed that will not be an issue
either.
In short: leave as is. it will be OK for those 2 hours
Cheers,
jorge
________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Amy Hunter
Sent: Tuesday, November 29, 2005 16:43
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] FSMO role transfer
Hi guys,
We have two DC's, one which holds the Forest FSMO roles, the other which
holds the domain FSMO roles.
I plan to take each server down at different times so that one of the two
servers can provide authentication etc while the other gets maintained.
Initially, I was planning on moving the FSMO roles to the other DC while
maintainance work is carried out and transferring it back once it's online
again. I would then do the same for the other DC.
I was then told that you don't need to move the FSMO roles when you perform
maintenance on a DC holding the roles. Each server will be down for about
2hrs.
Does anyone have advice for me? I would like to move the roles for peace of
mind knowing they are available, but if I don't need to do that, I won! 't
bother
Is there any recommended practice?
Amy
________________________________
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre
.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
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/ | | | |
| listmail
Posts:429
| | 11/30/2005 2:14 AM |
| Actually I make all DCs that have a possibility of being
the forest root PDC synchronize from an external source. I haven't ever run DNS
on DCs so I can't say anything to that, however if I did, I might consider it.
There really is nothing to moving FSMO roles. Have you had
a FSMO role move failure that makes you giddy about them? I was serious when I
said that moving the roles was a 5 second operation.
It doesn't take regular failures (hardware, software, or
other) to have one just occur at any random time. It is just like house
insurance, you don't buy it because you want to use it or even expect to use it,
you buy it to cover you in the event something does happen. Everyone has to make
a judgement call as to whether the insurance costs outweigh the impact of
whatever it is the insurance protects against. Moving FSMO roles would be
insurance, the thing it is protecting against is the possibility of some dorked
up issue coming up when the server is going down or coming up or if it doesn't
come up at all. If you use the manual steps, the overhead is minutes, if you use
scripts the overhead is seconds. That is better than the pennies a day used to
sell people on other insurance.
I would be afraid if my customers were so weak on procedure
that moving a FSMO role was considered hard or dangerous.
Obviously this is something that everyone is going to have
different feelings on. I certainly don't care what people do on their owns, my
process and what I recommend is to move the roles. I much rather move roles than
seize them. Seizing is when I get concerns such as RID pools and now you are
locked into what you are doing with the offline DC.
Overall I would say that a vast majority of the reboots and
maintanence work I have done didn't appear after the fact to need the FSMO move.
But I figure the few minutes spent over the years wasn't an excessive
administrative cost to do the FSMO moves.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David
AdnerSent: Tuesday, November 29, 2005 6:26 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
MilburnSent: Tuesday, November 29, 2005 4:26 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
MilburnMCSE, Microsoft MVP
- Directory ServicesSr
Network Analyst, Field Platform DevelopmentApplebee's International,
Inc.4551
W. 107th
StOverland
Park,
KS 66207913-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@xxxxxxxSent: Tuesday, November 29, 2005 11:56
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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. | | | |
| sbradcpa
Posts:299
| | 11/30/2005 3:30 AM |
| 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/ | | | |
| AD
Posts:2
| | 11/30/2005 3:32 AM |
| Sorry I had to express myself here. Love the analogy. Well said.
From: joeSent: Tue 29/11/2005 9:12 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] FSMO role transfer
Actually I make all DCs that have a possibility of being the forest root PDC synchronize from an external source. I haven't ever run DNS on DCs so I can't say anything to that, however if I did, I might consider it.
There really is nothing to moving FSMO roles. Have you had a FSMO role move failure that makes you giddy about them? I was serious when I said that moving the roles was a 5 second operation.
It doesn't take regular failures (hardware, software, or other) to have one just occur at any random time. It is just like house insurance, you don't buy it because you want to use it or even expect to use it, you buy it to cover you in the event something does happen. Everyone has to make a judgement call as to whether the insurance costs outweigh the impact of whatever it is the insurance protects against. Moving FSMO roles would be insurance, the thing it is protecting against is the possibility of some dorked up issue coming up when the server is going down or coming up or if it doesn't come up at all. If you use the manual steps, the overhead is minutes, if you use scripts the overhead is seconds. That is better than the pennies a day used to sell people on other insurance.
I would be afraid if my customers were so weak on procedure that moving a FSMO role was considered hard or dangerous.
Obviously this is something that everyone is going to have different feelings on. I certainly don't care what people do on their owns, my process and what I recommend is to move the roles. I much rather move roles than seize them. Seizing is when I get concerns such as RID pools and now you are locked into what you are doing with the offline DC.
Overall I would say that a vast majority of the reboots and maintanence work I have done didn't appear after the fact to need the FSMO move. But I figure the few minutes spent over the years wasn't an excessive administrative cost to do the FSMO moves.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David AdnerSent: Tuesday, November 29, 2005 6:26 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 MilburnSent: Tuesday, November 29, 2005 4:26 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 MilburnMCSE, Microsoft MVP - Directory ServicesSr Network Analyst, Field Platform DevelopmentApplebee's International, Inc.4551 W. 107th StOverland Park, KS 66207913-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@xxxxxxxSent: Tuesday, November 29, 2005 11:56 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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. | | | |
| AD000001290
Posts:0
| | 11/30/2005 4:18 AM |
| 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/ | | | |
| davidadner
Posts:0
| | 11/30/2005 6:26 AM |
| 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/ | | | |
| AD000001161
Posts:0
| | 11/30/2005 6:34 AM |
| 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/ | | | |
| mark.parris@xxxx.yyy
| | 11/30/2005 6:54 AM |
| Mr pedantic here,
That's a stitch in time saves nine.....
-----Original Message-----
From: Bahta Nathaniel V Contractor NASIC/SCNA
Date: Wed, 30 Nov 2005 13:32:13
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 s |
|
|