BPuhl’s Blog

A little bit of everything without actually being much of anything

More RODC Fun

Posted by BPuhl on February 5, 2009

During our deployment of Windows Server 2008, and then Server 2008 R2, we ran across an interesting case when we deployed in RODC out to one of our regional sites.  The problem was that when we put the RODC into the site in Fargo, ND, users started reporting that one of their serves which is part of a DFSR replica set was throwing errors and not replicating.

In true IT spirit, the first thing we did was deny all accountability and punt it to the DFSR team…after all…we didn’t touch anything :)  (not really, but that’s what usually happens)

Actually, what really happened was that the DFSR team came to us, because they were seeing errors that looked like this on their server:

dfsr_6002

After a little bit of research, the DFSR team came to the only logical conclusion:  AD was broken, and their object was corrupted on FAR-NA-DC-02.

Knowing of course, that AD doesn’t break, and object corruption most certainly couldn’t happen on OUR service, we started looking for alternative explanations.  To understand the environment, remember that we have a multi-domain forest.  In this case, the 2 relevant domains, REDMOND and NORTHAMERICA, are both part of the CORP forest.  The DFSR object is in the REDMOND domain, and Fargo is part of the NORTHAMERICA domain.

When we looked on a REDMOND DC for the object, we found:

Dn: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com
cn: Dynamics_Build202;
description: Contact: <snip>;
distinguishedName: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = (  );
instanceType: 0x4 = ( WRITE );
msDFSR-Options: 1;
msDFSR-ReplicationGroupType: 0;
msDFSR-Schedule: ��������…
msDFSR-TombstoneExpiryInMin: 86400;
msDFSR-Version: 1.0;
name: Dynamics_Build202;
objectCategory: CN=ms-DFSR-ReplicationGroup,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com;
objectClass (2): top; msDFSR-ReplicationGroup;
objectGUID: c527a764-97da-4597-935d-dc96ad1fd889;
showInAdvancedViewOnly: TRUE;
uSNChanged: 452529472;
uSNCreated: 450899211;
whenChanged: 6/24/2008 12:50:51 PM Pacific Daylight Time;
whenCreated: 6/22/2008 11:18:13 PM Pacific Daylight Time;

So the REDMOND DC’s did have the attribute the service was looking for, in this case msDFSR-ReplicationGroupType

When we queried the NORTHAMERICA DC’s would find:

Dn: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com
cn: Dynamics_Build202;
description: Contact: <snip>;
distinguishedName: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = (  );
instanceType: 0x0 = (  );
name: Dynamics_Build202;
objectCategory: CN=ms-DFSR-ReplicationGroup,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com;
objectClass (2): top; msDFSR-ReplicationGroup;
objectGUID: c527a764-97da-4597-935d-dc96ad1fd889;
uSNChanged: 83626939;
uSNCreated: 82256556;
whenChanged: 6/24/2008 12:44:22 PM Pacific Daylight Time;
whenCreated: 6/22/2008 11:18:13 PM Pacific Daylight Time;

Ok, so at this point, we’re not talking rocket surgery or anything.  It was pretty apparent that the attributes that the DFSR service is looking for are not part of the partial attribute set, so they aren’t replicated to the GC. 

At this point, we’re feeling confident that the data for the REDMOND DFSR object wasn’t on the NORTHAMERICA RODC because it wasn’t supposed to be (not part of the PAS), so we started sniffing around to see what the actual problem could be. 

We started asking ourselves a question:  If you query a NORTHAMERICA GC on port 3268 for a REDMOND object, what do you get?  The answer of course is above, you get the object with the PAS.

But what if you query a NORTHAMERICA GC on port 389 for a REDMOND object?  The answer is, that since you’re querying the LDAP port, you should get a referral back to a REDMOND DC, and your client will chase the referral (unless told not to) and end up querying a REDMOND DC for the object.  In which case, they get the object with it’s full set of attributes.

At least that’s the normal, expected behavior.

What we found though was slightly different.  If you query full DC’s/GC’s, then you get the results you expect.  But when we deployed RODC’s, we found that if you queried an ROGC, on port 389, for an object in the REDMOND domain.  Instead of being returned a referral to the REDMOND DC, you were instead returned the object out of the servers GC partition, which only contains the PAS attributes.

Oops.

A quick conversation with the product group came up with a few things:

1.  This isn’t the behavior we want, and it’s fixed in Server 2008 R2 (Win7 Server)
2.  The fix for this, is to add msDFSR-ReplicationGroupType to the PAS (Partial Attribute Set) so it replicas to all GC/ROGC’s.  Click here for how to do that.
3.  It’s generally considered a bad practice to rely on referrals to redirect you to where your data is

So now we’ve got this out of the way, and I think there will be a KB article coming sooner or later on this.  But for now, if you’ve got a multi-domain forest, where a DFSR replica set spans across the domains, and you’re using ROGC’s…well…hopefully you’ll find this post 🙂

~Brian

Advertisements

One Response to “More RODC Fun”

  1. Laura said

    So…in this case, AD actually was broken.

    …naaaaaaaaah, your AD would never break, I refuse to believe it. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: