Blog - Title

January, 2009

  • Remote Server Administration Tools (RSAT) Available For Windows 7 Beta

    Ned here. For those testing Windows 7 administration capabilities, this is for you.

    Download here

    This is the list of Windows Server 2008 administration tools which are included in Win7 RSAT Client:

    Server Administration Tools:
    • Server Manager

    Role Administration Tools:
    • Active Directory Certificate Services (AD CS) Tools
    • Active Directory Domain Services (AD DS) Tools
    • Active Directory Lightweight Directory Services (AD LDS) Tools
    • DHCP Server Tools
    • DNS Server Tools
    • File Services Tools
    • Hyper-V Tools
    • Terminal Services Tools

    Feature Administration Tools:
    • BitLocker Password Recovery Viewer
    • Failover Clustering Tools
    • Group Policy Management Tools
    • Network Load Balancing Tools
    • SMTP Server Tools
    • Storage Explorer Tools
    • Storage Manager for SANs Tools
    • Windows System Resource Manager Tools

    If you need any kind of support, head on over to the TechNet forums or drop us a line here.

    - Ned Pyle

  • Using Group Policy Preferences to Map Drives Based on Group Membership

    Hello AskDS Blog Readers, Mike here again! A common request we hear is how to automatically connect specific network shares to drive letters based on group membership. Mapping network drives based on group membership requires some programming knowledge-- either VBScript or command shell (batch files). VBScript based logon scripts can require hundreds of lines of code to provided a complete solution. And batch files require the assistance of helper applications such as IFMEMBER.EXE and NET.EXE, and introduce many challenges with controlling how Windows processes the script. But Group Policy Preferences removes the programming requirement and awkwardness of scripting mapped drives based on group membership. There are many scenarios in which you may want to map a local drive letter to a specific network share to include public drive mappings, inclusive group drive mappings, and exclusive group drive mappings.

    Public drive mappings typically do not require membership to a particular group. However, sometimes public drive mappings do not provide enough granularity. Most organizations have data specific to business units such as accounting, marketing, or human resources.. Inclusive Group Drive mappings solve this problem by allowing a configuration that maps a specific drive letter to a specific network share based on the user being a member of a particular group. This ensures members of the accounting unit receive drive letters mapped for accounting and members of human resources map their respective drives. Exclusive drive mappings are not very common; however, they do provide the flexibility to prevent a user from mapping a particular drive letter to a network share if they are not a member of a specific group. A good example of exclusive drive mappings is to prevent the CIO or other executives members from mapping a drive letter in which they are likely to never use. Let us take a closer look at these scenarios

    Public drive mappings

    Producing a Group Policy Preference item to create public drive mappings is simple. The GPO containing the preference item is typically linked to higher containers in Active Directory, such as a the domain or a parent organizational unit.

    Configuring the drive map preference item.

    image

    Figure 1 Configuring mapped drive preference item

    Newly created Group Policy objects apply to all authenticated users. The drive map preference items contained in the GPO inherits the scope of the GPO; leaving us to simply configure the preference item and link the GPO. We start by configuring the drive map preference item by choosing the Action of the item. Drive map actions include Create, Replace, Update, and Delete. These are the actions commonly found in most preference items. Create and Delete actions are self-explanatory. The compelling difference between Replace and Update is that Replace deletes the mapped drive and then creates a new mapped drive with the configured settings. Update does NOT delete the mapped drive-- it only modifies the mapped drive with the new settings. Group Policy Drive Maps use the drive letter to determine if a specific drive exists. The preceding image shows a Drive Map preference item configure with the Replace action. The configured location is a network share named data; hosted by a computer named hq-con-srv-01. The configured drive letter is the G drive. All other options are left at their defaults. This GPO is linked at the contoso.com domain.

    The results of this configuration are seen when using Windows Explorer on the client computer. The following picture shows a user's view of Windows Explorer. We see there is one network location listed here, which is the G drive that is mapped to \\hq-con-srv-01\data.

    image

    Figure 2 Public drive map client view

    Later, we'll see how to use exclusive drive mappings with public drive mappings as a way to exclude public drive mappings from a subset of users.

    Inclusive drive mapping

    Inclusive drive mappings are drives mapped to a user who is a member of (or included) in a specific security group. The most common use for inclusive drive maps is to map remote data shares in common with a specific sub set of users, such as accounting, marketing , or human resources. Configuring an inclusively mapped drive is the same as a public drive mappings, but includes one additional step. The following image shows us configuring the first part of an inclusive drive mapping preference item.

    image

    Figure 3 Inclusive drive mapping

    Configuring the first part of an inclusive drive mapping preference item does not make it inclusive; it does the work of mapping the drive. We must take advantage of item-level targeting to ensure the drive mapping items works only for users who are members of the group. We can configure item level targeting by clicking the Targeting button, which is located on the Common tab of the drive mapping item. The targeting editor provides over 20 different types of targeting items. We're specifically using the Security Group targeting item.

    image

    Figure 4 Security group targeting item

    Using the Browse button allows us to pick a specific group in which to target the drive mapping preference item. Security Group targeting items accomplishes its targeting by comparing security identifiers of the specified group against the list of security identifiers with the security principal's (user or computer) token. Therefore, always use the Browse button when selecting a group; typing the group name does not resolve the name to a security identifier.

    image

    Figure 5 Configured inclusive security group targeting item

    The preceding screen shows a properly configured, inclusive targeting item. A properly configured security group targeting item shows both Group and SID fields. The Group field is strictly for administrative use (we humans recognize names better than numbers). The SID field is used by the client side extension to determine group membership. We can determine this is an inclusive targeting item because of the text that represents the item within the list. The word is in the text "the user is a member of the security group CONTOSO\Management." Our new drive map item and the associated inclusive targeting item are now configured. We can now link the hosting Group Policy object to the domain with confidence that only members of the Management security group receive the drive mapping. We can see the result on a client. The following image shows manager Mike Nash's desktop from a Windows Vista computer. We can see that Mike receives two drive mappings: the public drive mapping (G: drive) and the management drive mapping (M: drive).

    image

    Figure 6 Client view of inclusive drive mapping

    Exclusive drive mapping

    The last scenario discussed is exclusive drive mapping. Exclusive drive mappings produce the opposite results of an inclusive drive mapping; that is, the drive map does NOT occur if the user is a member of the specified group. This becomes usefully when you need to make exceptions to prevent specific drives from mapping. Let's add an exclusive drive mapping to our public drive mapping to prevent specific members of management from receiving the public drive mapping.

    image

    Figure 7 Configured exclusive drive mapping

    The preceding image shows the changes we made to the public drive mapping (from the first scenario). We've added a Security Group targeting item to the existing public drive mapping preference item. However, the targeting item applies only if the user IS NOT a member of the ExcludePublicDrives group. We change this option using the Items Options list. The client view of manager Monica Brink shows the results of applying Group Policy.

    image

    Figure 8 Client view of exclusive drive mapping

    This client applies two Group Policy objects; each containing a drive mapping preference item. One item contains our public drive mapping with an exclusive security group targeting item. The other GPO contains the management drive mapping with an inclusive security group targeting item. The client processes the public drive mapping GPO; however, the exclusive targeting item verifies that Monica is a member of the ExcludePublicDrives group. Monica is also a member of the Management group. Therefore, Monica's group memberships prevent her from receiving the public drive mapping and include her in receiving the management drive mapping.

    Summary

    Drive mapping preference items do not require any scripting knowledge and are easy to use. Leveraging targeting items with drive mapping items increases the power in which to manage drive mapping to users and computers. Public drive mappings are typically linked at higher levels in the domain and generally apply to a large subset (if not all) users. Inclusive drive mappings associate as specific subset of data with a specific group of people, often times mapping to logical divisions within an organization such as accounting, marketing, or human resources. Exclusive drive mappings invert the principals of inclusive drive mappings. The user must not be a member of the specified group for the drive mapping to occur.

    Best practices

    Be sure to link GPOs high enough in Active Directory so the scope of the drive mapping effects the largest group of user accounts. Obviously, not every GPO should be linked at the domain; however, if there is an accounting organizational unit with three child OUs-- then linking at the Accounting OU effects that largest amount of users. Allow your inclusive and exclusive targeting item to do the bulk of your work. GPOs hosting inclusive drive mappings are best used when the number of user needing the drive mapping are fewer than the number who do not. Exclusive drive mappings are best used when the number of user not requiring the drive mapping are fewer than the number that do. These rules help prevent users from becoming members of too many groups and increasing the cost of managing drive mappings within the organization.

    - Mike “Play Some Skynyrd!’ Stephens

  • DFSR SYSVOL Migration FAQ: Useful trivia that may save your follicles

    Hi, Ned here again. Today I'm going to go through some well-hidden information on DFSR SYSVOL migration; hopefully this sticks in your brain and someday allows you to enjoy your weekend rather than spending it fighting issues.

    As you already know, Windows Server 2008 introduced the ability to use Distributed File System Replication (DFSR) to replicate your SYSVOL folder, rather than the legacy File Replication Service (FRS). And there was much rejoicing. The step-by-steps for this process are documented here:

    1: SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process
    2: SYSVOL Migration Series: Part 2 – Dfsrmig.exe: The SYSVOL migration tool
    3: SYSVOL Migration Series: Part 3 – Migrating to the ‘PREPARED’ state
    4: SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state
    5: SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state

    (And before you get wound up in the Comments section - Yes, there is a TechNet Whitepaper for this coming just as soon as we can get it published! Don't hurt me!)

    So let's run through some Q & A.

    Q: What are the Domain Controller availability requirements during my migration?

    A: There are a couple.

    1. The PDC Emulator must be online any time the DFSRMIG tool is being invoked for a read or write operation. If the PDC Emulator is offline or inaccessible for LDAP, the user of DFSRMIG will receive:

    “Unable to connect to the Primary DC’s AD.

    Please make sure that the PDC is reachable and try the command later.”

    2. All DCs must remain online until they each complete their state steps. All DCs do not need to be accessible simultaneously. But the global state will never reach the Prepared, Redirected, or Eliminated state until all DCs have been able to complete their individual phases.

    The PDC Emulator requirement is because by default, administrators always edit group policy on the PDCE, so in most environments it will have the most up to date knowledge of policy. That and we need to talk to someone unique, so it might as well be him.

    It is recommended that a SYSVOL migration not be attempted unless all DCs are online and available. Change control blackouts should be scheduled to prevent modification to DCs that might impact their availability. This will minimize the window of time that the migration will take.

    Q: Is there some super-secret way to return to using FRS after reaching the Eliminated phase of DFSR migration?

    A: Microsoft does not support returning your domain to using FRS for SYSVOL replication after a completed DFSR migration (except to rebuild the domain). This is why the steps are done in a phased approach with two checkpoints where you can revert back to FRS without any consequences. Once you trigger the ELIMINATED phase to start, there is no going back, period.

    image

    Q: When does Robocopy run during the migration and what does it do?

    A: The DFSR service uses robocopy at several stages to synchronize SYSVOL directories outside of normal replication when it detects a SYSVOL migration is underway; a set of ‘pre-seeding’ and ‘save the GP admins from themselves’ operations.

    1. When Prepared state (DFSRMIG /SETGLOBALSTATE 1) is invoked, all DC’s robocopy their FRS SYSVOL data locally into the new DFSR content set. This is equivalent to ‘pre-seeding’ data and ensures that minimal file replication occurs to converge the content set. This is triggered by the DFSR service itself when:

    • AD replication has converged between a DC and the PDCE.
    • The DFSR service on that DC has polled (this runs every 5 minutes) and picks up the state change from CN=dfsr-LocalSettings

    2. When entering the Redirected state, the PDC Emulator (only) robocopies the local differences of FRS SYSVOL data into the new local DFSR content set, on itself. The other servers receive new data via replication.

    3. If you undo the Redirected state back to Prepared, the reverse happens. The PDC Emulator robocopies its local DFSR content set data into its local FRS content set. FRS replication synchronizes all other servers... eventually. Allow more time for this than entering Redirected, as FRS is not as fast to synchronize as DFSR.

    For sharp-eyed readers: we won’t run into any of the old pre-seeding issues (the file hash being changed by robocopy) here because DFSR correctly creates the SYSVOL_DFSR folder ACL, so there are no inheritance issues when the contents are copied in and replicated.

    Q: Event 8004 says something about RODC's. I don't have any RODC's. What the frak?

    A: The following event is incorrectly written in the DFSR event log(s) on servers that are not Read-only Domain Controllers when setting elimination state using DFSRMIG.EXE:

    Log Name: DFS Replication
    Source: DFSR
    Date: 9/28/2007 11:53:46 AM
    Event ID: 8004
    Task Category: None
    Level: Information
    Keywords: Classic
    User: N/A
    Computer: <WRITABLE DC>
    Description:
    The NTFRS member object for the Read-only Domain Controller <WRITABLE DC> was deleted successfully.

    Well, it finally happened – we had a bug. No, no, don’t try to tell me it’s not possible, it was bound to occur someday. :)

    The text in the event log is completely cosmetic and benign. It is supposed be fixed in a later version of the OS. Just ignore it.

    Q: What are all the AD and Registry state values that will be set at a given point in the migration?

    A: Ok, you asked for it buddy.

    =============

    1. Prepared Phase - DFSRMIG /SETGLOBALSTATE 1

    a. DFSRMIG contacts the PDC Emulator directly.

    b. Global objects are created under:

    CN=DFSR-GlobalSettings,CN=SYSTEM,DC=<domain>
    CN=DOMAIN SYSTEM VOLUME
      CN=SYSVOL SHARE
       CN=CONTENT
        CN=TOPOLOGY

    c. CN=DFSR-GlobalSettings now has msDFSR-Flags attribute set to 0.

    d. As DC's pick up the globalstate change via AD replication and DFSR service polling, they create and write to registry entry:

    HKLM\System\CurrentControlSet\Services\DFSR\Parameters\Sysvols\Migrating Sysvols
    Local State = 4
    [REG_DWORD]

    e. The PDC Emulator creates the:

    CN=dfsr-LocalSettings,CN=<servername>,DC=<domain>

    objects for all DCs and sets this attribute to:

    msDFSR-Flags = 80 (if RWDCs).
    msDFSR-Flags = 64 (if RODCs - the RODC itself will set it to 80 later).

    f. The DFSR service has now started and created the new local SYSVOL_DFSR structure. Robocopy has made a local copy of the FRS SYSVOL. All AD topology data has been written in to support the content set. Initial sync of the data has started (since robocopy has locally pre-seeded the data this should involve minimal replication data on the network). The registry on all DC's is:

    Local State = 5 [REG_DWORD]

    g. Once initial sync is done on all DCs:

    Local State = 1 [DWORD]
    'msDFSR-Flags' (on CN=dfsr-LocalSettings) = 16

    h. If DFSRMIG /GETGLOBALSTATE returns that all DCs are prepared, 'msDFSR-Flags' on CN=dfsr- GlobalSettings has changed to 16 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with FRS being shared as SYSVOL.

    =============

    2. Redirected Phase - DFSRMIG /SETGLOBALSTATE 2

    a. DFSRMIG contacts the PDC Emulator directly.

    b. CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 96 on all DCs and this replicates out through AD.

    c. As DCs pick up the attribute from AD replication, their DFSR service sets:

    Local State = 6 [REG_DWORD]

    d. On the PDC Emulator only, robocopy syncs any changes between the FRS and DFSR's content sets, and this is replicated out through DFSR.

    e. Once SYSVOL data is in sync, SYSVOL content set is set to be the active SYSVOL share on all servers. FRS and DFSR are both still replicating data.

    f. When this is complete, for each DC:

    Local State = 2 [DWORD]
    'msDFSR-Flags' (on CN=dfsr-LocalSettings) = 32

    g. If DFSRMIG /GETGLOBALSTATE returns that all DCs are redirected, 'msDFSR-Flags' on CN=dfsr- GlobalSettings has changed to 32 because all DCs are prepared. All DCs are currently replicating DFSR and FRS content sets, with DFSR being shared as SYSVOL.

    ==============

    3. Eliminated Phase - DFSRMIG /SETGLOBALSTATE 3

    a. DFSRMIG contacts the PDC Emulator directly. At this point it is not possible to undo the changes!

    b. CN=DFSR-LocalSettings now has msDFSR-Flags attribute set to 112 on all DCs and this replicates throughout AD.

    c. As DCs pick up the attribute from AD replication, their DFSR service sets:

    Local State = 7 [REG_DWORD]

    d. On the PDC, the FRS content set information is removed and this is replicated through AD. As each DC sees this change, their FRS service stops replicating the FRS content set. The FRS service is stopped (and restarted if custom FRS sets still exist on a given server).

    e. When this is complete, for each DC:

    Local State = 3 [DWORD]
    'msDFSR-Flags' (on CN=dfsr-LocalSettings) = 48

    f. If DFSRMIG /GETGLOBALSTATE returns that all DCs are eliminated, 'msDFSR-Flags' on CN=dfsr-GlobalSettings has changed to 48 because all DCs are prepared. All DCs are currently replicating DFSR only.

    g. A final cleanup task on each DC will set their 'msDFSR-Flags' on CN=dfsr-LocalSettings to <NOT SET>. The same will happen from the PDC to CN=dfsr-GlobalSettings.

    ==============

    If any 'undo' phases are entered (where an administrator has decided to go from redirected back to prepared, redirected back to start, or prepared back to start), the flow above happens in reverse, with the exception that the following two entries exist in the 'Local State' registry entries:

    8 (Undo Redirecting)
    9 (Undo Preparing)

    Q: I'm not a huge fan of Ultrasound. Are there any other ways to validate the health of SYSVOL prior to and after migration?

    A: Sure thing - already discussed in a previous blog post here.

    Q: Are there any migration KBs or bugs I need to worry about?

    A: One KB, with a simple solution to domains that have non-standard (and frankly, not any safer than default) security configurations: http://support.microsoft.com/kb/2567421

    And that’s it. If you have any questions on DFSR SYSVOL migration not covered by this blog post or by the FileCab step-by-step guide, don’t hesitate to start swinging in the Comments section below.

    - Ned “Working on Windows 7 Beta But Still Has An Unnatural Love for Win2008 DFSR” Pyle

  • Windows Server 2008 R2 DFSR Features

    Ned here again. The cat is out of the bag now and we're a little more free to talk about DFSR features that are planned (not guaranteed - planned) to release with Windows Server 2008 R2. Our friends at the File Cabinet blog have posted an excellent writeup - definitely worth a look:

    DFS Replication: What’s new in Windows Server™ 2008 R2

    Here's the short and sweet list of areas that were added or improved:

    • Support for Windows Failover Clusters
    • Read-only Replicated Folders (now with true filter driver support)
    • SYSVOL on Read-only Domain Controllers (leveraging the improved Read-only functionality)
    • Diagnostics Improvements (DFSRDIAG adds support for replication state, record translation, and file hash checking for pre-seeding)

    You can try all these out in a test environment right now - hurry up and grab the ISO's before it's too late.

    - Ned 'The Short Simpson' Pyle

  • Negotiate security support provider behavior

    Greetings DS blog readers, Todd here. I wanted to talk a little about the Negotiate security support provider (SSP) and how there are times when it will intentionally use NTLM rather than Kerberos. [And if that’s not interesting, keep reading anyway because there is a slick trick in here for network captures - Editor]

    In a properly configured and functioning domain when SSP Negotiate is utilized and the client application resides on the target server to be accessed, SSP Negotiate will choose NTLM instead of Kerberos. Microsoft Negotiate acts as an application layer between Security Support Provider Interface (SSPI) and the other SSPs. When an application calls into SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.
    Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication, the calling application did not provide sufficient information to use Kerberos, or the client and server are the same machine. For efficiency and security reasons NTLM is chosen over Kerberos when the client and the server are the same machine. This behavior is by design.

    How to reproduce the behavior

    Note: The test computer must be part of a domain and on a routed network for the reproduction to work.

    1. On your test computer create a share.
    2. Install a network capture utility. (Netmon, Wireshark, etc...)
    3. Add a network route to the test machine to allow network traffic to be seen with the source and destination are the same location.
    Run the following command on the machine where you need to see the to and from traffic on itself:

    route add <IP Address of the server that you are on> <IP Address of default gateway of the server you are on>

    This causes the server to send internal packets over the network that would ordinarily stay completely local and not be viewable in a network trace. The packets will just return to the test computer itself.

    PLEASE NOTE: To remove the “route add” issue the command “route add <IP Address of the server that you are on>”

    Note that each packet going from the server to itself will appear twice ... once exiting the server on its way to the router, once returning from the router on its way back to the server. You can ‘post-process’ the capture to eliminate the duplicate packets (i.e. don't display the packets where the source Ethernet address matches the router).

    In Netmon 3.x you can use a Display Filter constructed similar to:

    HTTP and Ethernet.SourceAddress == 0x010203040506

    For Wireshark you can use the following display filter:

    (tcp.port == 80) && (eth.src == 01:02:03:04:05:06)

    You will need to replace the 0x0102030405 or the 01:02:03:04:05:06 with the MAC address of your web server.

    4. Start the network capture.
    5. Access the share on the test computer from the test computer (i.e. from itself, to itself).
    6. Stop the network capture.
    7. Review network trace.

    You should see the following sequence in the trace:

    i. A GET request
    ii. A HTTP 401 Unauthorized response with:

    WWW-Authenticate:Negotiate

    …in the HTTP header

    iii. A second GET request with NTLM authentication

    Here is the workaround

    In order to allow a client application to utilize Kerberos in this usage scenario; the following steps can be enacted.

    1. Create an alias (CNAME) host record for the machine with a unique name for the forest. This can be accomplished using the DNS snap-in, expanding out he forward lookup zone for the domain which contains the web server, right clicking on the domain name and select New Alias (CNAME)…

    2. Register SPNs for the alias on the computer object. You can use Setspn to register an SPN which would be formatted similar to “Setspn –A HTTP/<alias_ you _registered_in_DNS> <webservername>”

    3. When accessing the machine with a browser use the alias. This will allow Kerberos to be utilized even if the client resides on the server.

    References
    http://msdn.microsoft.com/en-us/library/aa378748(VS.85).aspx

    I hope this has been enlightening.

    Best regards,

    Todd Maxey

  • Microsoft North Carolina, Directory Services Team 3 – Doh!

    Ned here. We’ve been asked a few times to show a picture of the DS Support teams that you work with everyday. I’m finally able to oblige you for my team courtesy of the outstanding SimpsonizeMe website, run by the good folks at Burger King. See if you recognize any names from support cases you’ve worked or blogs you’ve read.

    simpsons team3

    The back row, from left to right: David Beach, David Fisher, Gary Mudgett, Jonathan Stephens, Rob Greene, Sean Ivey, Steve Taylor, Tait Neville.

    The front row, from left to right: Mike Stephens, Ned Pyle, Adam Conkle, Chris Cassidy.

    And don’t worry, this didn’t affect any SLA’s – our manager put it together on his own time. We tried to get him in here too but his face was too hideous for the tool to read; it simply rejected him. Make sure you give the SimpsonizeMe site a try, it’s fun stuff.

    - Ned “Mmmmm… Whopperrssss.” Pyle

  • Windows 7 for TechNet and MSDN Subscribers

    Ned here. Come and get it... :)

    Press Release 
    TechNet Subscribers
    MSDN Subscribers

    For all others, you'll have to wait until Friday. Oh the humanity.

    Just a quick reminder - unless you are part of TAP, TechBeta, or OEM Beta, you cannot get support for Windows 7. If you don't know what those three things are, you aren't in them. This goes for Premier customers, Pro customers, people with MSDN or TechNet Support 5-packs, and the rest - please don't bother trying to open a case with us about it.

    This beta is for your evaluation purposes and general lovin', but do not use it for mission critical systems or where problems with your OS is going to cost you money. In short - use your head and enjoy the new OS goodness. :)

    If you have already snagged it (public release, TechNet, MSDN, or.. otherwise) make sur to stop by the TechNet forums for any support or bug reporting. And you can always drop us a comment here too, naturally.

    - Ned Pyle

  • Understanding the behavior differences of SYSVOL replication in Windows Server 2008 RODCs

    Hi, Ned here again. Are you tired of me blogging about DFSR and FRS yet? If so, stop reading. :)

    Today I am going to describe the architectural differences of SYSVOL replication on Read-Only Domain Controllers in Windows Server 2008 – FRS versus DFSR. This makes another good case for taking the effort of getting your domain functional levels to 2008 and migrating off of the File Replication Service.

    Before I get rolling, a mini-glossary:

    RODC - Read-Only DC (Introduced in Windows Server 2008)
    RWDC - Writable DC (introduced in Windows 2000 Server)
    FRS - File Replication Service (introduced in Windows 2000 Server)
    DFSR - Distributed File System Replication (introduced in Windows Server 2003 R2)

    Running RODCs with FRS as the replication engine for SYSVOL

    While FRS can be used, it has some significant downsides in its behavior if the environment is not carefully administered. Since RODCs are designed to be placed in locations that will not have administrators or very basic role-separated administrators, this can be problematic. FRS does not contain the full plumbing to undo changes, but instead only prevents changes from leaving the DC.

    • Files/folders created, modified, or deleted replicate from RWDC to RODC.
    • Files/folders created, modified, or deleted do not replicate from RODC to
      RWDC.
    • All changes within SYSVOL on the RODC survive inbound replication unless the
      same file path was changed upstream.

      (Example Scenario)
    1. SYSVOL contains 2 policies for Default Domain and Default DC.
    2. On the RODC an administrator adds a folder called 'my stuff'.
    3. He also manually deletes the registry.pol file from the Default DC policy.
    4. He also changes a gpttmpl.inf file to contain no data.

      (Outcome)
    5. The folder called 'my stuff' continues to exist forever, unless deleted on the RODC or created on the RWDC, replicated down, and then deleted on the RWDC.
    6. The registry.pol file stays deleted until it is updated on the RWDC and replicated back down to the RODC.
    7. The gpttmpl.inf file stays empty until it is updated on the RWDC and replicated back down to the RODC.

    As you can imagine, using FRS to replicate RODC SYSVOL folders has some administrative caveats and is not recommended. FRS ,as a feature, has effectively been deprecated (as you can tell from here and the Windows Server 2008 administration tools – where did DFSGUI.MSC go?).

    Running RODCs with DFSR as the replication engine for SYSVOL

    DFSR offers some architectural advantages that make it very compelling for RODCs.

    • Files/folders created, modified, or deleted replicate from RWDC to RODC.
    • Files/folders created, modified, or deleted do not replicate from RODC to
      RWDC.
    • All changes within SYSVOL on the RODC are undone immediately by the DFSR
      service (i.e. they revert to whatever the RWDC has currently, allowing for replication latency).

      (Example Scenario)
    1. SYSVOL contains 2 policies for Default Domain and Default DC.
    2. On the RODC an administrator adds a folder called ‘some goo’.
    3. He also manually deletes the contents of the Default Domain policy.
    4. He also changes a gpt.ini file to not contain any data.

      (Outcome)
    5. The folder called 'some goo' is immediately deleted.
    6. The missing contents of the Default Domain policy is replicated back in as fast as replication allows.
    7. The unmodified gpt.ini file is replicated back in as fast as replication allows.

    For these reasons, DFSR-based SYSVOL replication (available when running in Windows
    Server 2008 Domain Functional Mode) is recommended.

    PS: Have you downloaded Windows Server 2008 R2 yet and deployed DFSR in a test environment? You are in for some surprises there with read-only. You should check that out

    - Ned “My First Born Was Named USN Journal” Pyle