«Windows Backup encountered an error when accessing the remote shared folder» Error Code 2155348315

I know for a fact that the server isn’t going offline, I tried staying logged on the server via Remote Desktop while the backup ran and it never booted me. All the machines are on full Gigabit switch (via a Dlink DIR-825 router).
I’ve been able to run backups to that WHS from all my other Windows 7 machines (2 laptops and 1 Media Center system) w/o issues.

Also ran check disk on the drives, hardware is fine (Core i7 920 with 6GB of DDR on an Asus x58 board, ATI Radeon 4870 card, WD 300GB Raptor and 1.5TB Seagate drive).

· Have you mapped network drive on the computer?

If you have mapped network drive then try disabling it and then run the back as it seems that backup is failing when trying to access a remotely shared file/folder.

Also place the computer in a clean boot state and try backing up the computer.

1. Click Start, type msconfig.exe in the Start Search box, and then press ENTER to start the System Configuration Utility.

2. If you are prompted for an administrator password or for confirmation, type your password, or click Continue.

3. On the General tab, click Selective Startup, and then click to clear the Load startup items check box. (The Use Original Boot.ini check box is unavailable.)

4. On the Services tab, click to select the Hide all Microsoft services check box, and then click Disable all.

5. Click OK, and then click Restart.

Now, follow the below mentioned Knowledge Base Article and perform the mentioned steps to determine the cause.
Refer: http://support.microsoft.com/kb/929135

Note : Make sure you put the computer back to Normal Startup once troubleshooting is completed.

You may also post your query here:

Windows backup encountered error accessing remote shared folder

This forum is closed. Thank you for your contributions.

Asked by:

General discussion

I’m running into this error with around 50% of my 65 servers during a system state/bare metal backup. The volumes back up fine. The error happens roughly 10 minutes into a system state/BMB:

Error code ‘0x8078015B’ (Windows Backup encountered an error when accessing the remote shared folder. Please retry the operation after making sure that the remote shared folder is available and accessible.)

I’m also running into the semaphore timeout errors too, it’s probably related.

We are running DPM 2016 UR4 with SQL 2016 SP1 on Windows Server 2016. It has a 52TB RAID60 data drive formatted with ReFS. We run all backups to the disk, no tape.

I have the recovery points for the protection groups spread out during the day to reduce load on the server. The groups are set to sync every hour, with a 10 minute offset between them.

We are backing up Server 2008/2012/2016, and I noticed that no 2008 servers are having errors.

I’m simply at a loss at this point, I’ve tried every solution I could find on technet and google. I’ve tried everything from both this error and the semaphore error.

Has anyone else ran into this issue and resolved it? On a side note, I set up an almost identical server for one of our clients, and they have no issues with their DPM server. But they are also backing up maybe 30 servers.

All replies

Run into it, but not resolved or escalated it. Looks like a bug with DPM 2016 UR and BMR backups.

We only took a BMR backup from one physical domain controller, i have removed this protection for now. We have backups from other domain controllers (VMs — Hyper-V) so i can do without BMR for this server.

I have had this problem since I switched to DPM 2016 at the UR1 release. I have also spent much money on this issue, not only in my personal time, but in premier support case hours to get this solved (I had a premier support case open virtually a year on this). I have had NO success from Microsoft on this problem. They keep saying they have not seen this problem. I firmly believe Microsoft believes there is no problem here. I guess we are just imagining this issue.

I found for me it got much better once I changed my DPM server from a VM with VHDX files for the data storage to a physical server with direct access to the volumes. I did this on my own, not at Microsoft’s suggestion. However, over the last few weeks with UR4, it has seemed to start becoming a problem again. Not as bad as before when I NEVER could get a BMR to work for any server. Today I have to manually restart the BMR backups for some systems each day, and usually after several attempts I can get it to work. To me this is still a major problem with DPM 2016 even at UR4.

I would like DPM to be a system that I do not have to worry about on a daily basis. Unfortunately, that is not the case any longer.

This was not a problem in DPM 2012 R2 (or earlier versions).

After fighting with this issue for the last few weeks, it would seem that a simple setting improves the situation quite significantly. It was suggested on one of the other threads that the issue is related to ReFS and some of the recent windows patches included tunable parameters.

Changing the timeout value (option 4) from 60s to 180s has resolved the issue on our server. Remember to reboot the DPM server after changing the value.

Did you do anything else? That is not working for me. I assume you set this on the DPM server, not the protected system? Did you make any of the other indicated changes or anything is this document:

This is also happening to us on our primary server — all of a sudden numerous (not all) system state jobs fails. The secondary server as of right now is fine.

It complains about numerous things: the remote share is inaccessible — not enough space for the replica — both of which are false. So I suspect too like others here that it is a bug ultimately triggered by something for this to happen and for certain VMs.

The secondary is a whole different concept. It doesn’t use Windows Server Backup. Too much silence from Microsoft on this issue in my opinion.

No, I had a look at the rest of the settings from that link but none looked like they would make a difference. The only setting that I changed was the timeout. In saying that, I did add another 64Gb of ram to that server but it doesn’t seem to matter at its memory usage has remained roughly the same (and the memory was added prior to changing the timeout value and didn’t seem to make a difference)

I have a solution that sometimes works.

So this is something to try. It seemingly has nothing to do with the
error, but try it and bear with me.On the protected server right click
the C:\ drive and select configure shadow copies. You’ll notice you have
a funky volume (recovery volume) that looks like this:

Select
it and then hit the settings button. Use the schedule button to set the
schedule you want. But the important part is to set which drive it
stores the shadow copies on. I set it to c:

Set a size limit you want but give yourself breathing room. The
backup process needs to image the partition and then copy it to the DPM
server. So I would recommend allocating at least 100% of the total
partition size. It’s small so this shouldn’t be a problem.

Once you do that manually create a shadow copy.

Then retry the BMR backup job and see if it completes successfully. Rinse and repeat on the other servers giving you grief.

I am having this issue and just found the UR6. A few things caught my eye.

• Data Protection Manager System State and Bare Metal Recovery (BMR) fails intermittently for multiple servers.
• Indefinite looping occurs for consistency check jobs for Resilient Change Tracking (RCT) on a virtual machine (VM) because of I/O errors.

Installing now. Hopefully this fixes the issues.

Did UR6 seem to help?

A bit earlier for me to really know. however the UR6 wasn’t a magic fix. I was still having issues until i Deleted and re-created the protection of the servers, since i have done that i have not had issues.

We also see the same issue. Haven`t tried upgrading to UR6 yet, but the workaround in this thread seems to work.

Temporarily disable WinRE when taking a system image backup

Blog: http://www.powershell.no
Twitter: http://twitter.com/janegilring

• Edited by Jan Egil Ring MVP Wednesday, December 19, 2018 8:18 AM

this action did not help 🙁

What i did and worked for one server (got 3 more to try).

1. Did a local backup from command prompt:

wbadmin.exe start backup -allcritical -backuptarget:e:\

2. Created a share on the dpm disk and did a backup to the disk where all the dpm backups are stored (initially it failed and the second try it worked)

wbadmin.exe start backup -allcritical -backuptarget:\\server\share

3. Followed Jan’s advice and disabled WinRE (from Command Prompt (Admin)):

Please tell me if that worked for you

Same problem here. DPM 2016 RU6.

Server backuped: windows 2016

BMR fails intermittenly.

We have recently upgraded much of our Windows estate to Windows Server 2016 and as part of this work we also upgraded our DPM Server to DPM 2016 1801. Since doing so, the BMR/System State backups for Windows 2016 servers frequently fail. The BMR backups on our Windows 2008R2 servers continued to work without any problems. Looking through the backup/event logs we see the following logged when the backups fail:

0x8078015B Windows Backup encountered an error when accessing the remote shared folder
0x80070079 The semaphore timeout period has expired

I spent quite some time trying to find a solution to this problem, initially without a great deal of success. If I removed the server from the protection group in DPM, cleared the backup history, and then re-added the server, I would find that the BMR backups worked once or twice before failing consistently once again. If I ran Windows backup on the protected computer, backing up the BMR to local disk it would also work fine. The same BMR backup to a share on the DPM server also worked consistently. Further digging revealed that the DPM server presents a share to the protected computer for the duration of the backup. Testing revealed that the share was removed from the DPM server before the BMR backup completes, resulting in the backup failing. I attempted various configuration changes to try and resolve the problem, but none of these worked. For completeness, here is what I tried unsuccessfully:

1. Creating/modifying the following registry keys on both the DPM server and the protected server
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\SPP\CreateTimeout and set decimal value to 3600000. To increase VSS timeout.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\Settings\IdleTimeout and set decimal value to 3600000. To increase VSS timeout.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue and changed decimal value from 60 to 180.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxDataRetransmissions with a decimal value of 5.
2. Running “wbadmin delete catalog” on the protected server to clear the backup catalog.
3. Checking for shadow copies and removing them on the protected server using the command “vssadmin list shadows”.
4. Increasing the paging file to 16Gb from 2Gb on the DPM server.
5. Attempting to throttle the bandwidth using the bandwidth throttling in DPM.
6. Modifying the disk allocation to 100Gb for the backup within DPM.
7. Running chkdsk /f on the protected server.
8. Modifying the maximum size of storage allocated to volumes for shadow copies to have no limit at all.

As I said, none of the above helped at all. What has finally led to us being consistently able to run BMR backups reliably on Windows 2016 servers was throttling the bandwidth between the protected server and the DPM server using a QoS profile on the protected server itself. I’ve read somewhere that the throttling built into DPM does not apply to BMR backups. I’m not sure whether that’s true, but trying that did not help us at all. It’s very simple to create a QoS profile in Windows 2016, and it’s not necessary to install any additional software, roles or features. To do so, simply carry out the following steps:

1. Start “Local Group Policy Editor” by typing gpedit.msc on the protected computer.
2. Browse to Local Computer Policy > Computer Configuration > Windows Settings > Policy-based QoS.
3. Right click and select “Create New Policy”.
4. Provide a name for the policy, uncheck “Specify DSCP Value” and set an outbound throttle rate (I used 100MBps successfully).
5. Select “All applications” (though if your backup server provides other functions you may wish to restrict this just to the Windows Backup application.
6. Select “Any source IP address” and enter the IP address of the backup server in the destination field.
7. Select both the TCP and UDP protocols, and any source/destination port.
8. The policy takes immediate effect without a requirement to reboot.

Since applying this policy our BMR backups on Windows 2016 have worked reliably and consistently. Hopefully this is of help to others as well, as this can be quite a frustrating problem!

Simon Edwins
Senior IT Security Specialist
Rothamsted Research