LDAP modify operations
A fellow admin came over the other day asking me a couple of tough questions about Active Directory and Group Policy. One of them is the topic for today’s blog posting:
You probably have heard about how the Schema gets updated and that there’s a small delay before the changes get become effective on a DC. Typically that’s five minutes. It’s just a wait time to make sure the changes made to the Schema are complete as a whole. For the time between the Schema change and the time the changes become effective, DCs keep their current Schema definition in the Schema Cache and wait for the delay time to pass.
In order to force a DC to load the Schema immediately, there’s a trick you can use: you open LDP and focus on the rootDSE (use a NULL DN) object. You select “Modify” from the “Browse” menu and add the ‘schemaUpdateNow’ attribute to change its value to ‘1’. ‘SchemaUpdateNow’ is a special attribute of the rootDSE that you can’t see from the attribute list in LDP:
That’s because schemaUpdateNow is one of Active Directory’s ‘LDAP modify attributes’. Those attributes aren’t readable but can be written to kick off a special function on a DC. In our case, that’s a forced update of the in-cache Schema on a DC.
There are a couple of other LDAP modify attributes around, according to http://msdn.microsoft.com/en-us/library/cc223297(PROT.13).aspx, those are:
becomeDomainMaster
becomeInfrastructureMaster
becomePdc
becomePdcWithCheckPoint
becomeRidMaster
becomeSchemaMaster
checkPhantoms
doGarbageCollection
dumpDatabase
fixupInheritance
invalidateRidPool
recalcHierarchy
schemaUpdateNow
removeLingeringObject
doLinkCleanup
doOnlineDefrag
replicateSingleObject
updateCachedMemberships
doGarbageCollection
PhantomsNow
invalidateGCConnection
renewServerCertificate
rODCPurgeAccount
runSamUpgradeTasks
sqmRunOnce
runProtectAdminGroupsTask
disableOptionalFeature
enableOptionalFeature
Looking through the list, there are a couple of interesting attributes. Kicking off ‘doGarbageCollection’ with a ‘1’-value in LDP starts the garbage collection process on a DC that removes objects that are “ready” to be deleted:
Digging further through the list, you get to see three very interesting attributes:
becomePDC
becomeSchemaMaster
becomeDomainMaster
becomeInfrastructureMaster
becomeRIDMaster
Aren’t those these operations you are supposed to execute from NTDSUtil from the command line? Transferring and Seizing FSMO roles are no NTDSUtil-only job. http://support.microsoft.com/kb/321469 - you can script the role transfer pretty easily by targeting the rootDSE of the DC that you want to transfer roles to and kick off the corresponding modify operation. Be sure to connect to the correct DC when using these attributes. Kicking off the functions will only work on the target DC - there is no remote stuff working behind that would trigger the function on all DCs at the same time.
