|
A lot of the complexity comes from having
multiple domains. If you have a simple forest with a single domain, then it’s
doable but ugly. As you scale up the complexity of your forest, if you insist
on having users from each domain, then you have to deal with an N-squared
expansion in the number of permissioning steps in order to get everything
talking to everything else. That’s why there are alternative deployment
strategies that reduce that complexity. I advocate the resource domain
architecture because you can throw it away at the end of the day if you want,
or had it over to an outsourcer. So the schema change itself will not be so
bad especially if you get all the DCs upgraded to Windows 2003 SP1. You will
avoid all of the headaches associated with full GC re-sync, though to be honest
it’s not a big deal if you only have one domain. The main issues for me are the placement
of the system objects (though I’ve heard that they might fix that in a
future version) and the overall permissions model which involves domain global
groups, new property sets and domain-wide ACLs with ACEs referring to those
domain groups for every domain with servers in it. Don’t get me wrong. I like the LCS
functionality. I like the service and what it does for me. I just don’t
like the implementation. Wook From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED] ...what joe said, but also test the app
thoroughly and document its issues so that you can then perform a CYA job back
to those asking for the product and to your own boss :) This is par for the course in the world of
IT - we are often forced to deploy cr** and all we can do to mitigate the
situation is to document our misgivings. At least if the whole thing blows up
in your face, you can point to a doc or email and state 'told you so' :) neil From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe I do not have first hand experience with
it but have been speaking to some very trusted friends who have been trying to
implement it and pretty much anything they say I would take as if I saw it
myself. From what I hear there are some "odd" ACEs added to the ACLs
(I believe at the NC Head level) that make no sense but are required or you can't
install LCS Servers. I believe specifically there is something with a property
set that is absolutely worthless (I don't recall the details now). Also you
can't substitute the ACEs, you must have the exact ACEs in place that the LCS
prep puts into place. That means they aren't checking access rights, they are
scanning the To add even more pain, the Basically, if you are being forced to use
it, you don't have much choice, lube up and go for it. If you do have a choice,
go through the product with a fine tooth comb in the lab and document all of
the crap and then complain to MS. Possibly if enough people tell them that the
functionality isn't good enough to deal with a shitty implementation they might
get a clue. Most likely it has gone as far as it has is because most people
don't have a clue what they are doing when they are installing things and
assume anything out of MS will be done correctly and never verify the changes
made in the directory and how much sense they may or may not make. Oh another thing, there is some global
group requirement built into LCS for admining the product, from what I heard
you have NO CHOICE but to use global groups. This is yet another product that
demonstrates that just because it came out of MS doesn't mean it is good or
should just be implemented. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From:
Rimmerman, Russ [mailto:[EMAIL PROTECTED] Do you have any specific examples of the
domain-wide ACLs I can keep an eye out for? Unfortunately we don't have
much say in this, the 'powers that be' want it implemented, and quickly. From:
[EMAIL PROTECTED] on behalf of Lee, Wook IMHO, LCS
puts its configuration system objects in the wrong place, i.e. 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
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 |
Title: RE: [ActiveDir] Extending the schema
- RE: [ActiveDir] Extending the schema Lee, Wook
