Home | Site Map | Cisco How ToNet How To | Wireless |Search | Forums | Services | Donations | Careers | About Us | Contact Us|

Event ID: 4202 and 4304

Active Directory, Domain, DNS, WINS, DHCP, SBS, New Releases.

Event ID: 4202 and 4304

Postby chicagotech » Sat Aug 12, 2017 9:50 am

Situation: The client has Windows 2016 running DFS. The Event logs show these warning:
Log Name: DFS Replication
Source: DFSR
Date: 8/11/2017 10:00:02 PM
Event ID: 4304
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: DC
Description:
The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. The service failed to stage a file for replication due to a sharing violation.

Additional Information:
File Path: D:\DFS\NetBackups\E-QB\2017-08-11_22-00-01\BKS PROPERTIES LLC (Backup Feb 19,2014 03 40 PM).QBB
Replicated Folder Root: D:\DFS\NetBackups
File ID: {558A329C-2AA0-40FB-8210-9FDA04CA6756}-v1067038
Replicated Folder Name: NetBackups
Replicated Folder ID: C4AB7CC7-BF67-408E-8739-E4913BE34931
Replication Group Name: NetBackup
Replication Group ID: 187FEF02-B206-4CD4-8EAD-CB1D876AD121
Member ID: F7052710-D28F-4605-B27F-D548A56AA3D9

Log Name: DFS Replication
Source: DFSR
Date: 8/11/2017 10:12:57 PM
Event ID: 4202
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: DC
Description:
The DFS Replication service has detected that the staging space in use for the replicated folder at local path D:\DFS\NetBackups is above the high watermark. The service will attempt to delete the oldest staging files. Performance may be affected.

Additional Information:
Staging Folder: D:\DFS\NetBackups\DfsrPrivate\Staging\ContentSet{C4AB7CC7-BF67-408E-8739-E4913BE34931}-{F7052710-D28F-4605-B27F-D548A56AA3D9}
Configured Size: 4096 MB
Space in Use: 3702 MB
High Watermark: 90%

Low Watermark: 60%

Replicated Folder Name: NetBackups
Replicated Folder ID: C4AB7CC7-BF67-408E-8739-E4913BE34931
Replication Group Name: NetBackup
Replication Group ID: 187FEF02-B206-4CD4-8EAD-CB1D876AD121
Member ID: F7052710-D28F-4605-B27F-D548A56AA3D9
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
chicagotech
Site Admin
 
Posts: 6920
Joined: Mon Nov 27, 2006 1:24 pm
Location: Chicago USA

Re: Event ID: 4202 and 4304

Postby chicagotech » Sat Aug 12, 2017 9:51 am

Possible causes:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.


11. 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.

12. Incompatible Anti-Virus software or other file system filter drivers

It’s a problem that goes back to FRS and Windows 2000 in 1999 – some anti-virus applications were simply not written with the concept of file replication in mind. If an AV product uses its own alternate data streams to store ‘this file is scanned and safe’ information, for example, it can cause that file to replicate out even though to an end-user it is completely unchanged. AV software may also quarantine or reanimate files so that older versions reappear and replicate out. Older open-file Backup solutions that don’t use VSS-compliant methods also have filter drivers that can cause this. When you have a few hundred thousand files doing this, replication can definitely slow down!

You can use Auditing to see if the originating change is coming from the SYSTEM account and not an end user. Be careful here – auditing can be expensive for performance. Also make sure that you are looking at the original change, not the downstream replication change result (which will always come from SYSTEM, since that’s the account running the DFSR service).

There are only a couple things you can do about this if you find that your AV/Backup software filter drivers are at fault:
•Don’t scan your Replicated Folders (not a recommended option except for troubleshooting your slow performance).
•Take a hard line with your vendor about getting this fixed for that particular version. They have often done so in the past, but issues can creep back in over time and newer versions.

13. Bandwidth Throttling or Schedule windows are too aggressive

If your replication schedule on the Replication Group or the Connections is set to not replicate from 9-5, you can bet replication will appear slow! If you’ve artificially throttled the bandwidth to 16Kbps on a T3 line things will get pokey. You would be surprised at the number of cases we’ve gotten here where one administrator called about slow replication and it turned out that one of his colleagues had made this change and not told him. You can view and adjust these in DFSMGMT.MSC.

14. Configuring multiple DFSN folder targets on a replicated folder hosting user profiles data

Ned’s details found here have become the standard for why Microsoft does not recommend or support using Distributed File System Replication (DFSR) and DFSN (multiple folder targets) for user profile data. For example: if a user were to be referred to a file server that hasn’t yet replicated in recently changed data (or perhaps you don’t have replication enabled on the shared folder), then the user will not have access to their expected data. The user will logon and receive an old version of their user profile. At best, this generates helpdesk calls–at worst, a user may unknowingly utilize outdated files and lose data.

Do not use DFSN paths with multiple folder targets to store user profiles or volatile user data. Whenever implementing DFSN, you must be vigilant to ensure users and clients are never affected by referrals to alternate file servers where expected data may not reside
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
chicagotech
Site Admin
 
Posts: 6920
Joined: Mon Nov 27, 2006 1:24 pm
Location: Chicago USA


Return to Windows

Your Ad Here

Who is online

Users browsing this forum: Majestic-12 [Bot] and 3 guests