Hello everyone!

Adam has published a new round of content for Active Directory Federation Services (ADFS) to the TechNet Wiki. These articles include troubleshooting information and how-tos to assist you when you are evaluating, implementing, or troubleshooting ADFS.

AD FS 2.0 - How to change the Federation Service Name 

AD FS 2.0 - How to capture a log during installation (AdfsSetup.exe) 

AD FS 2.0 setup fails to install PowerShell feature on Windows Server 2008 

Windows Identity Foundation (WIF) - A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo..."). 

Windows Identity Foundation (WIF) - How to protect static content with the Federation Authentication Module (FAM) 

AD FS 2.0 - Federation Server Proxy servers fail to authenticate users - Events 248 and 996 logged 

AD FS 2.0 - How to change the local authentication type

 -- Jonathan "Ned's Blog Monkey" Stephens

Hi everyone, we have a few new and updated articles from last week that are Directory Services related. 

And I just noticed that the last post put us to our 500th article. That’s a post every 205,200 seconds! Wait, that doesn’t sound impressive. That’s a post every 2.3 days! OK, not quite Raymond Chen or Keith Combs, but it will have to do.

You have kept us going with your comments, questions, and readership – thanks very much.

- Ned “User profile cannot be loaded” Pyle

Hello everybody, Ned here again to share some conversations. This week I talk some SMB security, domain renames, file compression, and DFSR DFSR DFSR!

• Domain rename registry key orphans and determining if a rename ever happened
• DFSR compression recommendations for Office 2007+
• "Server SPN target name validation level"
• Clustering DFSR on WIn2003 and Win2008 non-R2
• DFSR removal
• Other stuff

Question

I successfully renamed my domain some years ago and but I find some registry values that reflect the old name. Those values are also present in my test domain where I tested the rename before I renamed the production environment. They are values in HKEY_LOCAL_MACHINE\System\currentcontrolset\Services\NTDS\Parameters, such as "Configuration NC" and "Src Srv objectGuid". Do you know why those keys are not cleaned out or changed by rendom.exe? And how do I tell if a domain has been renamed?

Answer

Those value names are not vital and it’s up to LSASS.EXE and DCPROMO.EXE (not rendom.exe) to populate them; there will be a few others, depending on the DC being first created or later added, such as “Src Root Domain Srv” and “Root Domain”. They are used during the DC promotion process but after that they are no longer used. There are a few others like this in DCs – for instance, in the NetLogon key you will often find an abandoned AutoSiteName registry value that never changes to match reality. It’s not great fit and finish, but nothing fatal here. Keep in mind that domain rename came many years after AD was created so it’s unlikely the owners of NTDS ever expected these values to change outside DCPROMO.

If you want to update them for consistency that’s perfectly ok. After all, some application might decide (incorrectly) that it should use these values to make some decisions rather than correctly querying through APIs. If you want to be ultra-paranoid, you can demote each server in turn, then promote them back up and that will change those values for you. But that is crazy with a capital K.

As for your other question: as new DC’s are created they have the updated info, so it’s not possible to rely on these registry values to tell if a domain was renamed. If you look at the oldest DCs and see that they have SPNs registered for another domain, that might hint at it. The problem is that DC attrition may eventually remove those traces, and it still doesn’t emphatically mean a rename operation happened – it only shows that someone registered some other domain as SPNs for some reason.

The best way I can think of is to look at the version of the msDS-UpdateScript attribute on the “cn=partitions,cn=configuration,dc=<domain>” object. The only operation that’s supposed to change that attribute is a domain rename and it’s protected from direct alteration by administrators. If it’s version is higher than 1, a rename has likely been done.

Question

KB 951003 talks about how to turn off DFSR file staging compression for certain kinds of files. Does it make sense to also add the Office 2007/2010 .docx, .pptx, and .xlsx suffixes to this list because these file formats are also ZIP files?

Answer

It’s an excellent question and I agree: adding those to the exclusion list would generally be a good idea. For instance, here I zipped a large-ish DOCX file that did not include any pictures:

The savings with conventional WinZip against the default ZIP compression level of DOCX was only 1%. DFSR will not do any better and you will waste a (small) amount of time, disk, and CPU trying. It's such a good idea that it became the default in Windows Server 2008 R2. :)

Question

Can you could share some background information about the "Server SPN target name validation level" GPO setting? With our current information, setting the "Accept if provided by client" seemed to be a reasonable thing to incrementally increase our security configuration on DCs. Unfortunately we immediately hit a compatibility wall with some third party file appliances not working.

Answer

We bury this explanation as deep as possible; this setting was added to all supported versions of Windows (XP and later) with KB 973811 but only Vista and later know about it via group policy (security policy). What you are really modifying is the DWORD registry setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
SmbServerNameHardeningLevel

This article explains the setting and its rules (see the bottom section “More information about this update”, which naturally states nothing about the group policy):

2345886  Description of the update that implements Extended Protection for Authentication in the Server service - http://support.microsoft.com/default.aspx?scid=kb;en-US;2345886

If a 3^rd party has not updated their products to act more closely like Windows for things like Extended Protection or they are not following RFC2743 or if they are based on Win2000 or older OS emulation, or a host of other issues described in that article, they will fail using settings of 1 or 2. A network capture may show the issue in this case as to see why its failing or if you need to specify SrvAllowedServerNames entries – but it may also be that your appliance will not work until you contact that vendor to see how it must be reconfigured, updated, or that it’s a known issue and the appliance is incompatible.

Question

Can I cluster DFSR on Windows Server 2003 R2 or Windows Server 2008 non-R2? [asked by many people and seen in many support cases]

Answer

NOOOOOOOOOOOOOOOOOOO!

Question

Are you sure I cannot cluster it?

Answer

Yes, I am sure. People don’t seem to notice that when they cluster DFSR on Win2003 R2 it explodes their database and never replicates again after a node failover. Not to mention that we obviously spent millions of dollars to create a clustered DFSR in Windows Server 2008 R2 – why bother if it already worked? Plus we say you cannot cluster except on Win 2008 R2 all over the place.

Question

We successfully tested DFSR replication of user data across sites in our network. We now want to completely remove DFSR from both of the servers used in testing as they are going to be repurposed and I need to ensure I get back all the disk space, CPU, and memory. How can I make sure it’s totally removed?

Answer

Good question, we don’t document this (who would ever want to remove DFSR after all?!?! :-P ). This assumes you already removed Replication Groups or removed the members from replication, obviously:

To fully remove DFSR, you need to do the following:

1. Uninstall the DFSR role via Server Manager (on Win2008/R2) or Add/Remove Windows Components (Win2003):

2. Delete the folder(s) that you were replicating.

3. If using Win2008/R2, give yourself access to the hidden operating system folder “System Volume Information” on the C: drive with this command (that should be run as an elevated Admin user; if on Win2003 the Admin will already have permissions):

icacls "c:\system volume information" /grant Administrators:F

4. Repeat step 3 on any drives that had replicated folders, changing the path to that drive.

5. In that CMD prompt (don’t use Windows Explorer) you can then delete the “DFSR” folder that was left behind on those drives. That contains all the staged, pre-existing, and conflicted files in 2008/R2. It also contains the DFSR database and XML files in all versions of Windows. For example:

Rd “c:\system volume information\dfsr” /s /q

6. Repeat as needed on any other drives.

7. Done.

The reason you need to use a CMD prompt on Win2008/R2 is based on how Explorer special-cases the SVI folder and prevents anyone (even admins with full control permissions) from deleting its contents. You have to want it real bad, basically. Win2003 just lets you delete it arbitrarily because he is a punk.

Other stuff

Thanks to everyone who sent along nice emails about the Think Positive post, there were quite a few of you and I may not have responded to everyone. If you want to give those pleasant folks in Melbourne a little jolt of cash to keep their campaign going, click here.

They also sell the posters, but I will be sticking with what I already have up in my cubicle. I can only be so positive before I have to return to my roots…

 
No one at DePaul gets this anymore

Finally, to all the former and present US Marines, happy 235th birthday from an old leatherneck. In keeping with the tradition started in 1921, here is the 13th Commandant’s message:

On November 10, 1775, a Corps of Marines was created by  a resolution of Continental
Congress. Since that date many thousand men have borne the name "Marine". In memory of them it is
fitting that we who are Marines should commemorate the birthday of our corps by calling to mind the
glories of its long and illustrious history.

The record of our corps is one which will bear comparison with that of the most famous
military organizations in the world's history. During 90 of the 146 years of its existence the
Marine Corps has been in action against the Nation's foes. From the Battle of Trenton to the
Argonne, Marines have won foremost honors in war, and in the long eras of tranquility at home,
generation after generation of Marines have grown gray in war in both hemispheres and in every
corner of the seven seas, that our country and its citizens might enjoy peace and security.

In every battle and skirmish since the birth of our corps, Marines have acquitted themselves
with the greatest distinction, winning new honors on each occasion until the term "Marine" has come
to signify all that is highest in military efficiency and soldierly virtue.

This high name of distinction and soldierly repute we who are Marines today have received
from those who preceded us in the corps. With it we have also received from them the eternal spirit
which has animated our corps from generation to generation and has been the distinguishing mark of
the Marines in every age. So long as that spirit continues to flourish Marines will be found equal
to every emergency in the future as they have been in the past, and the men of our Nation will
regard us as worthy successors to the long line of illustrious men who have served as "Soldiers of
the Sea" since the founding of the Corps.

Have a nice weekend folks,

- Ned “0341” Pyle

In this line of work it‘s hard to remain optimistic. You deal with mistakes, bugs, ignorance. You repair more than you create. You often work for those who cannot comprehend what you do. Your most carefully laid plans unravel owing to the incredible complexity of distributed systems. You begin to expect the worst out of computers and people.

 
From  the not-for-profit Positive-Posters.com and neatorama.com

Remember the important things you are doing. The successful deployments. The proposals fulfilled. The problems fixed. The satisfaction that comes from your efforts making a real difference.

As Winston Churchill said, “I am an optimist - it does not seem to be much use being anything else.”

- Ned Pyle

Hi folks, Ned here again. A few years ago Dave Fisher wrote a treatise on how to migrate your domain-based DFS namespaces from one forest or domain to another. It works great and a lot of people have found his article helpful. Recently, a few customers have asked how they can migrate a namespace out of an old forest into a new one and keep the old domain namespace structure. Today I explain how you can make this variant work.

The Scenario

Contoso Inc. recently purchased Fabrikam Corporation. Fabrikam had a domain-based DFS Namespace structure called:

\\fabrikam.com\Public

Inside that root they have a few Link Targets that provide access to software installation shares, procedural manuals, and public shared documents:

\\fabrikam.com\public\software
\\fabrikam.com\public\procedural_docs
\\fabrikam.com\public\shared

These Links point to file servers in the Fabrikam domain currently, but those file servers are going to be migrated over to the Contoso.com domain with ADMT.

Some users have been pointed to these Links through logon scripts and others have just been using UNC paths or mapped drives they added themselves. At this point, telling a few thousand former Fabrikam users that these paths are not going to work anymore is not acceptable to management. The old fabrikam.com forest must be removed, as it represents a significant problem for the future with its dozens of DC’s, non-default security settings, backdoor high privilege users, and other unknown configuration changes.

Woo, I sound like an MCP question!

What Won’t Work

When admins first explore this scenario they usually come up with this list below; none of them are recommended though:

• Aliased DNS record for a standalone or domain-based DFS to “pretend” to be a forest

In theory you could have a forward lookup zone that resolves to a standalone DFS server so that it appears to be the old domain. But now you have the main disadvantage of standalone namespaces: they must be clustered for high availability. You could use domain-based DFS with multiple servers and create more complex manual DNS records. But in all cases you have to manually build and maintain SPNs to make Kerberos work. And this means that you cannot make any mistakes with DNS or SPN maintenance ever, especially if you plan on having computers access files through DFS – NTLM cannot be used by Windows to talk to other Windows computers; NTLM only works for users. Worst of all, you are creating a solution so customized and non-standard that it becomes a supportability problem for your colleagues and whoever replaces you someday.

• DFS Root Consolidation

DFS Root Consolidation shims non-DFS servers into a new standalone DFS namespace so that the old computer names continue to work. It does not handle consolidating old domain-based DFS namespaces into new ones.

What Will Work

The best answer is to recreate the same-named domain as a different tree in the Contoso.com forest once the old forest has been decommissioned. This solves all of those problems and can be maintained with little cost or effort:

• It has an identical namespace so users are not affected.
• The Contoso IT staff is creating a new domain so none of the old forest’s risk is brought over.
• It runs on minimal resources at low cost – just two DC’s are enough, and they can be virtualized; DFS can handle thousands of referrals a second without breaking a sweat. If you want to add more to individual sites to ensure local referrals, you can.
• There is no Trust maintenance and the domain will contain no users, groups, or member computers requiring operational overhead.
• The DCs do not have to be GCs nor host DNS application partitions, so they will not perform significant AD replication after promotion is complete.
• No DNS trickery is being used so the solution is good for the long term.

The Steps

Note: This article is not about ADMT or migrating file servers between domains, so I am going to gloss over those parts. If you need to learn more about that, review:

• Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains (Word version)
• ADMT Guide: Migrating and Restructuring Active Directory Domains (TechNet version)

Before you start, understand the timeline: this migration requires the old domain to be gone when the DFS migration is complete so that users can access their data without issues, and it requires that the DFS link target servers move to your new domain and be ready for use. This old domain is not coming back, so this would be the last step of a domain migration. This is going to happen on a weekend when users don’t need to access these file servers for a few hours; don’t do all this at 2PM on a Wednesday or you won’t be there on Thursday!

1. Export the domain-namespace from the old domain you are decommissioning.

DFSUTIL.EXE /root:\\<domain fqdn>\root> /export:<somefile.txt> /verbose

For the fabrikam.com example:

Note: If using Windows Server 2003 you will need the Support Tools. If a later OS, DFSUTIL is built in when you install the DFSN role.

2. Examine the export file and you will see that it lists out the entire configuration with all the server names, links, and targets. For example:

<?xml version="1.0"?>

<Root Name="\\FABRIKAM\public" State="1" Timeout="300" Attributes="64" >

       <Target Server="2003-03" Folder="public" State="2" />

       <Target Server="2003-04" Folder="public" State="2" />

 

       <Link Name="software" State="1" Timeout="1800" >

              <Target Server="2003-07" Folder="software" State="2" />

              <Target Server="2003-08" Folder="software" State="2" />

       </Link>

 

       <Link Name="shared" State="1" Timeout="1800" >

              <Target Server="2003-07" Folder="shared" State="2" />

              <Target Server="2003-08" Folder="shared" State="2" />

       </Link>

 

       <Link Name="procedural_docs" State="1" Timeout="1800" >

              <Target Server="2003-07" Folder="procedural_docs" State="2" />

              <Target Server="2003-08" Folder="procedural_docs" State="2" />

       </Link>

</Root>

3. Migrate all of your Link Target servers over to the new domain with ADMT, making sure to do security translation on all the files and shares. Consider using SID history as well. The Root Target servers are totally immaterial and do not need to be touched, unless you plan to use them as the hardware in step 5. If these Link Target servers were using FRS or DFSR to replicate in the past you will need to note this down and recreate that replication when all done with step 9. It’s beyond the scope of this article to go into details, but if you want more info let me know and I’ll cover it in another article.

4. Decommission the old domain. So in my example, Fabrikam.com no longer exists at this point. Make sure you take note of the old NetBIOS domain name before you zap it. Also make sure you remove the old trust and any previous name resolution done to make the trust work.

5. Using DCPROMO, recreate the old decommissioned domain as a new tree domain in the target forest. In my example, this would be Fabrikam.com as a new tree domain in the Contoso.com forest, like below:

 

6. Configure DNS conditional forwarders in the domains so that everyone can find your new domain tree and the new domain tree can find the domain containing all the link target file servers. In my example these are:

Note: If you have some other way you configure DNS that allows clients and link targets to work, that’s fine too; conditional forwarders are just my recommendation.

7. Add one more DC to that new tree domain. Now you have high availability and the basis for your two DFS root servers. No other servers are needed unless you want them. Make sure that the DFS Namespace role is installed on both servers if using Win2008 or later.

8. Using DFSMGMT.MSC, recreate your old root namespace. In my case it is named “Public”. Use your tree domain DC’s as the two namespace servers when configuring this root, so that you have high availability. Don’t recreate the links manually. You can use DFSUTIL.EXE /AddFtRoot to do this also.

9. Here’s the only step that requires you to pay attention to the export file:

A. If your servers listed in the export file only use NetBIOS names, import the TXT file back into the new tree domain by running DFSUTIL on one of the tree domain DCs.

B. If your servers listed in the export file use fully-qualified domain names, you must edit the TXT file to have them point to their new FQDNs. For example:

       <Link Name="software" State="1" Timeout="1800" >

              <Target Server="2003-07.contoso.com" Folder="software" State="2" />

              <Target Server="2003-08.contoso.com" Folder="software" State="2" />

       </Link>

You don’t have to change anything else because the root names, shares and links have not changed. So after step A or B, you run:

DFSUTIL.EXE /root:\\<domain fqdn>\root> /import:<somefile.txt> /set /verbose

For example:

Note: Don’t worry about the TXT file containing the old domain root server names (which may have changed). DFSUTIL ignores those root server targets during import. It only cares about the links and link target info. That’s why you had to pre-create the namespace in step 8.

You’re done! You can use DFSDIAG to check all your work now and make sure everything is hunky-dory. Since the data and file servers and shares never changed during this process, simply recreating the old domain name and importing the old configuration takes care of everything. The default DFS root share permissions are for EVERYONE READ so there are no groups or other permissions needed. As long as your users can find the recreated tree domain via DNS, they will never know anything happened.

Until next time.

- Ned “Dave’s sock puppet” Pyle

KB Articles

Greetings everyone. Warren here again with a blog post that is a collection of common DFSR issues that I have encountered over the past few years. The goal of this blog post is to list these common DFSR configuration mistakes that have caused problems to prevent you making the same mistake. Knowing what not to do is as important as knowing what to do. Many of these points are addressed in other content so links are provided for more in-depth reading.

• Too small of a Staging Area Quota

Are you seeing a lot of event ID’s 4202 and 4204? If so, your staging area is not sized correctly. The downside to an improperly sized staging area is that replication performance will be negatively affected as the service has to spend time cleaning up the staging area instead of replicating files.

DFSR servers are more efficient with a full staging area for at least these two reasons:

1. It is much more efficient to stage a file once and send it to all downstream partners than to stage a file, replicate the file, purge for each downstream partner.
2. If at least one member is running Enterprise Edition the servers can take advantage of Cross File RDC

An improperly sized staging area can also cause a replication “loop” to occur. This condition happens when a file get replicated to the downstream server and is present in the staging however the file is purges by the staging area cleanup process before the file can be installed into the Replicated Folder. The purged file will be replicated again to the server that just purged it from its staging as it never got to install the file. This process will keep repeating until the file gets installed.

Don’t ignore staging area events.

See this blog post for the method to use to determine your minimum staging area size

See the section “Increase Staging Quota” here

See “Remote Differential Compression details” here for information on Cross File RDC

• Improper or Untested Pre-seeding procedure

Pre-seeding is the act of copying the data that will be replicated to a new replica member before they are added to the Replicated Folder with the goal of reducing the amount of time it takes to complete initial replication. Most failed pre-seeding cases I have worked on failed in 3 ways.

1. ACL mismatch between source and target.
2. Changes were made to the files after they were copied to the new member
3. No testing was done to verify the pre-seeding process they were using worked as expected.

In short the files must be copied in a certain way, you cannot change the files after they are staged and you must test your process.

Click here to read Mr. Pyle’s blog on how to properly pre-seed your DFSR servers

• High backlogs for extended periods of time

Besides the fact that having high backlogs for extended periods of time means your data is out of sync, it can lead to unwanted conflict resolution where a file with older content wins in a conflict resolution scenario. The most common way I have seen this condition hit is when rolling out new RF’s . Instead of doing a phased rollout some admins will add 20 new RF’s from 20 different branch offices at once overloading their hub server. Stagger your rollouts so that initial replication is finished in a reasonable amount of time.

• DFSR used as a backup solution

Believe it or not some admins run DFSR without backing up the replicated content offline. DFSR was not designed as a backup solution. One of DFSR’s design goals is to be part of an enterprise backup strategy in that it gets your geographically distributed data to a centralized site for backup, restore and archival. Multiple members do offer protection from server failure; however, this does not protect you from accidental deletions. To be fully protected you must backup your data.

• One way Replication – Using it, or Fixing One way replication the wrong way

In an attempt to prevent unwanted updates from occurring on servers where they know the data will never be changed (or they don’t want changes made there) many customers have configured one-way replication by removing outbound connections from replica members. One-way replication is not supported on any version of DFSR until Windows Server 2008 R2. On Windows 2008 R2 one-way replication is supported provided you configure Read-Only replicated folders. Using Read –Only DFSR members allows you to accomplish the goal of one-way replication, which is preventing unwanted changes to replicated content. If you must use one-way replication with DFSR then you must use Windows 2008 R2 and mark the members as read-only where changes to content should not occur.

Click here and here to learn about Read-Only DFSR replicas.

Another common problem that occurs is when an Admin discovers that one way replication is not supported they go about fixing it the wrong way. Simply enabling two-way replication again can have undesirable results. See the blog post below on how to recover from one-way replication.

Click here to learn about fixing one-way replication.

• Hub Server - Single Point of Failure or Overworked Hub Servers

I have seen many deployments with just one hub server. When that hub server fails the entire deployment is at risk. If you’re using Windows Server 2003 or 2008 you should have at least 2 hub servers so that if one fails the other can handle the load while the other is repaired with little to no impact to the end users. Starting with Windows Server 2008 R2 you can deploy DFSR on a Windows Failover Cluster which gives you high availability with half of the storage requirement.

Other times admins will have too many branch office servers replicating with a single hub server. This can lead to delays in replication. Knowing how many branch office servers a single hub server can service is a matter of monitoring your backlogs. There is no magic formula as each environment is unique and there are many variables.

Read the “Topology Tuning” section here for ideas on deploying hub servers.

Click here to learn how to setup DFSR a Windows Server 2008 Fail-Over Cluster.

• Too many Replicated Folders in a single Jet Database

DFSR maintain one Jet database per volume. As a result placing all of your RFs on the same volume puts them all in the same Jet Database. If that Jet database has a problem that requires repair or recovery of the database all of the RF’s on that drive are affected. It is better to spread the RFs out using as many drives as possible to provide maximum uptime for the data.

• Bargain Basement iSCSI deployments

I have seen more than one DFSR iSCSI deployment where the cheapest hardware available was used. Usually if you are using DFSR it is for some mission critical purpose such as data redundancy, backup consolidation, pushing out applications and OS upgrades on a schedule. Depending on low-end hardware with little to no vendor support is not a good plan. If the data is important to your business then the hardware that runs the OS and replication engine is important to your business.

• Did not maintain the DFSR service at the current patch level

DFSR is actively maintained by Microsoft and has updates released for it as needed. You should update DFSR when a new release is available during your normal patch cycle. Make sure your servers are up to date per the KB articles listed below.

Windows 2003 R2 DFSR Hotfixes

Windows 2008 and Windows 2008 R2 DFSR Hotfixes

You will notice that updates are listed for NTFS.SYS and other files besides DFSR.EXE/DFSRS.EXE. For replication always make sure DFSR and NTFS are at least at the highest version listed. The other patches listed mostly deal with UI issues that you will at minimum want installed on the systems you perform DFSR configuration tasks on.

Proactively patching the DFSR servers is advisable even if everything is running normally as it will prevent you from getting effected by a known issue.

• Did not maintain NIC Drivers

DFSR will only work as well as the network you provide for it. Running drivers that are 5 years old is not smart. Yes, I have talked with more than a few customers with NIC drivers that old who’s DFSR replication issue was resolved by updating the NIC driver.

• Did not monitor DFSR

Despite the fact that the data DFSR is moving around is usually mission critical many Admins have no idea what DFSR is doing until they discover a problem. Savvy admins have created their own backlog scripts to monitor their servers but a lot of customers just “hoped for the best”. The DFSR Management Pack has been out for almost a year now (and other versions for much longer). Deploy it and use it so you can detect problems and respond before they become a nightmare. If you can’t use the DFSR Ops Management pack at a minimum write a script to track your backlogs on a daily basis so that you know that DFSR is replicating files or not.

Click here for information on the Ops Manager DFSR Management Pack.

Updated Jan 19, 2011:

• Making changes to disk storage without first backing up the data
  
  If you must replace or add hard drive space to your DFSR server it is critical that you have a current backup of the data in case something goes wrong. Any number if things can go wrong the most common being conflict event s created due to accidental changes to a parent folder or unintentional deletion of a parent folder that is replicated to all partners. You must backup your data before starting the changes and maintain the backup until the project is completed. 
   
• Stopping the DFSR service to temporarily prevent replication
  
  Sometimes there is a need to temporarily stop replication. The proper way to accomplish this is to set the schedule to no replication for the Replication Group in question. The DFSR service must be running to be able to read updates to the USN Journal. Do not stop the DFSR service for long periods of time (days, weeks) as doing so may cause a journal wrap to occur (if many files are modified, added, or deleted in the meantime). DFSR will recover from the journal wrap but in large deployments this will take a long time and replication will not occur or will happen very slowly during the journal wrap recovery. You may also see very high backlogs until the journal wrap recovery completes.

I hope this list has been a help to you. Happy replicating.

Warren “wide net” Williams