| Author | Messages | |
sbradcpa
Posts:354
 | | 12/01/2005 3:33 AM |
| But why reinvent the wheel individually when we should be asking
Microsoft to either fix the wheel or build us a wheel in the first
place? If it's a task that is repetitively done, has value, is used
over and over again, I'd rather trust a gui wizard/console/button that's
gone through beta testing by various testers that lays down an audit log
file than a home grown script [no offense guys] that I'd have to go get
interpreted.
Take the Security configuration wizard for example.. versus your own
home grown version of the same. I'll take the SCW because I can see and
confirm the resulting XML file, the program has been through beta
testing process so in my brain I assign it a bit of lesser testing
resources.
For my space, I trust the gui way more than I do a script from a web
site that possibly wasn't built with SBS in mind.
But the gang that does Scripting drools over Monad. So get ready for
Scripting on steriods.
http://www.microsoft.com/downloads/details.aspx?FamilyID=2ac59b30-5a44-4782-b0b7-79fe2efd1280&displaylang=en
http://www.microsoft.com/downloads/details.aspx?FamilyID=8a3c71d1-18e5-49d7-952a-c55d694ecee3&displaylang=en
David Cliffe wrote:
Well, I just think that most of the people in the command line and/or
scripting "camp" like to encourage others to learn to use them simply
because they feel it's to your benefit. I don't think they really like
to promote the "you're not a real admin..." sentiment. Or at least I
hope not :-) Right now in my org, I'm in the minority using the CLI. I
just prefer working that way and don't knock my colleagues for their
methods, but rather show them other ways to get at the info they need.
CLI and scripting fosters your knowledge of what's happening in the
background, helps you learn the product and truly is a great way to
automate tasks! (if not THE way)
For the longest time I've been meaning to learn VBscript, but haven't
devoted enough time to go for it yet. From what I've seen so far, it
scares me :-P but I still intend to give it a shot. I've been getting
by with Perl and CMD shell for now (I came from a KSH/*nix background).
Have you seen some of the sample command shell scripts Dean has put
together? Or the stuff that Alain Lissoir can do with WMI? Wow!
Anyway, this topic has drifted further now, but I'm going to resist the
urge to change the subject line. The last time I did that, we had a
little side bit just on the fact that the subject line changed! :-D
-DaveC
-----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/
To find out more about Reuters visit www.about.reuters.com
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
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/ | | | |
|
|