I have a scenario where the replication for the DR is getting failed.
We have around 24 repositories which are getting failed. Since we already know that we are running with EOL products like ePO 5.3.2 and MA 5.0.5, we are planning to upgrade the ePO, but at least we would like to get an immediate assistance to resolve the issue. If you could assist here, that would be of great help.
Logs for your reference.
Failed to upload file catalog.z to site rocsvw1001.roc.ABCDEFG.net:8081, error code 5 ( Access is denied. ), will retry
Failed to upload file Current\VSCANDAT1000\DAT\0000\Replica.log to site jiasvw1027.JIA.ABCDEFG.NET:8081, error code 5 ( Access is denied. ), will retry
Failed to upload file Current\AMCORDAT2000\DAT\0000\content-00010006-003581-dat.zip to site gotsvw1003.got.ABCDEFG.net:8081, error code 10054 ( An existing connection was forcibly closed by the remote host. ), will retry
Using lazy caching will allow them to just stop trying to replicate to these altogether. when a client requests repository data, the SA repo will just grab what it needs when the client requests it.
There are few advantages of using Lazy Caching: . a) It will reduces the bandwidth. b) The files are pulled on the needed basis. .c) it helps ensure that the sites are always up to date sites.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?please select Accept as Solution in my reply and together we can help other members?
The access denied usually indicates a problem with that agent on the sadr. This it typically the easiest way to fix those.
1. Set policy so agent is no longer a superagent repository.
2. delete the directory that is specified in the ma policy that is for the repository files, including the root of that directory.
3. Check masvc log on client for any agent-server communication issues. If the agent has a lot of errors, reinstall the agent to get it functional again. If everything looks fine, then go to step 4.
4. Apply the superagent policy again to that system, but make sure to not pre-create any of the folders that is specified in the policy for the repository location. The superagent conversion process needs to create those automatically - otherwise you get failures like what you are seeing.
5. If using replication, make sure lazy caching is disabled. If using lazy caching, do not replicate. Use one or the other.
Was my reply helpful? If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?