It can be. It's easily scripted. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Wednesday, November 30, 2005 4:39 PM To: [email protected] Subject: Re: [ActiveDir] FSMO role transfer
That's my point. If this is .....according to some of the threads on this, it is normal, regular, and part of a risk management process to just move these roles around, yes? Why not one click? Cace, Andrew wrote: > It is available in the AD snap-ins. In AD Domains & Trusts, you can > transfer the Domain Naming master by right-clicking the name of the snap-in > in tree-view and choosing Operations Master. In ADUC, right-click the name > of the domain and choose Operations Master to transfer the RID, PDC, and > Infrastructure masters. In the Schema Management snapin, you can transfer > the Schema master by right-clicking Active Directory Schema and choosing > Operations Master. > > Next question...Why isn't there a single place to click all of these? > > -Andrew > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA > aka Ebitz - SBS Rocks [MVP] > Sent: Wednesday, November 30, 2005 3:09 PM > To: [email protected] > Subject: Re: [ActiveDir] FSMO role transfer > > <stupid question alert> > > If the task is that trivial > If the benefit is so great > Why isn't it part of the AD snap ins as a one button task? > > <sincerely, who needs scripting when you can ask for a gui/wizard or button > instead> > > David Adner wrote: > >> I'm not debating the effort it takes to make the change. I'm saying I >> don't see the point in devoting whatever amount of effort it takes for >> something that's going to provide benefit only, IMO, an extremely rare >> case. And if that case happened, the corrective action is also a >> trivial process. And again, I'm not saying I don't see your point; I just >> > don't agree with it. > >> >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Bahta >>> Nathaniel V Contractor NASIC/SCNA >>> Sent: Wednesday, November 30, 2005 12:32 PM >>> To: [email protected] >>> 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: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of David Adner >>> Sent: Wednesday, November 30, 2005 1:24 PM >>> To: [email protected] >>> 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: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On Behalf Of >>>> [EMAIL PROTECTED] >>>> Sent: Wednesday, November 30, 2005 10:16 AM >>>> To: [email protected] >>>> 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: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Susan >>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP] >>>> Sent: 30 November 2005 15:29 >>>> To: [email protected] >>>> 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. >>>> >>>> [EMAIL PROTECTED] 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:* [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] *On Behalf Of >>>>> >>>>> >>>> *David Adner >>>> >>>> >>>>> *Sent:* 29 November 2005 23:26 >>>>> *To:* [email protected] >>>>> *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:* [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] *On >>>>> >>>>> >>> Behalf Of *Rich >>> >>> >>>>> Milburn >>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM >>>>> *To:* [email protected] >>>>> *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:* [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] *On Behalf Of >>>>> [EMAIL PROTECTED] >>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM >>>>> *To:* [email protected] >>>>> *Subject:* Re: [ActiveDir] FSMO role transfer >>>>> >>>>> If something went wrong you could still seize the FSMO >>>>> >>>>> >>>> roles as an >>>> >>>> >>>>> option rather than doing a transfer. Of course the >>>>> >>>>> >>>> procedures for >>>> >>>> >>>>> all of these for the 5 FSMOs should be documented just in case >>>>> needed.. >>>>> >>>>> Chuck >>>>> >>>>> / >>>>> >>>>> >>>>> >>>> -------------------------------------------------------------- >>>> ---------- >>>> >>>> >>>>> *-------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY >>>>> >>>>> >>>> NOTICE-------* >>>> >>>> >>>>> PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this >>>>> message or any attachments. This information is strictly >>>>> confidential and may be subject to attorney-client >>>>> >>>>> >>>> privilege. This >>>> >>>> >>>>> message is intended only for the use of the named >>>>> >>>>> >>> addressee. If >>> >>> >>>>> you are not the intended recipient of this message, >>>>> >>>>> >>> unauthorized >>> >>> >>>>> forwarding, printing, copying, distribution, or using such >>>>> information is strictly prohibited and may be unlawful. If you >>>>> have received this in error, you should kindly notify >>>>> >>>>> >>> the sender >>> >>> >>>>> by reply e-mail and immediately destroy this message. >>>>> >>>>> >>>> Unauthorized >>>> >>>> >>>>> interception of this e-mail is a violation of federal criminal >>>>> law. Applebee's International, Inc. reserves the right >>>>> >>>>> >>>> to monitor >>>> >>>> >>>>> and review the content of all messages sent to and from this >>>>> e-mail address. Messages sent to or from this e-mail >>>>> >>>>> >>> address may >>> >>> >>>>> be stored on the Applebee's International, Inc. >>>>> >>>>> >>> e-mail system./ >>> >>> >>>>> >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> - >>> >>> >>>>> -- >>>>> >>>>> PLEASE READ: The information contained in this email is >>>>> >>>>> >>>> confidential >>>> >>>> >>>>> and intended for the named recipient(s) only. If you are not an >>>>> intended recipient of this email please notify the sender >>>>> >>>>> >>>> immediately >>>> >>>> >>>>> and delete your copy from your system. You must not copy, >>>>> >>>>> >>>> distribute >>>> >>>> >>>>> or take any further action in reliance on it. Email is >>>>> >>>>> >>> not a secure >>> >>> >>>>> method of communication and Nomura International plc >>>>> >>>>> >>> ('NIplc') will >>> >>> >>>>> not, to the extent permitted by law, accept responsibility or >>>>> liability for (a) the accuracy or completeness of, or (b) >>>>> >>>>> >>>> the presence >>>> >>>> >>>> >>>>> of any virus, worm or similar malicious or disabling code >>>>> >>>>> >>> in, this >>> >>> >>>>> message or any attachment(s) to it. If verification of this >>>>> >>>>> >>>> email is >>>> >>>> >>>>> sought then please request a hard copy. Unless otherwise >>>>> >>>>> >>> stated this >>> >>> >>>>> email: (1) is not, and should not be treated or relied upon as, >>>>> investment research; (2) contains views or opinions that >>>>> >>>>> >>> are solely >>> >>> >>>>> those of the author and do not necessarily represent >>>>> >>>>> >>> those of NIplc; >>> >>> >>>>> (3) is intended for informational purposes only and is not a >>>>> recommendation, solicitation or offer to buy or sell >>>>> >>>>> >>> securities or >>> >>> >>>>> related financial instruments. NIplc does not provide investment >>>>> services to private customers. Authorised and regulated by the >>>>> Financial Services Authority. Registered in England no. >>>>> >>>>> >>> 1550505 VAT >>> >>> >>>>> No. 447 2492 35. Registered Office: 1 St >>>>> >>>>> >>> Martin's-le-Grand, London, >>> >>> >>>>> EC1A 4NP. A member of the Nomura group of companies. >>>>> >>>>> >>>> List info : http://www.activedir.org/List.aspx >>>> List FAQ : http://www.activedir.org/ListFAQ.aspx >>>> List archive: >>>> http://www.mail-archive.com/activedir%40mail.activedir.org/ >>>> >>>> >>>> >>>> PLEASE READ: The information contained in this email is >>>> >>>> >>> confidential >>> >>> >>>> and intended for the named recipient(s) only. If you are not an >>>> intended recipient of this email please notify the sender >>>> >>>> >>> immediately >>> >>> >>>> and delete your copy from your system. >>>> You must not copy, distribute or take any further action in >>>> >>>> >>> reliance >>> >>> >>>> on it. Email is not a secure method of communication and Nomura >>>> International plc ('NIplc') will not, to the extent >>>> >>>> >>> permitted by law, >>> >>> >>>> accept responsibility or liability for (a) the accuracy or >>>> completeness of, or (b) the presence of any virus, worm or similar >>>> malicious or disabling code in, this message or any >>>> >>>> >>> attachment(s) to >>> >>> >>>> it. If verification of this email is sought then please >>>> >>>> >>> request a hard >>> >>> >>>> copy. Unless otherwise stated this email: (1) is not, and >>>> >>>> >>> should not >>> >>> >>>> be treated or relied upon as, investment research; (2) >>>> >>>> >>> contains views >>> >>> >>>> or opinions that are solely those of the author and do not >>>> >>>> >>> necessarily >>> >>> >>>> represent those of NIplc; (3) is intended for informational >>>> >>>> >>> purposes >>> >>> >>>> only and is not a recommendation, solicitation or offer to >>>> >>>> >>> buy or sell >>> >>> >>>> securities or related financial instruments. NIplc does >>>> >>>> >>> not provide >>> >>> >>>> investment services to private customers. Authorised and >>>> >>>> >>> regulated by >>> >>> >>>> the Financial Services Authority. Registered in England no. >>>> 1550505 VAT No. 447 2492 35. Registered Office: 1 St >>>> Martin's-le-Grand, London, EC1A 4NP. A member of the >>>> >>>> >>> Nomura group of >>> >>> >>>> companies. >>>> >>>> List info : http://www.activedir.org/List.aspx >>>> List FAQ : http://www.activedir.org/ListFAQ.aspx >>>> List archive: >>>> http://www.mail-archive.com/activedir%40mail.activedir.org/ >>>> >>>> >>> List info : http://www.activedir.org/List.aspx >>> List FAQ : http://www.activedir.org/ListFAQ.aspx >>> List archive: >>> http://www.mail-archive.com/activedir%40mail.activedir.org/ >>> List info : http://www.activedir.org/List.aspx >>> List FAQ : http://www.activedir.org/ListFAQ.aspx >>> List archive: >>> http://www.mail-archive.com/activedir%40mail.activedir.org/ >>> >>> >> List info : http://www.activedir.org/List.aspx >> List FAQ : http://www.activedir.org/ListFAQ.aspx >> List archive: >> http://www.mail-archive.com/activedir%40mail.activedir.org/ >> >> >> > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > -- Letting your vendors set your risk analysis these days? http://www.threatcode.com List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
