Perfect World= clone all servers, workstations, users (especially the stupid ones that break things all the time anyway) Install patches on the identical cloned network, when cloned users break things beat them so they never do the stupid act again. (okay so maybe this is just a network admin's view of a perfect cloning experiment --- it might be better to beat the real users come to think of it...)

Best = set up a test network with real hardware that replicates the types/kinds of equipment you have

Better = test up test network with mixtures of real/virtual

Good = test network is virtual, recreate apps, etc.

Better than nothing option 1= users that are "canaries".. they get patches first... they die so that others will live

Better than nothing option 2= break the mirror, patch the main, ensure all is well remirror (I'm personally not a fan of this...but...)

Bottom line even in testing ...you won't find everything. True story: I patched for a chm help file patch back in 2005, all looked fine, and I deployed the patch. Two weeks later someone pinged me that they couldn't get into the Tax software help file.... it was suddenly blank. When I right mouse clicked on the suddenly blank page I realized it was a chm file and went.... oh...hang on.... there was a patch... Contacted the vendor and sure 'nuff, they already knew about it and had a workaround. So just plan on the fact that somethings just won't be noticeable until it's in a live network and deal with it.

joe wrote:
It isn't the best test environment but it is infinitely better than no test environment. If you have a QA environment that matches production then I am perfectly fine with an entirely virtual test environment. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Rocky Habeeb
*Sent:* Saturday, August 19, 2006 10:36 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] FMSO roles split, patch question.

Oh ...
So virtual is where my test environment should be ...
And that will adequately equate to a "real" production environment?
["Hmmmmmm ..." he wonders, "Could it be true?"]
_____________________________________________
    -----Original Message-----
    *From:* [EMAIL PROTECTED]
    [mailto:[EMAIL PROTECTED] Behalf Of *Deji
    Akomolafe
    *Sent:* 17 August, 2006 4:45 PM
    *To:* ActiveDir@mail.activedir.org
    *Subject:* RE: [ActiveDir] FMSO roles split, patch question.

    That argument went out the window when the following happened:
Dell started selling desktops with jillion gigabyte drive space
    for under $1000
    Microsoft started giving away Virtual Server with very liberal
    Windows Server 2003 licenses.
Us poor admins no longer needed bazillion dollars to create "test
    environments".
Sorry, try another one :)

    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:* Gordon Pegue
    *Sent:* Thu 8/17/2006 1:31 PM
    *To:* ActiveDir@mail.activedir.org
    *Subject:* RE: [ActiveDir] FMSO roles split, patch question.

    What about us poor admins, who for a variety of reasons outside
    their control, don't have a "test" environment?
    I'm just a little guy, supporting a small business that doesn't
    have kilobucks to spare for non-production equipment.
I sweat bullets every time MS issues updates and I spend a lot of
    time researching each and every one of them before I apply...
    Thanks
    Gordon Pegue
    System Administrator
    Chavez Grieves Consulting Engineers
    Albuquerque, NM
    www.cg-engrs.com
        ------------------------------------------------------------------------
        *From:* [EMAIL PROTECTED]
        [mailto:[EMAIL PROTECTED] *On Behalf Of
        *Deji Akomolafe
        *Sent:* Thursday, August 17, 2006 11:53 AM
        *To:* ActiveDir@mail.activedir.org
        *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:* 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

Reply via email to