I'm not the original author of these and I don't know who is, but I've had this list on paper for a long time and it's time to put it online so I can pitch the paper copy.

ADSI Design Rules

1. Never Hard Code the Server Name.  Use "Serverless Binding" when connected to or attempting to find the best directory server.  Serverless binding extends scalability by allowing for access to the directory service without regard to where the directory store exists (which server or servers) or if it exists across multiple directory servers.  ADSI will actually locate the "best-connected" directory server in the namespace subnet automatically.  ADSI will bind to the default domain without specifying the primary domain controller.  This is the domain associated with the current security context of the thread that's doing the binding.
   
   For ordinary applications, this is typically the domain of the logged-on user.  For service applications, this is either the domain of the servivce's logon account or that of the client that the service is impersonating.
   
   Use rootDSE to retrieve information about the directory server, such as its name (ServerName).
   
   The ADsPath string for rootDSE LDAP reference is:
   LDAP://rootDSE
   
   The rootDSE can be referenced because it does not exist in any namespace, and therefore is global in scope.  The rootDSE has many other useful properties that should be exploited, such as currentTime and namingContexts among many others.
   
2. Use rootDSE to Get the Distinguished Name for a Namespace.  Dynamically read the namingContexts property of rootDSE to access the distinguished name of the namespace and distinguished names of all of the objects in the namespace.
   
3. Use OIDGEN to Generate Unique Identifiers for New Attributes (or Other Objects).  Microsoft delivers the oidgen command line tool to list available unique object identifiers for use within the PlanSoft applications and services.  Always use identifiers in the listed range for new classes or attributes.
   
4. Use the Following Class and Attribute Naming Rules. You must explicitly specify the IDAPDisplayName for all of your attributes and classes.  Do not let ADSI auto-generate this name from the Common-Name.
   
   Use the same name for both the Common-Name (cn) and the LDAP-display-name (IDAPDisplayName) of a new attributeSchema or classSchema object.
   
   Identify your company with a lower-case prefix in the first section of the name.  This prefix can be a DNS name, acronym, or other string that uniquely identifies your company.  The prefix ensures that all attributes and classes for a specific company are displayed consecutively when browsing the schema.
   
   Use a hyphen as the next character (after the prefix).
   
   Specify an attribute or class name that is unique within your company after the hyphen.  This part of the common-name should be descriptive.  Don't use cryptic names that are meaningless to developers and viewers of the schema.
   
5. Minimize the Use of Objects (Classes and Attributes) in the Global Catalog.  If you can find an existing use of one of the existing classes or attributes, then use it and don't create a custom attribute or class to accomodate the new property.  Other factors:
   
   The attribute is "globally interesting."  Either the attribute is needed for locating objects that may occur anywhere in the forest, or read access to the attribute is valuable even when the full object is not accessible.  An example of the first type is the location attribute, which can be used to find a printQueue object no matter where that object is located.  An example of the second type is telephoneNumber, because you can phone someone even if you can't access a full replica of his user object.
   
   The volatility of the attribute is very low.  This is important, because if an attribute class is included in the global catalog, changes to every value of that attribute class throughout the enterprise forest are replicated to all global catalog servers in the enterprise.
   
   The size of the attribute is small.  "Small" is highly subjective:  when placing an attribute in the GC you must consider the impact of replicating the attribute to all GC servers in the enterprise.  The smaller the attribute, the lower the impact.  Because replication occurs only when the attribute changes, the impact of replication is also smaller as volatility decreases, so a large attribute with very low volatility may have a smaller overall impact than a small attribute with high volatility.
   
6. Group all ACLs to be Used for BizTalk Server Into a Single Group.  This will enable you to use a unique identity for each server application and treat them the same with respect to ACLs on other system resources.