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"

msgbox "done!"


After 15 min or so - your user "dyno" will cease to exist. ( if all goes well... )




keyword: dynamicObject entryTTL


Comments (11)
  1. mikeshep says:

    Seems like just the thing an unscrupulous IT Consultant needs when business is slow.  Create your customer’s user accounts as dynamic objects with a TTL, then when they disappear, work very hard through the night to recreate the missing accounts.  Maybe even use a VAP Business Down case to get the "experts" at Microsoft involved in troubleshooting…

    🙂 Sounds like you’re having fun at least, even if you do get shot at occasionally.

  2. Spat-MSFT says:

    Key Word "unscrupulous"

  3. joe says:

    Interesting. I was shown this by another MVP (Dean)in 2003 when we were going to the MVP Summit in Redmond. He had worked out ways to use it for evil. When we sat with the DS Dev team they seemed aware of the possibility but seemingly hadn’t worked out the implications because they sat rapt with attention as the implications were layed out. At first arguing some of the points but then accepting them and I recall Will L shaking his head saying, yeah, this has to be corrected.

    I later worked out some more uses for it using the same basic ideas in various ways. We heard it was going to be plugged for SP1. After applying SP1 I took a quick look at it and it appears the protections are on the schema mods so schemas that have already been configured in specific ways prior to SP1 (sort of like the confidential bit workarounds) should still be able to leverage this capability even after all DCs have been upgraded to SP1.

    I definitely understand why this had to be changed, it was a good call. It was an extremely dangerous thing to leave in the hands of admins of AD who might be less than secure in their position. Done properly, you could plant a serious bomb that is very difficult for someone to disarm.

    So anyone reading this who hasn’t upgraded to K3 SP1 AD you now know one reason why you really really really should.


  4. Today I finally arrived into office after long time being on-site at customer’s office and I had some…

  5. Today I finally arrived into office after long time being on-site at customer’s office and I had

  6. Rudolph says:

    Is there any way report the TTL of a dynamic object? Is seems that the entryTTL "attribute" can be set via vbscript etc but can not be read. Is this by design or am I missing something?

  7. I was recently engaged by a SQL dev in order to help out on a tough nut they were working on. A customer

  8. ... says:

    Ich erklare meinen Freunden uber diese Seite. Interessieren!

  9. Rob Ingenthron says:

    I love finding info like this, but one thing I have seen clearly defined is the minimum requirements for these objects to become available. Obviously, you need at least one Windows 2003 DC, but does the forst need to be at "Windows 2003" to create this class of objects? Is there a config setting in AD that needs to be set to enable access to these objects?

    I’ve tried various vbscripts to create a dynamic object, but I get "The server is unwilling to process the request", which seems indicative of a non-existent class.

    Any additional info would be appreciated.


    — Rob —

  10. WintelRob says:

    Shoot.. Sorry… I mean’t "haven’t seen clearly defined".

Comments are closed.

Skip to main content