Rocky - keep in mind that a typical "Admin" job in a big company is user administration, computer account administration, patching member servers, checking backup logs, and various other routine administration (hence "Admin") - and tricky things get passed up the chain to level 2. In a mid-size or small company, some jobs titled "Admin" should really be titled "Engineer" or "Analyst" because they do things like Exchange troubleshooting, replication troubleshooting, hardware upgrade planning, etc as well as the occasional user account issue, etc. He's talking (forgive me Joe if I misinterpret here) about the former, your classic Admin who hopefully doesn't have much rights and takes day-to-day administrative tasks. There are probably not a lot of those people on this list. There is the possibility though that some admin Admins do spend the whole day in deep concentration over creating and modifying individual user accounts, etc... nuff said about that. But for the do-all mis-titled Admin/Engineer, if you're spending all your time handling routine admin tasks and can't be proactive with more of the engineering stuff - well eventually (and more commonly nowadays) you are going to need to pick up scripting or some way of automating things (as Tom has found), or someone else will get hired who can.
Rich ----------------------------------------------------------------------- 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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb Sent: Thursday, December 01, 2005 9:29 AM To: [email protected] Subject: RE: [ActiveDir] FSMO role transfer joe, I can't believe you said this. "Rarely are admins ever really doing hard admin type thinking/troubleshooting work constantly except for the folks who take on escalations from lower level admins." I stopped reading after this. Sorry. But I've got to cool down first. I've no argument with anything above this line and I concur and understand. >BUT< This is flat out wrong. Sorry. YMYMYM RH ___________________________________________- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of joe Sent: Thursday, December 01, 2005 9:52 AM To: [email protected] Subject: RE: [ActiveDir] FSMO role transfer Wow I feel heat directed at me.... :o) A non-scripting admin can not survive very well if at all in a large org unless the org is willing to spend a lot of money for extra admins to cover the overhead of wading through the GUI. Take my last ops position as an example. Three people handling a Fortune 5 AD. Couldn't feasibly done with the GUI. How long does it take you to enter 100 new subnets? What if you need to expire 8,000 users a day until you have expired all 200,000 users? Is that real admin work or is it clerk work if you are simply clicking on something in a GUI? If I were a manager of a business, I would rather pay a contractor or other service $10 or $15 an hour to click buttons for something like that than pay $40,$60,$100, $150 an hour to someone who is supposed to keep things running. So back to the 100 subnets question. How long in Sites and Services? Hours? What are the chances of a mistake? High? Now you write a script to do it, how long? Maybe hours to write it and then seconds to minutes to run for ever after? Chances of a mistake? Low for entry, also severely reduced for supplied data if script has sanity checks in it? Also once in script form it is that much easier to say put on a web site and delegate to others to do by entering basic answers to basic questions in a form. Don't create 100 subnets in small org? What other items do you do that are no-brainer work that could be scripted. If you didn't have that workload how much other work could you get done? Rarely are admins ever really doing hard admin type thinking/troubleshooting work constantly except for the folks who take on escalations from lower level admins. Possibly this is different in the SBS world and there is no repetitive work being done that isn't better served by a script, I don't have that experience, I would expect however that there is quite a bit that could be scripted or else Susan wouldn't have the I would rather see something safe from MS than a script from someone in the backroom attitude. A saying I have used here in the past that I always used at work is that you can't be too busy cutting down trees to sharpen your axe. It applies both to training and scripting. If you are too busy to do nothing but the work in front of you, you will never see the edge of the forest as you get slower and slower at doing what you are doing. At some point you have to step back and spend some time to make yourself more informed or more efficient. The more time you spend getting more efficient, the more time you have to keep yourself informed and get even more efficient. Finally scripting requires understanding of how things are working, using the GUI doesn't. Trying to script processes forces a person to learn more about the product they are supporting and could very likely get them to learn enough that the next time they encounter a failure, they fully or at least more fully troubleshoot versus changing things in the GUI until it works. If you look at an admin making $35k a year versus one making $60k a year versus one making $80k a year versus one making $150k a year versus one making over $240k a year you are probably not looking at a raise in salary because someone knows the GUI better than the others. If you see someone who rose through those salary ranks in say 5 years, it isn't because they knew the GUI keyboard shortcuts. Understanding scripting makes you more valuable both because you can operate more efficiently and because you "tend" to have a better grasp of how things work because you are forced to learn the details which are covered by the GUI. Not only that, you can troubleshoot better because you have more options to you. I recently ran into an issue where someone entered a bad value for a DL expansion server. The value was so bad the GUI didn't even display it, instead it said the DL had no expansion server. The admin I was helping actually told me I was wrong when I said it was set and it was in fact set incorrectly because the GUI said it wasn't set. That is kind of scary to me. The GUI is an interpretation of what is there. Don't trust it that much. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb Sent: Wednesday, November 30, 2005 5:18 PM To: [email protected] Subject: RE: [ActiveDir] FSMO role transfer Susan, "THANK YOU !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!! !!!!!!!!!!!" There are a >LOT< of people on this list that do not believe that real Admins use the GUI. Some believe that you're not a real Admin if you do. I do. I have to. I can't allocate time to learn scripting right now because I'm overworked as is. I'll just leave it at that. RH ______________________________________________ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Wednesday, November 30, 2005 4: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/ 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/ -------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. 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/
