Let’s look at the roles for a minute….
Domain Naming Master: Okay, so in a large environment there may be
people creating domains on a regular basis. But is it really a crisis
that will leave someone in a panic if that role holder goes down for a
few hours?
Schema: Hopefully this is one that can stay down with no real
consequences, except for Exchange upgrades and the like. If it is
down, it will not cause panic, it can be moved.
RID: I could see this being a problem, if a large number of objects
are being created. But even in the biggest environments there aren’t a
whole lot of times that 1000s of objects are being created simultaneously.
Infrastructure: Yeah, if this is down you will certainly see some
issues in a large network. Over time. It seems like it would be a
while before the info in the domains got stale enough for this to
really matter.
PDC: As Joe mentioned, there would be some real headaches here if
you’ve got old (needs to be retired) computers running NT or anything
in the 9x realm. Hopefully that is not the case. Older softer is much
more likely, and as Joe said, could present some major crises. And
passwords would be a given.
Since there is such disagreement amongst the brethren (and sistren),
perhaps we could all agree that the PDCEm would be a real bear if it
was gone for a few hours. Perhaps we don’t all agree that we should
change our patching plans based on that, but I can certainly see the
wisdom in moving that one. The others seem just as disposable as any
other dc, since they could probably be gone a while with no adverse
consequences.
Kevin
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Deji Akomolafe
*Sent:* Thursday, August 17, 2006 3:04 PM
*To:* [email protected]
*Subject:* RE: [ActiveDir] FMSO roles split, patch question.
I always try to frame my responses around the requested info. In tis
case, the OP wanted to know the folloing:
After I apply the patches from Microsoft what is the beat practices
for the boot order...or does it matter?
1. Remote DC/GC's first
2. no. 1
3. then no 2.
The simple and logical answer is "it does not matter". The order of
your patching and rebooting your DC is NOT depepndent on the roles
they hold.
Everything else you've written in your response is all well and good.
Nice to have, if I must say. I still stand by the original response.
You do NOT have to put a lot of thoughts into playing chess with your
roles just to figure out which one to reboot first. DCs are
dispensable, even the role-holding ones - as long as there are others
in the environment.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.com <x-excid://32770000/uri:http:/www.akomolafe.com> -
we know IT
**-5.75, -3.23**
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
------------------------------------------------------------------------
*From:* joe
*Sent:* Thu 8/17/2006 12:25 PM
*To:* [email protected]
*Subject:* RE: [ActiveDir] FMSO roles split, patch question.
That is fine Deji, you can completely disagree as much you want, it
wouldn't be the first time we haven't agreed. :)
BTW, I never said Best Practice, I said this is what I do and I agree
with Jorge. But in the end, I don't care about best practices, I do
what I think is right and the least likely to cause me issues balanced
by my efficiency of doing things.
You could test something to within an inch of its existence and
something still go wrong in production, there is no way to guarantee
no issues will occur, that is why we test in the first place. If it
could be guaranteed, MSFT would have already done so. So you can put
your faith in god all you want but it is prudent to row away from the
rocks as well.
I am confused as to what disadvantage there is to moving roles? You
seem to be saying since it isn't troublesome to seize them you
shouldn't tranfer them. That is cracked.
Note that I don't say do this just for patching, any reboot or machine
specific core change and I will move the roles. It could be something
completely unrelated to a patch that caused a failure, especially in a
reboot situation. It is such an innocuous thing to do that can save
concern and work in the event of a failure. I think if it is easy to
do up front, it seems outright stupid to not move the roles and remove
all possibility of an issue around them. If I had a DC fail while
doing maintenance work, I don't want to have to have made up issues
for me to deal with around it, just get the DC working again. I can
guarantee you several large companies that I have done work for would
all question the process if I didn't do everything I could to limit
possible issues up front.
I would argue, and have in the past argued, that a seize is not as
good as a tranfer regardless of your thoughts on the topic. If that
weren't the case, it is probably likely there wouldn't be two methods
in the first place. Even now there doesn't really need to be two
methods, you could have one method for transfer and if that fails it
does the seize but they specifically want you realizing you are
seizing. Even if this weren't the case, I would STILL move the roles
because it is simple and innocuous and fast.
In the end, you can do anything you want to to manage your
environments as you see fit, but any environment I run will be handled
as I indicated. I see it as such free insurance that is silly not to buy.
Let me leave you with a scenario, feel free not to respond if you want.
You and I are working on our enterprise environments. We need to patch
or do something else which will require a reboot. I go ahead and
quickly move the roles and you just go forward in patching, I am slow
that day so it takes 30 seconds instead of 15 seconds to move roles
and then I am patching. You obviously hit reboot first, uh no, the
reboot hangs up or the server doesn't reboot or doesn't even POST. 30
seconds later I see the same thing... Assuming we built out Domain
Controller Architecture properly what happens next?
I go, well that sucks, I will have to fix that at some time and
determine when I will make time for it and decide if I will
troubleshoot and correct or just wipe and reload.
You go, *&[EMAIL PROTECTED] <mailto:*&[EMAIL PROTECTED]>. Do I fix this or do I seize
the roles and you think about it while I am getting in my jeep and
driving to meet friends or have lunch or dinner. (or alternately maybe
some more junior admin makes the WRONG decision without you there..)
Once you finally decide what direction you go, you then know what you
can properly do. In the meanwhile, your decision may get pushed as
users and admins start noticing things aren't as they should be. The
GPO management tools are bitching about which machine they should talk
to. Users changing passwords via tools using legacy API (yes they
still exist even if clients don't) are all breaking. Password chaining
isn't working for anyone that changed their passwords. Who knows what
else is going on, you get to figure it out. I am drinking my second
Labatt's not having to make any difficult decisions.
All over a 15 second process handled by a batch file that took what
maybe 30-60 minutes to write.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Deji Akomolafe
*Sent:* Thursday, August 17, 2006 1:53 PM
*To:* [email protected]
*Subject:* RE: [ActiveDir] FMSO roles split, patch question.
I completely disagree with you. I understand the thinking behind the
move-roles-before-patch stance. I just don't buy into it. Test patch
and be sure it doesn't kill things. Test your config changes and be
sure it doesn't break things. Test, test and test more before you move
into production.
Then deploy to production. IF, in spite of all your tests, "something"
goes wrong with one DC holding a specific role (or - perish the
thought - ALL your roles), it's no big deal. As long as you have other
DCs available to assume the roles, the target DCwill not care how they
got the roles (graceful transfer or inelegant seizure).
It's good to have a script that moves roles as you desire, but this
does not fall into the realm of "best practice" in the scheme of
things. Your energy should be invested in instituting a comprehensive
patch/change management and testing operations practice rather than
figuring out where to move roles to in case a patch eats your DC.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.com <x-excid://32770000/uri:http:/www.akomolafe.com> -
we know IT
**-5.75, -3.23**
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
------------------------------------------------------------------------
*From:* joe
*Sent:* Thu 8/17/2006 9:31 AM
*To:* [email protected]
*Subject:* RE: [ActiveDir] FMSO roles split, patch question.
I completely concur with Jorge on his process.
It takes a lot less hassle and a lot less feeling of concern to move a FSMO
prior to an update of a machine than to have to seize the role later
regardless of the reason of it going down. Especially when you have a script
that applies the NTSUTIL commands to move the roles. A move of all roles in
a properly scripted environment is a procedure that takes all of about 10-15
seconds. A seize on the other hand isn't something you should just quickly
think about doing, you need to work out the consequences and make a
determination in most cases whether or not you will ever bring that DC back
up as it stands now. It is, IMO, a no-brainer if you have multiple DCs as it
is isn't any real workload or concern to do it.
When I am doing production ops I *always* move roles prior to making machine
specific updates. I never assume a server is going to come back up after I
say restart or in fact even go down properly without hanging.
Now I understand the SBS thoughts behind it though... In the SBS world if
you lost the DC, you have far greater issues than you lost a FSMO role for
the moment. In the world outside of SBS, most people look at DCs as
expendable. You set up 10 of them in front of you and 5 fell down you would
be like, crap, I will have to fix those at some point. You set up an SBS DC
and it falls over there are skid marks where you were previously standing.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Thursday, August 17, 2006 11:48 AM
To: [email protected]
Subject: Re: [ActiveDir] FMSO roles split, patch question.
As a person who tests/patches a bunch of single DCs.... I've never seen
a "patch" kill a server.
Driver update may and has, yes.
Impair functionality of the server, yes.
But kill it completely? Microsoft tests patches ahead of time and they
would find ahead of time if basic functionality of a DC would be nailed.
But if the server dies... it was probably on the emergency list prior to
patching. Rebooting the box first ensures that you find these 'hospital
bound' servers.
Almeida Pinto, Jorge de wrote:
> the reason is that is a DC dies during the patching you do not have to
seize the roles....IMHO, I prefer transfering over seizing
>
> Met vriendelijke groeten / Kind regards,
> Ing. Jorge de Almeida Pinto
> Senior Infrastructure Consultant
> MVP Windows Server - Directory Services
>
> LogicaCMG Nederland B.V. (BU RTINC Eindhoven)
> ( Tel : +31-(0)40-29.57.777
> ( Mobile : +31-(0)6-26.26.62.80
> * E-mail : <see sender address>
>
> ________________________________
>
> From: [EMAIL PROTECTED] on behalf of John Strongosky
> Sent: Thu 2006-08-17 16:55
> To: [email protected]
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> I cornfused is this a standard practice as I thought you did not want to
move the FMSO roles back and forth.
>
> john
>
> ________________________________
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto,
Jorge de
> Sent: Thursday, August 17, 2006 4:33 AM
> To: [email protected]
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> in addition to that....
> DC1 having FSMOset1 and DC2 having FSMOset2
> transfer FSMOset1 from DC1 to DC2
> apply patches to DC1 and reboot and check everything (event logs DCdiag,
etc)
> if everything OK!
> transfer FSMOset1 and FSMOset2 from DC2 to DC1
> apply patches to DC2 and reboot and check everything (event logs DCdiag,
etc)
> if everything OK!
> transfer FSMOset2 from DC1 to DC2
> voila (that's french)...done! ;-)
>
> jorge
>
>
>
> ________________________________
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
> Sent: Wednesday, August 09, 2006 01:52
> To: [email protected]
> Subject: RE: [ActiveDir] FMSO roles split, patch question.
>
>
> It doesn't matter.
>
>
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.com - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
>
> ________________________________
>
> From: John Strongosky
> Sent: Tue 8/8/2006 4:49 PM
> To: [email protected]
> Subject: [ActiveDir] FMSO roles split, patch question.
>
>
> We have our FMSO roles split between 2 dc's. They are Schema
Master/Domain Tree Operator on 1 and on 2, the roles PDC Emulator/Rid
Pool/Intrastate on the other. After I apply the patches from Microsoft what
is the beat practices for the boot order...or does it matter?
>
> 1. Remote DC/GC's first
> 2. no. 1
> 3. then no 2.
>
>
> thanks
>
>
>
>
>
>
> 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.
>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will
hunt you down...
http://blogs.technet.com/sbs
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
