|
>I personally think
investing time and money into the native tools for data administers is like
giving children razor blades.
On this point, I have to
disagree. In a number of organisations I've done work where custom or
3rd party tools have been used they have been fine.......UNTIL something goes
wrong and they stop working.
If your support staff only know how
to do their job via a 'sandboxed' application, they are essentially useless if
that tool is down.
In my current environment, we made a
concious decision to show the 1st and 2nd level support staff how to use the
native tools, and have not had any problem so far *touch wood* outside of the
normal finger fumbles. If your AD security is implemented correctly (thats the
trick), they shouldnt be able to get themselves into too much trouble
anyway.
Its also good for them as they learn
how AD works, and actually UNDERSTAND what effects things can have, and why a
certain field should be a specific value. Its also good or your 3rd level guys
(like me) who dont have 1st and 2nd level banging on the door to do tasks for
them if the custom tool is down.
My $0.02
Glenn
----- Original Message -----
Sent: Friday, August 08, 2003 6:57
AM
Subject: RE: [ActiveDir] Seeking some
feedback ... use of 2003 Admin. tool s against a non-forest prep'd 2000 only
directory ...
Schema Extensions aren't bad, if they are documented correctly and
properly replicated throughout the forest. Rob, didn't you say that you
found a way to clean up old schema extensions that Microsoft "fixed" in
SP3.
Dean,
Why is it necessary for you to extend the native tool
function? If it is to have better Data Administration functions, I
would recommend using a third-party products. I personally think
investing time and money into the native tools for data administers is like
giving children razor blades. Directory Administrators on the other
hand can use tools like Hyena, or one of the many tools out there, but you are
right, to get extended functions, the only way is to either forest prep
using Microsoft regression tested methods, or roll you
own.
So the question is, are you that good!
This isn't to say can you write a
script to do it, more so, can you predict how long their directory will be
used, and if your extensions will one day cause more problems than its worth
to the next guy who supports
them. I have to say you do have a very
impressive Microsoft knowledge base in your brain, and intellectual
grasps of the cause and effect of changes in Microsoft Technology, so I
am not really worried. Just trying the scare off the faint of
heart.
From what you describe though, it doesn't sound to
difficult and I have modified display specifies many of times. (Who in
the heck searches an address book by first name? The guy who wrote AD
U&C must have had some good drugs that
day.)
Based on some things I've done in the past that are similar in nature
to this, I would be extremely surprised if MS supports it. That
said, it didn't prevent me from doing it anyway ;-)
I'd like to see the script when you are done to look at what is
involved. You'll definitely want to put add an "undo" option as part
of it. As you mentioned, the schema version would be the major
concern. Who knows how Microsoft uses it within
applications. I suppose other non-MS apps could also use it to
determine what to expect in the schema.
As
far as extending the schema goes, you will inevitably run into the
people that don't want to do it because it is "bad", and probably even more
so if it isn't supported by MS. I'm a big proponent of extending
the schema when it makes sense. Especially in this case, you aren't
adding to the GC (which of course isn't an issue in W2K3). It all
comes down to how much the customer needs the new tools and is not wanting
to upgrade.
Robbie Allen
In order for the multi-select property sheets to
become available within the admin. tools, a display specifier modification
is necessary. The modification entails the usage of an attribute NOT
provided by the base Windows 2000 AD schema, subsequently, some minor
directory updates are necessary if batch modification is desirable within
the GUI (in my experience, it's listed as the one of the major complaints
especially from those that upgraded from NT4).
The mods. necessary are quite extensive and
involve incrementing the schema revision (objectVersion attribute of the
schema NC head) to a value of 15 (this step is mandatory as the tools
appear to be hard coded to look for this value
before presenting the properties context menu option during a multi-select
operation).
With the exception of the schema revision and a
modification to two of the pre-existing display specifiers, no further
potentially destructive changes are necessary (the schema revision is the
major concern).
As for supportability from MS themselves, I agree
this is important to many but since we're introducing changes defined
by Microsoft themselves (admittedly incomplete) I see no reason for major
technical concern. I'm uncertain as to PSS's point of view at this stage
(without wishing to raise the "ooh, look at me flag", I'm fortunate enough
to have the luxury of teaching the majority of Microsoft's worldwide AD
PSS tech. leads & support staff and will ask for their opinion next
week). I guess I look it these modifications as similar to those you
referenced in your reply, they are little more than "run of the mill"
schema extensions that happen to be defined and used by MS themselves ...
one would hope this is a positive thing :) .
Thanks for your input Glenn ... much
appreciated.
Dean
--
Dean Wells
MSEtechnology
( Tel: +1 (954)
501-4307
* Email:
dwells@msetechnology.com
http://msetechnology.com
Dean,
I'm not quite sure I understand the
question (it may have something to do with it being 1am
here)
Running the 2k3 Admin tools on 2000 / XP
machines wont require any mods to the forest schema (and in
fact is the only way you can perform some administrative tasks from XP
machines (like e2k) - grrrrr Microsoft).
That being said, it sounds like you are
performing a selective update of the schema with those properties /
objects to give some additional 2003 'ish features without going all
they way and really 2k3'ing the environment ? Are they simply additional
properties to existing objects (like users, groups, computers), or it it
something more fundamental ?
Sounds like a feasible alternative,
provided that you arent changing underlying properties within objects
that may affect downlevel 2000 clients or DC's (which it sounds like you
arent). Personally, I dont think MS would support you in the
slightest if you did have issues in the 2k environment, and would be
tricky to undo as you cant reverse schema mods in 2k. The only option
would be a 'forced' rollup to 2k3 before the client environment is ready
for it.
What sort of additional functionality are
you gaining, and is this enough to potentially have an "unsupported" AD
in the eyes of MS ? (I'm not saying for certain they wouldnt support
you, but from personal experience its probable).
My suggestion would be to get a definate
yes or no from MS on the supportability of this change, and if they are
happy make your decision then. The schema isnt written in stone
obviously, so is meant to be changed (within reason), your just modding
it in a slightly *strange* way.
I would certainly be interested in the
details of what changes you are making, and what additional
functionality you are getting. My understanding with things
like Multiple Object Edit is that it is simply additional functionality
within the 2k3 Admin tools, and had nothing really to do with
AD.
As to schema mods, I've certainly made
several changes to each schema for directories I've designed to
incorporate additional properties for objects, but havent tried anything
like your doing.
Glenn
----- Original Message -----
Sent: Thursday, August 07, 2003
10:19 PM
Subject: [ActiveDir] Seeking some
feedback ... use of 2003 Admin. tools against a non-forest prep'd 2000
only directory ...
I'm
seeking some feedback regarding the use of the new 2003 admin. tools
against a Windows 2000 only directory. I implemented these tools many
moons ago on an internal, production 2000 forest on both XP and Server
2003 clients and have experienced no significant (insurmountable)
issues. Coincidentally enough, I recently offered this as an
alternative *potential* solution in the public
newsgroups for those administering 2000 directories who wish to
take advantage of the newer features such as "Saved queries" and
"Multiple object edit" (to name but a few) ... quite honestly, that's
the main reason for soliciting your feedback.
I'm
considering automating the necessary directory modifications such that
those customers (specifically, one of mine) wishing to use the new
features provided by the uplevel ADMINPAK are able to do so without
going through the convoluted steps necessary to enable certain
components and gaining these features without fully forest prepping
their existing directory (NOTE - doing so is, IMHO, a satisfactory
approach but I'm certain that the myth of "Extending a Windows 2000
schema is a bad, bad thing" is likely to raise its head ... thus the
reasoning behind making ONLY the necessary directory
modifications).
What I'm
looking for are opinions/technical commentary or actual
experience of doing so in production or test environments other than
my own.
I've
exhaustively tested this including proceeding with a full Windows 2003
forest prep in order to ensure that the modifications made to the base
2000 schema were NOT prohibitive to a future 2003 upgrade ... they
weren't (this did require some minor modifications prior to executing
the forest prep though).
Thanks in
advance for your thoughts and/or experiences.
Dean
|
