This isn't a difference in how ldifde works, but in how ADAM and AD works
for schema updates. That output format is a standard way to publish a
directories schema. You can query the schema from AD in that format (get
the DN from the subschemaSubentry attribute from the rootDSE, authenticate,
and query that DN specifying objectclasses and attributeTypes) but it
doesn't accept updates in that format.
Just so you know, I personally don't have much hands-on experience with
AD/AM - just AD. Here's the documentation I found from MSDN on updating
AD/AM's schema:
http://msdn.microsoft.com/library/en-us/netdir/adam/extending_the_adam_schema.asp?frame=true
So what you have is an output format for the schema, likely per RFC 2252 (
http://www.ietf.org/rfc/rfc2252.txt ). You're most likely interested in
sections 4.2 and 4.4 describing the strings for objectclasses and attribute
types. AD's schema is stored as a collection of objects in the Schema
naming contexts. So instead of adding lines to the attributeTypes or
objectClasses attribute of a subschema object you'll add an object for each
attribute and objectclass you're creating. If making a LDIF file for this
is too much work I'm told AD/AM has a GUI schema manager similar to AD's
schema manager but I don't have an AD/AM instance installed to verify this
with.
Sorry, I don't have a script that will parse the subschemasubentry output.
Jason