Before posting, and to avoid disappointment, please read the following:

  • This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.
  • If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.

Possible solution to silent fail on scheduled profile

SyncBackFree is the freeware version of SyncBack. It is *not* an evaluation version of SyncBackPro/SE.
Post Reply
Posts: 1
Joined: Thu Nov 17, 2016 10:08 pm

Possible solution to silent fail on scheduled profile

Post by jeverett »

I recently installed SyncBackFree on my Windows 10 (64-bit) desktop. When I tried to setup and test a schedule for a synchronize profile, nothing happened. I found several 10016 events in my event log that were associated with the DCOM object request broker. A bit of Googling turned up the following site: ... 160-and-a/

Quoting from the start of the article: "Windows 10 Event 10016 Fix: The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} and APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276} to the user NT AUTHORITY\LOCAL SERVICE SID (S-1-5-19) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool."

The rest of the article provides a straightforward repair procedure. Apparently something goes awry in the Windows installation, such that the request broker ends up owned by the TrustedInstaller, rather than the Administrators group, and this results in permission problems when running a schedule. The fix is to change the ownership to Administrators, then use the DCOM configuration tool to add SYSTEM to the owners of the request broker.

The SyncBack profile ran on schedule after doing this.

One caveat: I have a Mac Mini with bootcamp dual-booting into Windows 10, and I found the same problem, with TrustedInstaller owning the request broker. However, prior to making the changes recommended in the article, I created a profile, and tested a schedule, which appeared to work. Aside from the hardware differences (I assembled my desktop from parts (e.g., gigabyte motherboard)) the only thing I can think of that's different between the two is that the desktop is running Windows 10 AU (build 14393), whereas the Mac is still running Windows 10 build 10586 (it keeps failing on the AU update).

Post Reply