joeware - never stop exploring... :)

http://computerworld.co.nz/news.nsf/tech/99A7774F067EA284CC257474007C0076

Hewlett-Packard is working with Fusion-io to adapt the start-up’s high-performance, solid-state input/output storage technology to HP’s enterprise servers to improve their data access performance and energy efficiency.

…

“With our ioMemory architecture, we’re getting more than 200,000 IOPS within HP BladeSystem c-Class server blades today,” says Don Basile, Fusion-io’s chief executive officer. “So, working together with HP was the natural place to begin building upon our next generationtechnology.”

Wow. That’s a couple orders of magnitude over anything else internal I believe. And being solid state, that would be way cooler and way less energy requirements… I want a PC and a laptop that runs at that IOPS level.

A friend of mine pinged me recently and asked

… can you think of way of determining with certainty that a DC was IFM promoted or not based on its DIT (logs are say long since retired)

I thought about this a moment,  furrowed my brow for another moment and then started down the path involving a special little implementation quirk I ran into long ago. I actually like implementation quirks, they can help you work out various things going on and in this case, possibly help you determine something that no one at MSFT may have thought you might want to know or be able to do someday or maybe just plain decided you didn’t need so never exposed the capability[1]… That so rarely happens[2].

The quirk is that when a new object replicates to a DC, all of the attributes replicated in update the metadata on the target DC in a specific fashion. That specific fashion is that the originating DSA (or DC in this example), originating USN, and originating time/date metadata are from the actual originating DSA… The DSA where the changes were initially made. With one exception… the RDN attribute… That ends up getting originating DSA info from the machine receiving the replicated object.

So for example if you look at my administrator userid metadata you will see

G:\Temp>repadmin /showmeta CN=administrator,cn=users,DC=test,DC=loc test-dc1

38 entries.
Loc.USN                          Originating DC   Org.USN  Org.Time/Date        Ver Attribute
=======                          =============== ========= =============        === =========
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 objectClass
   7366                      secondsite\TEST-DC1      7366 2008-04-12 23:50:33    1 cn
103078            Default-First-Site-Name\R2DC1   1186430 2008-05-28 20:39:12    1 title
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 description
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 instanceType
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 whenCreated
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 displayName
   7366            Default-First-Site-Name\R2DC1     12489 2006-05-11 23:39:56    2 nTSecurityDescriptor
103078            Default-First-Site-Name\R2DC1   1186430 2008-05-28 20:39:12    1 wWWHomePage
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 name
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 userAccountControl
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 codePage
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 countryCode
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 homeDirectory
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 homeDrive
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 dBCSPwd
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 scriptPath
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 logonHours
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 userWorkstations
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 unicodePwd
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 ntPwdHistory
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 pwdLastSet
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 primaryGroupID
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 userParameters
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 profilePath
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 objectSid
   7366            Default-First-Site-Name\R2DC1     12489 2006-05-11 23:39:56    1 adminCount
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 comment
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 accountExpires
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 lmPwdHistory
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 sAMAccountName
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 sAMAccountType
  70758                      secondsite\TEST-DC1     70758 2008-05-04 08:50:25  249 lockoutTime
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 objectCategory
   7366            Default-First-Site-Name\R2DC1      8194 2006-05-11 23:19:59    1 isCriticalSystemObject
3063976                      secondsite\TEST-DC1   3063976 2008-06-17 16:57:37   32 lastLogonTimestamp
170720                      secondsite\TEST-DC1    170720 2008-05-28 22:18:34    8 joewareExtended11
199736                      secondsite\TEST-DC1    199736 2008-05-28 23:05:49    2 joewareExtended10
1 entries.
Type    Attribute     Last Mod Time                             Originating DC  Loc.USN Org.USN Ver
======= ============  =============                           ================= ======= ======= ===
        Distinguished Name
        =============================
PRESENT      manager 2007-02-27 17:19:31   47e66f05-61fa-4bff-88e1-2a62b5ef8289    7403  555581   1
        CN=joe,OU=Users,OU=My,DC=test,DC=loc

As you can see, most of the attributes are showing that they were originated in May 2006 on R2DC1 but the cn is showing origination on April 12, 2008 on TEST-DC1. Clearly the date is off from the true instantiation of the account in the domain, but that is when it came into existence in the DIT this DC has. As a quick no brainer sidebar…. What day was TEST-DC1 dcpromo’ed?

So how, pray tell, you ask, does that help you with determining if a DC has been promoted from IFM or not? Well…. if you IFM a DC the DIT is the DIT from the DC you took the media from; the DIT is copied into place, it isn’t built locally in the normal way through replication. This is why it is faster. The same level of processing and validation isn’t done, the file just is there…  This means that the stamping on the RDN attribute will be from the DC that originally built the DIT, not the current machine. So if you, say, look at the replication metadata for the administrators account and specifically you look at the RDN attribute metadata (which is CN for users), it will list the old DSA, not the current DC like you would see on a DC that went through the normal DCPROMO process.

So a specific example…. Say I have DC1 which is the first DC in the domain and I look at the administrator’s account metadata for the ‘cn’ attribute. I will see DC1 listed as the originating DSA.. Now say I promote DC2 from DC1 in the normal way and look at the administrator’s account metadata for the ‘cn’ attribute, I will see DC2 listed as the originating DSA. Then let’s say I build IFM media from DC2 and promote DC3 with that IFM media. Looking at the administrator’s account metadata for the ‘cn’ attribute will show what… DC2… not DC3 for the originating DSA. Now later we make some IFM media from DC3 and we build DC4, what will the metadata show for the originating DSA for ‘cn’? Why DC2 again of course. Now what happens if DC2 gets demoted in the meanwhile, what will the metadata show then? The answer… “Deleted DSA”.

In the generic case, while I haven’t tested this in all scenarios, I expect just checking the metadata for any of the main three partition heads on the DC should be more than sufficient. Alternately you can check some other object that you know existed pre-IFM say like the administrator’s ID though you would need to be careful with how you do that in a generic way[3]. Using the configuration or schema partitions should be pretty stable since you don’t often see those renamed. 🙂

Here is a quick little perl script (or one liner if you prefer) to check the DCPROMO status (IFM or normal) of a specific DC

if ((`adfind -h @ARGV[0] -config-s base msDS-ReplAttributeMetaData;binary -mvfilterdelim # -mvfilter \”msDS-ReplAttributeMetaData;binary= dc\” -list`)[1]=~/\\$ARGV[0]/i) {print “Normal Promotion”} else {print “IFM Promotion”};

Just save that to a perl script file and then execute the script with the short name of the DC as the parameter. This isn’t intended to be all inclusive, just something simple to show the basic idea of how it can be done. If you want to put that into a function in a larger perl script just change @ARGV[0] to $_[0].

Stay tuned for a matching post from Brandon over on his blog as he also got wrapped up in this exercise. Maybe he will explain some context of what this was about and why anyone would care if a DC was promoted from IFM or not from his viewpoint….

   joe

[1] Inside joke for those who are paying attention to other threads I have been involved in recently.

[2] NOT! Happens all the time, if MSFT knew what I wanted and what I was doing, joeware never would have come into existence.

[3] Think renames or object moves…