|
The AD schema analyzer is quite useful for comparing schemas to
find missing attributes and classes (and to export them to LDIF so as to allow
an import to the target schema). Note however, that it doesn’t find
differences at the level of properties you have set for your schema objects,
for example it doesn’t find the difference in the searchFlags for an attribute that
exists in both schemas. As such you need to know how close you want your schema to match
and likely need to an exact compare either using custom scripts or LDIF dumps
of the complete schema coupled with text-compare tools. In general I would want to question what your goal is – like Al
I am assuming you want to make the schema more manageable. Basically a
convenience so you don’t have to worry about managing and documenting the differences.
That’s quite different from a technical necessity, where you may need to fully
replicate all objects in your AD along with all attributes (except the ones
managed by the system) – in this case, you may need to keep your schemas fully in
sync. I would not much discuss the security with respect to the Schema
classes and attributes stored in the different Forest schemas – I would not say
that there is much of a risk in knowing you have XYZ attributes defined in
either schema. The discussion is much more relevant as to which data do you
plan to replicate between the two? Let’s assume you are storing sensitive data
in one of your forests, for example, you may store the social security number
of your employees in a company specific attribute called “MyCompany-Employee-SSN”,
and you have even done everything to hide this data from normal read access (i.e.
you’ve configured it as a confidential attribute). Do you want this data to be
replicated to the other forests? If not, then I would also not suggest to add
the special schema attribute to your other forests schema, since this way you
hinder it from being synced by accident (not saying you couldn’t sync it
elsewhere). If later there is a necessity to replicate the data across to
the other forest(s) you could add a simple procedure in your ITIL processes
that would ensure that the target schemas need to be updated appropriately
prior to replicating the data. /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Al Mulnick Yep, the schema analyzer would
be a good tool to have hold of. On 9/13/06, Joe Kaplan <[EMAIL PROTECTED]> wrote: I like this advice as well. In terms of some of
the nuts and bolts of how |
- RE: [ActiveDir] Handling different schemas - managing ... Grillenmeier, Guido
