What are the Schema Extension Requirements for running Windows Server 2008 DFSR?

What are the Schema Extension Requirements for running Windows Server 2008 DFSR?

  • Comments 14
  • Likes

Ned here again. With the release of Windows Server 2008, a number of customers have asked us whether or not they need to extend the Active Directory schema in order to use the new version of Distributed File System Replication (DFSR).

The answer is, of course: it depends. :)

There are a few DFSR scenarios available in Windows Server 2008, so let’s start by talking about them. Then we’ll see what you as an administrator can decide to do in your environment.

DFSR with SYSVOL

If you want to stop using the legacy File Replication Service (FRS) to keep your SYSVOL shares in sync, you definitely need to extend the schema. This is because only Win2008 DC’s can participate in SYSVOL replication using DFSR, and in order to add Win2008 DC’s, the schema must be at 2008 level (i.e. version 44). Additionally in that scenario, you must be at a Windows Server 2008 Native Domain Functional Level. You can check the schema version of your forest by looking at the objectVersion attribute on the Schema object. You can view this with ADSIEdit or with a Dsquery command:

dsquery.exe * "CN=Schema,CN=Configuration,DC=contoso,DC=com" -scope base -attr objectversion

Here is what the versions will mean:

47 = Windows Server 2008 R2
44 = Windows Server 2008
31 = Windows Server 2003 R2
30 = Windows Server 2003
13 = Windows 2000

DFSR on member servers

Here things get a bit muddier. When we extend the schema to version 44, fifteen new DFSR-related attributes are added. Here’s a table describing them:

Attribute name

Status

ms-DFSR-CachePolicy

Not currently used by DFSR code

ms-DFSR-CommonStagingPath

Not currently used by DFSR code

ms-DFSR-CommonStagingSizeInMb

Not currently used by DFSR code

ms-DFSR-DefaultCompressionExclusionFilter

Used by Windows Server 2008 DFSR

ms-DFSR-DeletedPath

Not currently used by DFSR code

ms-DFSR-DeletedSizeInMb

Not currently used by DFSR code

ms-DFSR-DisablePacketPrivacy

Not currently used by DFSR code

ms-DFSR-MaxAgeInCacheInMin

Not currently used by DFSR code

ms-DFSR-MinDurationCacheInMin

Not currently used by DFSR code

ms-DFSR-OnDemandExclusionDirectoryFilter

Not currently used by DFSR code

ms-DFSR-OnDemandExclusionFileFilter

Not currently used by DFSR code

ms-DFSR-Options2

Not currently used by DFSR code

ms-DFSR-Priority

Not currently used by DFSR code

ms-DFSR-ReadOnly

Used by Windows Server 2008 DFSR

ms-DFSR-StagingCleanupTriggerInPercent

Not currently used by DFSR code

It turns out only two of these new attributes are actually used. The rest are reserved for the future of DFSR (and some are pretty tantalizing, aren’t they? Please don’t get your hopes up too high; there are R2 DFSR attributes that are still unused).

So by extending the schema, there are only two attributes added. What if we didn’t bother? The good news is DFSR will still work fine, replicate data, and not give you any errors or problems about these attributes. The downside is:

  1. You would not be able to make full use of the ms-DFSR-DefaultCompressionExclusionFilter functionality described in KB951003.
  2. You would not be able to make use of the msDFSR-ReadOnly functionality (which is only for RODC’s anyway, so no big loss if you are not using them).

And yes – Win2008 and Win2003 R2 DFSR servers will still happily replicate with each other in this scenario.

So is that it?

Of course not! There is really no compelling reason not to upgrade your schema once you have started to deploy Windows Server 2008 and Vista. If you don’t extend, you won’t get all the other interesting attributes that you might find useful. Things like Bitlocker Drive Encryption Recovery, Credential Roaming, DFS Namespace Version 2, Read-Only Domain Controllers, and the aforementioned DFSR SYSVOL support. These are really compelling features and you’ll need your schema extended to get them.

If you need to track down all the other schema changes made by Win2008, the best two references are:

As always, feel free to comment below. This is ASKDS after all…

(Update 6/3/09 - now includes 2008 R2 schema version. And no, there are no new Schema updates for DFSR in 2008 R2, nor do any of the reserved Schema updates described above change for R2 or start being used.)

- Ned Pyle

  • PingBack from http://windows2008security.com/network-security/what-are-the-schema-extension-requirements-for-running-windows/

  • The list is a little longer today because of not posting last week. Enjoy! Microsoft Advanced Windows

  • Hello, everyone Below you have a compilation of some very interesting blog posts from AskDS and Extreme

  • Check out the following posts: What is the purpose of the 'Deleted' folder in DFSR? DFSR and

  • Microsoft Support Documents 2008 "Lag site" or "hot site" (aka delayed replication) for Active Directory Disaster Recovery support

  • Hi Ned,

    I'm interested particular in the msDFSR-ReadOnly attribute.

    What would happen if you set this on a custom replication group (i.e. not SYSVOL)?

  • Hi,

    Here's a reprint of some things I wrote in an internal article for MS Support Engineers. Basically, you can do it, but it's entirely at your own risk and there can be... unexpected results. :-/

    - This read-only system in Win2008 was designed for SYSVOL and RODC's - it does not

    scale well with large amounts of data, nor with highly dynamic data.

    - It was never tested by MS Development for custom datasets - there may be catastrophic results with large data sets.

    - It is totally unsupported by Microsoft except for SYSVOL RODC.

    - If there are issues there will be no Dev/3rd tier CSS support - customer must undo the change and follow recommended share permissions method.

    - You cannot have servers be read-only where they pull from another read-only. The relationship must always be read-write and read-only. This may necessitate a custom topology.

    - There is no DFSMGMT.MSC interface for this by design.

    - As you can tell by now, this system is not true read-only - it is a 'latent automatic undo'. So users will find it confusing when they appear to save data only to have their changes or files disappear.

    But all is not lost - take a look at:

    Introduction to Windows Server 2008 R2 - http://download.microsoft.com/download/F/2/1/F2146213-4AC0-4C50-B69A-12428FF0B077/Windows_Server_2008_R2_Reviewers_Guide_(BETA).doc

    We have a real read-only feature under development in Win7. :)

    - Ned

  • Thanks Ned, that is fantastic information - I hope this goes ahead.

    This is slightly unrelated, but I just have a quick question, which I can't seem to find an answer on anywhere.

    Is there a way to manually change a DFS folder target to belong to a different site?

    We are consolidating all of our file servers in to data centres and out of branch offices, but we still need to seperate the resources for each individual office (they will all be connected in via fibre).

    So say Site1 is our data centre and hosts our data, and we have Site2 and Site3 which need their own resources, I wanted to have a share for each site which maps to data on the server in Site1 and have those shares present themselves accordingly to Site2 and Site3 via DFS.

    Can you point me in the right direction?

  • Cool. :)

    To your next question, the way we usually change a target to belong to another site is to make sure that the server it lives on is associated with a subnet, which is itself associated with a site. So in DSSITE.MSC, we'd make sure that a subnet was defined. We'd then link that to the site that was appropriate. And the server folder target should belong to that actual IP subnet range.

    Let me know of that doesn't make sense 100%. A bit more info (don't worry that they are 2003 R2 centric, it's no different in 2008 for this subject):

    http://technet.microsoft.com/en-us/library/cc737358.aspx

    http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx

    - ned

  • Thanks again,

    I realised I missed the most critical piece of information from my last question!

    The shares that I was speaking of will actually be on the same server, so I guess what I was hoping is that there was a way to manually re-assign an individual folder target to a different site, even though they were on a server that exists in an unrelated site.

    Sounds dodgy, I know, and I can't see that it is possible; but I'm hoping there's a way to achieve this (or something like it)!

  • Not possible, I'm afraid. The boundary is the server target itself.

    Now... There's nothing that stops you from pointing a DFS target to another DFS target. So in theory, your first target folder in one site could actually point to another DFS target altogether, which itself resides in another site. But it doesn't sound like that would meet your needs for this...

    - ned

  • Yeah, thought it was a long shot...

    Thanks for your help!

  • We’ve been at this for over a year (since August 2007), with more than 100 posts (127 to be exact), so

  • The previous post explained the concept of a read-only replicated folder. Now, let us take a look at