RE: [ActiveDir] FSMO role transfer

[joe]

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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 3:58 AM To: ActiveDir@mail.activedir.org Subject: 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Adner Sent: 29 November 2005 23:26 To: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org 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: ActiveDir@mail.activedir.org 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.