Minutes to hours. Depends on what exactly is going on. If it was heavy
maintanence do it as far as you want in advance, if rolling through applying
patches move the role, patch the server, move the role back. Depending on
how many patches and the reboot times it could be less than 5 minutes with
two FSMO moves in that time frame. The environment will be fine.

The worst role to move is the PDC role and that is simply because it is a
target for various things but moving the PDC role in 2K is so much
incredibly nicer than it was in NT4 and I don't hesitate to move it now.
Under NT4 there were many times I would sit there and wonder, what is going
to screw up when I do this. And yes, many people will sit back and go huh,
there was no problem doing that in NT4... Trust me, in very large NT domains
(>60k users[1] and hundreds of WAN based BDCs) it could get tricky. More
than once I saw a PDC role transfer result in two hung servers that had to
be hard reset. 

Once you move the role, if you are worried, simply take a peek at the DNS
records to make sure the PDC record was updated and make sure the WINS 1B
record reflects the new PDC and everything is good. Most legacy functions
that need the PDC will ask for the 1B record and then hit the server listed
and ask, hey are you the PDC? If the response comes back as negative, the
machine will get the entire 1C record and send the request to every DC
listed in the 1C record (25 machines) and probably find it that way. If it
doesn't the call will fail and you will get, couldn't find the PDC or
couldn't find the domain. The one time I recall troubleshooting that for
someone they had moved the PDC role to a machine that wasn't properly
configured for WINS or it was actually incorrectly running the WINS Service
or something like that. It was a dee de dee move on the part of some admin
that caused the issue, not anything technical. 


  joe


[1] While there was a recommended limit of no more than 40k users in a
domain in NT4 I stumbled into an environment that people hadn't been paying
attention and had 3 domains over that limit, ~65k, ~85k and ~110k. It works,
you just burn a PS/2 Token Ring card every morning in an offering to the IT
gods... 


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Strongosky
Sent: Thursday, August 17, 2006 12:50 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FMSO roles split, patch question.

Whets the time interval on moving these before you patch the DC's that the
roles were on.

john

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Thursday, August 17, 2006 9:32 AM
To: ActiveDir@mail.activedir.org
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: ActiveDir@mail.activedir.org
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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
> 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: ActiveDir@mail.activedir.org
>       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: ActiveDir@mail.activedir.org
>       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
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

Reply via email to