| Author | Messages | |
debbie.ellis@xxxx.yyy
 | | 12/01/2005 7:15 AM |
| Your links did not work
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Lou Vega
Sent: Thursday, December 01, 2005 11:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
Hey Rich - no need to script one yourself....Robbie's cookbook recipe 3.25
and 3.26 deal nicely with FSMO roles.
3.26 contains VBScript and Perl to transfer FSMO roles.
http://www.rallenhome.com/books/adcookbook/code.html
http://www.rallenhome.com/books/adcookbook/src/03.25-find_fsmos.vbs.txt
http://www.rallenhome.com/books/adcookbook/src/03.26-transfer_fsmo.vbs.txt
r/
Lou
-----Original Message-----
>I was curious to see, with all these posts, no one ponied up with a real
>script to help out all these folks who are 1) not scripters and 2)
>amazed that moving the roles could be that easy. (I would post one but I
>have not actually scripted this... it's not currently my job :)
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/ | | | |
| AD000001161
Posts:0
| | 12/01/2005 7:29 AM |
| Joe, the comment was that TRANSFERRING the roles would be something trivial to do, not seizing the roles. I also agree, scripting is the difference between an admin who knows where to click, and an admin who knows what is going on when he clicks, when his mouse takes focus in the window, when the cursor hovers over a selection, etc, etc. Scripting may be like in the end of the Matrix when Neo sees all the green and black monochrome code when he looks around, a point in time where you can see the world around you for the code it is, and then you are able to master all aspects of it. It all depends on what pill these admins want to swallow.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Thursday, December 01, 2005 10:06 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
I am not completely on board with a seize being trivial.
Sure it is trivial in the act of doing it, but do you fully understand what is going on under the covers? With a FSMO transfer you are going from a known state to a known state in a controlled fashion. The new roleholder can talk to the old roleholder and understand EXACTLY what is going on so have a seamless move. A seize is going from an unknown state to a known state. For a role that doesn't have a state to worry about which is most of them, that is fine. But the RID master definitely has state and to a lesser extent so does the PDC master. Seizing a role isn't just a simple matter of popping in a value into an attribute and saying "Done!". Well it could be, but you could get burned if that is all you do.
I agree that it will be tough to convince one group to do something the other way. I do hope though that people think about what has been written and don't think seizing a role is trivial because the command to do it is easy to run. I am glad it is easy, the last thing you want is for a hard process to be required to rescue your system when you have issues.
On the comment that transferring roles isn't a normal operating procedure.
Maybe not in some places but it is a perfectly normal operating procedure, certainly more standard or normal than a seize. Transferring the PDC role in NT could be a bit painful at times but it is easy as pie in AD. I recall having a couple of occasions in the very beginning (first half 2000) where I got a trifle nervous at first from previous NT issues but quickly got over it. I don't think twice about moving roles. Heck we didn't even have to submit change control for that, we would just move the roles and send an email to the change list saying it had been done. It was considered SOP for maintaining domain operations.
Finally and the last I will say about it... for the longest time and maybe even still I haven't looked lately MS said that the seize was the course of last resort, use it when the transfer fails. I realize MS warns about a lot of things but usually they have some basis for doing so. And if that isn't enough... if seizing roles was such a non-item, why wouldn't you just have a seize operation? Why have a transfer and a seize and cause this confusion?
If they were the same, wouldn't you just have a single move the role button and no other mechanism whatsoever?
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Figueroa, Johnny
Sent: Wednesday, November 30, 2005 4:53 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
I think what was meant about the "trivial" part is around the seizing of the roles not the transfer. I would love to have much of the ntdsutil functionality built into the UI, even if at some point it requires you to reboot/restore, whatever.
I don't think either camp is going to convince the other that you should or shouldn't transfer roles prior to some maintenance. It is almost a personality thing. I prefer not to transfer the role and deal with the possibility that I may need to seize it, on the rare case that something goes drastically wrong that I can not recover from before the role is actually needed. You architected the roles on specific DCs for a reason, if I forget to move it back I may end up with a DC hosting a role for a long time that I never meant to. Also, I don't consider transferring roles around part of the normal operating procedures.
But that's just me.
Thanks
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Cace, Andrew
Sent: Wednesday, November 30, 2005 2:26 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
Sent: Wednesday, November 30, 2005 3:09 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] FSMO role transfer
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?
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta
>> Nathaniel V Contractor NASIC/SCNA
>> Sent: Wednesday, November 30, 2005 12:32 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
>> Sent: Wednesday, November 30, 2005 1:24 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
>>> neil.ruston@xxxxxxxxxxxxx
>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>> Sent: 30 November 2005 15:29
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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.
>>>
>>> neil.ruston@xxxxxxxxxxxxx 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>
>>> *David Adner
>>>
>>>> *Sent:* 29 November 2005 23:26
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On
>>>>
>> Behalf Of *Rich
>>
>>>> Milburn
>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>> *ChuckGaff@xxxxxxx
>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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/ | | | |
| lvega@xxxx.yyy
| | 12/01/2005 8:05 AM |
| The links might have wrapped...a casualty of the mail system - in either
case go direct to rallenhome.com and follow the hyperlinks from there down
to the book's source code, and then to those recipes.
Hope that helps!
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ellis, Debbie
Sent: Thursday, December 01, 2005 1:46 PM
To: 'ActiveDir@xxxxxxxxxxxxxxxxxx'
Subject: RE: [ActiveDir] FSMO role transfer
Your links did not work
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Lou Vega
Sent: Thursday, December 01, 2005 11:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
Hey Rich - no need to script one yourself....Robbie's cookbook recipe 3.25
and 3.26 deal nicely with FSMO roles.
3.26 contains VBScript and Perl to transfer FSMO roles.
http://www.rallenhome.com/books/adcookbook/code.html
http://www.rallenhome.com/books/adcookbook/src/03.25-find_fsmos.vbs.txt
http://www.rallenhome.com/books/adcookbook/src/03.26-transfer_fsmo.vbs.txt
r/
Lou
-----Original Message-----
>I was curious to see, with all these posts, no one ponied up with a real
>script to help out all these folks who are 1) not scripters and 2)
>amazed that moving the roles could be that easy. (I would post one but I
>have not actually scripted this... it's not currently my job :)
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/ | | | |
| AD000001404
Posts:0
| | 12/01/2005 8:10 AM |
| | Message body was not found. | | | |
| kamleshap
Posts:58
| | 12/01/2005 9:30 AM |
| admin didn't transfer the roles, and went about maintenance,
found it didn't work out and time is running out, so let me seize the
role, (its only trivial command).
And meanwhile, the first role holder is back into network and declaring the ownership.
And this ownership war went unnoticed by admin for a day or two.
What kind of trouble we can expect?
anything role specific?
on replication ?
on authentication ?
on overall health of AD?
I think, asking & answering questions along the same line, would surely put the decision into more perspective.
-
Kamlesh
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~On 12/1/05, joe wrote:
I am not completely on board with a seize being trivial.Sure it is trivial in the act of doing it, but do you fully understand whatis going on under the covers? With a FSMO transfer you are going from aknown state to a known state in a controlled fashion. The new roleholder can
talk to the old roleholder and understand EXACTLY what is going on so have aseamless move. A seize is going from an unknown state to a known state. Fora role that doesn't have a state to worry about which is most of them, that
is fine. But the RID master definitely has state and to a lesser extent sodoes the PDC master. Seizing a role isn't just a simple matter of popping ina value into an attribute and saying "Done!". Well it could be, but you
could get burned if that is all you do.I agree that it will be tough to convince one group to do something theother way. I do hope though that people think about what has been writtenand don't think seizing a role is trivial because the command to do it is
easy to run. I am glad it is easy, the last thing you want is for a hardprocess to be required to rescue your system when you have issues.On the comment that transferring roles isn't a normal operating procedure.
Maybe not in some places but it is a perfectly normal operating procedure,certainly more standard or normal than a seize. Transferring the PDC role inNT could be a bit painful at times but it is easy as pie in AD. I recall
having a couple of occasions in the very beginning (first half 2000) where Igot a trifle nervous at first from previous NT issues but quickly got overit. I don't think twice about moving roles. Heck we didn't even have to
submit change control for that, we would just move the roles and send anemail to the change list saying it had been done. It was considered SOP formaintaining domain operations.Finally and the last I will say about it... for the longest time and maybe
even still I haven't looked lately MS said that the seize was the course oflast resort, use it when the transfer fails. I realize MS warns about a lotof things but usually they have some basis for doing so. And if that isn't
enough... if seizing roles was such a non-item, why wouldn't you just have aseize operation? Why have a transfer and a seize and cause this confusion?If they were the same, wouldn't you just have a single move the role button
and no other mechanism whatsoever?-----Original Message-----From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Figueroa, JohnnySent: Wednesday, November 30, 2005 4:53 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] FSMO role transfer
I think what was meant about the "trivial" part is around the seizing of theroles not the transfer. I would love to have much of the ntdsutilfunctionality built into the UI, even if at some point it requires you to
reboot/restore, whatever.I don't think either camp is going to convince the other that you should orshouldn't transfer roles prior to some maintenance. It is almost apersonality thing. I prefer not to transfer the role and deal with the
possibility that I may need to seize it, on the rare case that somethinggoes drastically wrong that I can not recover from before the role isactually needed. You architected the roles on specific DCs for a reason, if
I forget to move it back I may end up with a DC hosting a role for a longtime that I never meant to. Also, I don't consider transferring roles aroundpart of the normal operating procedures.But that's just me.
Thanks-----Original Message-----From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] On Behalf Of Cace, AndrewSent: Wednesday, November 30, 2005 2:26 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] FSMO role transferIt 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-inin tree-view and choosing Operations Master. In ADUC, right-click the nameof the domain and choose Operations Master to transfer the RID, PDC, and
Infrastructure masters. In the Schema Management snapin, you can transferthe Schema master by right-clicking Active Directory Schema and choosingOperations Master.Next question...Why isn't there a single place to click all of these?
-Andrew-----Original Message-----From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] On Behalf Of Susan Bradley, CPAaka Ebitz - SBS Rocks [MVP]Sent: Wednesday, November 30, 2005 3:09 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] FSMO role transfer
If the task is that trivialIf the benefit is so greatWhy isn't it part of the AD snap ins as a one button task?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> justdon't agree with it.>>>> -----Original Message-----
>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta
>> Nathaniel V Contractor NASIC/SCNA>> Sent: Wednesday, November 30, 2005 12:32 PM>> To: ActiveDir@xxxxxxxxxxxxxxxxxx>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
>> Sent: Wednesday, November 30, 2005 1:24 PM>> To: ActiveDir@xxxxxxxxxxxxxxxxxx>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx>>> [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of>>> neil.ruston@xxxxxxxxxxxxx>>> Sent: Wednesday, November 30, 2005 10:16 AM>>> To:
ActiveDir@xxxxxxxxxxxxxxxxxx>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx>>> [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]>>> Sent: 30 November 2005 15:29>>> To:
ActiveDir@xxxxxxxxxxxxxxxxxx>>> 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.>>>
>>> neil.ruston@xxxxxxxxxxxxx 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of>>>>>>> *David Adner>>>>>>> *Sent:* 29 November 2005 23:26
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On>>>>>> Behalf Of *Rich>>>>>> Milburn
>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx>>>> [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of>>>> *ChuckGaff@xxxxxxx>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx>>>> *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.comList info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspxList archive:http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList 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.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
-- | | | |
| listmail
Posts:824
| | 12/01/2005 10:36 AM |
| PITA Rich... ;o)
I will see if I can dig up the CMD file I used to use.
It is just a couple of commands sent into NTDSUTIL.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rich Milburn
Sent: Thursday, December 01, 2005 9:14 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
>...Why not one click?...
If you script it all up, you can add a "one-click button" to a custom msc.
Use input boxes for server names instead of passing them as parameters or
hard-coding. Or better yet, put it into an hta and launch that from a
button.
I was curious to see, with all these posts, no one ponied up with a real
script to help out all these folks who are 1) not scripters and 2) amazed
that moving the roles could be that easy. (I would post one but I have not
actually scripted this... it's not currently my job :)
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Michael B.
Smith
Sent: Wednesday, November 30, 2005 3:47 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
It can be. It's easily scripted.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Wednesday, November 30, 2005 4:39 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
Bradley, CPA
> aka Ebitz - SBS Rocks [MVP]
> Sent: Wednesday, November 30, 2005 3:09 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] FSMO role transfer
>
>
>
> 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?
>
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta
>>> Nathaniel V Contractor NASIC/SCNA
>>> Sent: Wednesday, November 30, 2005 12:32 PM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
>>> Sent: Wednesday, November 30, 2005 1:24 PM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
>>>> neil.ruston@xxxxxxxxxxxxx
>>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>>> Sent: 30 November 2005 15:29
>>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> 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.
>>>>
>>>> neil.ruston@xxxxxxxxxxxxx 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>>
>>>>>
>>>> *David Adner
>>>>
>>>>
>>>>> *Sent:* 29 November 2005 23:26
>>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On
>>>>>
>>>>>
>>> Behalf Of *Rich
>>>
>>>
>>>>> Milburn
>>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>> *ChuckGaff@xxxxxxx
>>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>> *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/
-------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/
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/ | | | |
| listmail
Posts:824
| | 12/01/2005 11:21 AM |
| Exactly, and Alain is another person used to working with big customers,
both prevously at HP and now with MS.
Consider savings to a company who can hire one person whose automation
capabilities means you can hire 2 less people on a normally 10 person team,
or 7 less people... Or solves issues much quicker because they use scripts
to filter down the problem from large sets of data that you would almost
never find a solution in manually. I have seen folks take hundreds of MBs of
network trace logs and write a script to parse it down to 2k of critical
information that blows the issue wide open and makes it totally obvious that
NEVER would have been found by looking at them in Ethereal or anything else.
We are computer people but we don't always use the computers to our
advantage. Don't let people do work that computers can do all by themselves.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Alain Lissoir
Sent: Thursday, December 01, 2005 10:57 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
Once you are known for your automation capabilities (WSH, MONAD, programming
tools, Perl, whatever), believe me there are companies (usually with large
deployments) that are more than happy to hire you on a project. I cannot say
that it is the case for all companies (it is also a question of awareness),
but as far as I'm concerned, all my professional experience has been made
this way because of scripting/automation (from CMD to any kind of
programming and automation technique). Once they know how much time they can
save, how fast things can be done, they are more than happy to pay to price
to get this type of knowledge on board.
/Alain
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Tom Kern
Sent: Thursday, December 01, 2005 7:25 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] FSMO role transfer
While I agree with the "scripting making you a better admin" part, I've
never worked for an employer who offered me more $$ because of scripting.
Or any interview or employer who cared other than "thats cool" attitude when
i wrote a script to automate something.
maybe i'm working for the wrong people.
I've just been teaching myself VBScript in the past few months and I've
written some scripts for my employer alone and with the help of this
list(alot of help) and lately i've been gainng the confidence no to rely on
this list as much, but my scripting is more for my own personal benfit and
knowldge rather than $$ driven because my employer has never indicated that
the ability to script was something that was a real value in his/her mind.
Scripting, to the employers i've worked for seems more like knowing about
this list- a personal resource that you as an employee chose to use to
perform your job better or gain more info, but not something that in and of
itself is valued, it seems.
Again, i could be working for the wrong people.
Also, ironically, i've yet to work in a Windows shop where i met someone who
knew how to script.
In fact, in Joe's salary chart of $35,000 to $240,000, I fall in the next to
last category. I started at the first/lowest range and in less than 4 years
got to ~ the next to last one without knowing any scripting at all.
i guess thats a sign of the lack of uniformity in the industry.
on the other hand, i think you should know how to script to be a good admin
and i've been busting my butt of late to do just that.
but like i said, its just for my own knowldge that i choose to do so.
i don't expect any $$ for it or advance in my career....
just my random thoughts...
On 12/1/05, joe wrote:
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rocky
Habeeb
Sent: Wednesday, November 30, 2005 5:18 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
Susan,
"THANK YOU
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!"
There are a >LOT
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?
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta
>> Nathaniel V Contractor NASIC/SCNA
>> Sent: Wednesday, November 30, 2005 12:32 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David
Adner
>> Sent: Wednesday, November 30, 2005 1:24 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
>>> neil.ruston@xxxxxxxxxxxxx
>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>> Sent: 30 November 2005 15:29
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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.
>>>
>>> neil.ruston@xxxxxxxxxxxxx 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>
>>> *David Adner
>>>
>>>> *Sent:* 29 November 2005 23:26
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On
>>>>
>> Behalf Of *Rich
>>
>>>> Milburn
>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>> *ChuckGaff@xxxxxxx
>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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/
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/ | | | |
| listmail
Posts:824
| | 12/01/2005 11:22 AM |
| Yep, you picked that out of what I said
"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."
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rich Milburn
Sent: Thursday, December 01, 2005 11:02 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rocky Habeeb
Sent: Thursday, December 01, 2005 9:29 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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.
>BUTLOT
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?
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta
>> Nathaniel V Contractor NASIC/SCNA
>> Sent: Wednesday, November 30, 2005 12:32 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
>> Sent: Wednesday, November 30, 2005 1:24 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
>>> neil.ruston@xxxxxxxxxxxxx
>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>> Sent: 30 November 2005 15:29
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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.
>>>
>>> neil.ruston@xxxxxxxxxxxxx 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>
>>> *David Adner
>>>
>>>> *Sent:* 29 November 2005 23:26
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On
>>>>
>> Behalf Of *Rich
>>
>>>> Milburn
>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>> *ChuckGaff@xxxxxxx
>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> *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/
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/ | | | |
| milburnr
Posts:12
| | 12/02/2005 3:03 AM |
| Pita? Yes please, with some nice lamb and garlic sauce and... oh wait,
now I get it hehe ;-)
Rich
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Thursday, December 01, 2005 4:07 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
PITA Rich... ;o)
I will see if I can dig up the CMD file I used to use.
It is just a couple of commands sent into NTDSUTIL.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Rich Milburn
Sent: Thursday, December 01, 2005 9:14 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
>...Why not one click?...
If you script it all up, you can add a "one-click button" to a custom
msc.
Use input boxes for server names instead of passing them as parameters
or
hard-coding. Or better yet, put it into an hta and launch that from a
button.
I was curious to see, with all these posts, no one ponied up with a real
script to help out all these folks who are 1) not scripters and 2)
amazed
that moving the roles could be that easy. (I would post one but I have
not
actually scripted this... it's not currently my job :)
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Michael B.
Smith
Sent: Wednesday, November 30, 2005 3:47 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] FSMO role transfer
It can be. It's easily scripted.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley,
CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Wednesday, November 30, 2005 4:39 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
Bradley, CPA
> aka Ebitz - SBS Rocks [MVP]
> Sent: Wednesday, November 30, 2005 3:09 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] FSMO role transfer
>
>
>
> 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?
>
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Bahta
>>> Nathaniel V Contractor NASIC/SCNA
>>> Sent: Wednesday, November 30, 2005 12:32 PM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of David Adner
>>> Sent: Wednesday, November 30, 2005 1:24 PM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
>>>> neil.ruston@xxxxxxxxxxxxx
>>>> Sent: Wednesday, November 30, 2005 10:16 AM
>>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>>>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>>>> Sent: 30 November 2005 15:29
>>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>>> 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.
>>>>
>>>> neil.ruston@xxxxxxxxxxxxx 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>>
>>>>>
>>>> *David Adner
>>>>
>>>>
>>>>> *Sent:* 29 November 2005 23:26
>>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On
>>>>>
>>>>>
>>> Behalf Of *Rich
>>>
>>>
>>>>> Milburn
>>>>> *Sent:* Tuesday, November 29, 2005 4:26 PM
>>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>> *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of
>>>>> *ChuckGaff@xxxxxxx
>>>>> *Sent:* Tuesday, November 29, 2005 11:56 AM
>>>>> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
>>>>> *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/
-------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/
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/ | | | |
|
|