When is it "by design" -- a tale of a dynamicObject ( yet another post SP1 change )
How do we convince you something is by design?
This is very hard for me. I can definitely empathize with those who run into “issues” ( I kinda hate using that word, almost as bad as “super excited” or “leverage” ) due to product behavior, however at some point we do have features which are by design and will not be changed.
When we run into these, we kindly reply with a “rejection letter” in which we explain the why’s and how’s of why your beloved design change was rejected by The Empire.
I don’t make these decisions. Folks with big brains make them. Much, much bigger than mine. In fact, they need to wear a neck brace just to support their enormous noggins. No, instead I just deliver the message, and many times am shot in the process. Don’t shoot the messenger. Please.
Here is a great example…
Back in Feb of 2003, before Windows Server 2003 launched, I was casually looking into this new feature called “Dynamic objects”.
Perhaps you haven’t heard of these up to now, so ill give a brief overview.
These are basically objects in your AD which have a time to live ( TTL ) and up and vanish when the TTL expires.
Lord! It's a miracle! Man up and vanished like a fart in the wind! ( sorry I had to say it - jake or wolfy will get it )
In addition all dynamic objects have the following limitations ( directly pasted from the link above )
· A deleted dynamic object due to its TTL expiring does not leave a tombstone behind. ( mui importante )
· All DCs holding replicas of dynamic objects must run on Windows Server 2003. ( mui importante )
· Dynamic entries with TTL values are supported in all partitions except the Configuration partition ( RTM this was not true ) and Schema partition. ( can you imagine a dynamic schema?? )
· The Active Director service does not publish the optional dynamicSubtrees attribute, as described in the RFC 2589, in the root DSE object.
· Dynamic entries are handled similar to non-dynamic entries when processing search, compare, add, delete, modify, and modifyDN operations.
· There is no way to change a static entry into a dynamic entry and vice-versa.
· A non-dynamic entry cannot be added subordinate to a dynamic entry.
Looks good. So let’s look at detailed behavior…
In RTM, you were allowed to ( regardless of domain of forest functional level ) :
-
Set entryTTL as an optional attribute for any class
-
Set dynamicObject to be a static auxiliary class for any class
-
Create dynamic objects in the configNC ( havent tested post SP1 )
I’ll let your imagination run wild for a bit to see why this may not be good. Anyway – back in 2003 when I was looking into this, I filed a bug on the behavior for dynamic objects. At the time, it was decided not to be a showstopper ( it was late in the game ) and postponed until sp1.
A little insight to this - we generally do not change code post RTM, unless there is a security hole or a customer is pushing for a hotfix. If the bug meets neither bar, it may be postponed to a service pack, or not fixed at all.
So you see, there was a bug filed, but with no customer to push it , and no time before RTM ( not high enough priority to change it so late in the cycle ) 2k3 went out the door with this bug in the code. It would not be fixed until Sp1.
And here we are - post SP1. What’s the new behavior?
You can *not* :
-
Set entryTTL as an optional attribute for any class ( restricted to dynamicObject class alone)
-
Set dynamicObject to be a static auxiliary class for any class ( it will function only as a dynamic auxiliary class )
And who gets emailed one day about some ISV who’s application’s setup is breaking? You guessed it… Apparently folks were using this “feature” and extending the schema in the exact manner which we had decided was NOT proper design and was indeed a bug. But, up until Sp1, everything worked like a champ.
I’m sorry, this is now by design. I know it may be hard to understand – especially if your product no longer installs , but really – it was a bug.
I guess there will always be two sides to a story, I just ask that you try to understand ours ( and don't shoot the messenger.)
PS: here is a little sample to demonstrate dynamic objects... pretty basic. Post Sp1 :)
set objOU = Getobject("LDAP://OU=CPR,DC=crisco,dc=com")
set objUser = objOU.Create("user", "cn=dyno")
objUser.PutEx 2, "ObjectClass", Array("dynamicObject","user")
objUser.Put "entryTTL", 902
objUser.Put "samAccountName", "dyno"
objUser.Setinfo
msgbox "done!"
After 15 min or so - your user "dyno" will cease to exist. ( if all goes well... )
spat
keyword: dynamicObject entryTTL
