Intermittent failure syncing two folders with BC4 using a Windows Scheduled Task

[cainemarko]

I have a nightly scheduled task to run a simple sync. I am using BC4 and running on Windows 2012 R2.

General:
Run whether user is logged on or not
Run with highest privileges
Configure for: Windows Server 2012 R2

Triggers:
Daily 9:00pm
Enabled

Action:
Start a program
Program/script "C:\Program Files\Beyond Compare 4\BCompare.exe"
Add Argurments @script.txt /silent
Start in C:\

Conditions:
Start the task only if the computer is on AC power
Stop if the computer switches to battery power

Settings:
Allow task to be run on demand
Stop the task if it runs longer than 3 days

Since upgrading these servers from 2008 SP2 or 2008 R2 to 2012 R2 we have had intermittent failure on the Scheduled Task. It fails to run and Last Run Result is showing 0x6b. I can run them manually with no issue. Right clicking and hitting run works every time. It only does this if we use the Scheduled time in the Triggers tab.

The two remaining 2008 SP2 servers, running BC3 are running like clockwork with no issues. The hit and miss is only happening in 2012 R2.

[Aaron]

Hello,

/silent makes it difficult to troubleshoot since it wouldn't show any dialogs, feedback, errors, etc. If you add a log c:\logs\bclog.txt to your script, are there any clues where it fails? I assume it is not running for 3 days and then ending due to the Task, correct?
Or if you run the task while logged in and remove the /silent, are you able to watch and review the Script Window log?

Are the upgraded machines using the original install and settings? Or did you do a fresh install and then bring over the settings or script?
Scripting uses the factory default settings unless set to load <default> or load a specific session; are there any potential differences in the scripting?

[cainemarko]

Aaron,
Thanks for getting back so quickly.

I have not added the Log C:\logs... to my script. I will give it a try.

The 3 days was just there by default. I need to change it. We run these nightly. Or they're supposed to anyway.

I will remove the /silent and run it manually as well.

They were the original install and settings until yesterday. I purchased and upgraded to BC4 and I imported the old settings from BC3.

I will give your suggestions a try and get back to you.

[cainemarko]

Aaron,

I didn't add the c:\logs\bclog.txt to the script, but I did run the script in the command prompt without the /silent.
"C:\Program Files\Beyond Compare 4\BCompare.exe" @C:\bc_script.txt

This produced a distinct error. It said that the user did not have permission to access the file. Even though the user I have in the task is an Administrator and in the Administrators group. It seems that Windows 2012 R2 is very touchy about giving permission to things in the root of C: or perhaps I just have the inheritances setup incorrectly.

Even though the user was in the Admin group, I went ahead and added it to the root of C:, in the Group and User names under the Security tab by itself, outside of the Admin group. So for the C: drive itself I now have the Administrators group, the Users group and now my single admin user. I ran the above script again and it worked perfectly. It has been working fine ever since.

btw, I did have one other hiccup that may be useful for someone. It would seem that even adding the user, which solved the problem, is not the only step. It appears that I need to leave the session running. If I actually sign out of that user the task fails even with the above change made.

Ultimately, none of this seems to be anything to do with your software. (woot!) But hopefully it will be helpful for other Windows Users.

Thanks.

[Aaron]

Hello,

Another factor is, being an Administrator user does not mean the program (BC4) executes with the "Run As Administrator" compatibility option. You may need to enable this to elevate BC4 during the run, or (as you found) move or edit permissions so BC4 does not need to be Run As Administrator to have access.

[Aaron]

As for needing to leave the session running, BC4 supports running as a logged in user or as a process, but I suspect the target security is disallowing the run as a process. The log might help show an error message that is otherwise suppressed if you aren't logged in to see it. Using a Portable Install might also help, as this would allow any user (graphical or scripted) to share the same settings in a global location, such as C:\Tools\Beyond Compare 4\, which they all have read/write access to.

[cainemarko]

Aaron,
Thanks for the extra responses. I was still testing. We were successful with the user always logged in, but of course our weekly windows updates reboot and log the user out. So the backups didnt run Sunday evening after the Sunday morning reboots.

I tried the Run as Administrator setup. But I only tried it from the shortcut, not the .exe istelf.

However I did notice that when I added the admin user to the root of C: and gave it full permissions, Windows 2012 R2 still doesnt give me rights to several folders. Program Files and Program Files x86 among them. I think this is the issue. So I am running a test tonight with one machine with the Portable install. I used your suggestion and its installed now with the same Admin User but in a newly created Tools folder, not Program Files.

I will let you know if this resolves it.

Thanks again.


David

[cainemarko]

Aaron,
So I have done all the testing I can think of. I did the portable install and ran all of the following tests.

I have run the command from the command prompt “C:\Tool\Beyond Compare 4\BCompare.exe” @C:\bc_script.txt and it runs fine.
I have that same basic setup in the Task Scheduler in the Actions Tab. I have taken out the /silent. If I right click and run this task manually, it works fine.
If I set up the time and let task manager run this at a scheduled time, it runs fine.
The second I log out of the admin account, it stops working. I have run the last test above and it works. I adjust the time by 5 minutes and log out. It fails.
We are creating a Sync log for errors and this is what I am getting.

6/28/2016 3:43:01 PM >> load "fc backup (foldername)"
6/28/2016 3:43:01 PM Load comparison: <->
6/28/2016 3:43:01 PM Fatal Scripting Error: Unable to load base folder
6/28/2016 3:43:01 PM Script completed in 0.12 seconds

The MOST frustrating thing is that this all appears to be random. I did the bulk of these tests last week and then ran all 9 machines Friday night, on the 9pm schedule, admin account logged OUT and they all ran successfully. Saturday night only 2 of them ran. Sunday night the same 2 ran. Monday I left the admin account logged into all 9 and they all ran.

The admin account has full permission of the C: drive. I checked the Tools folder that I created with the Portable install, it is inheriting properly.
The two machines that continued to run have their UAC at default levels. I seemed to have some success with getting the others to run when I turned this off, but that doesn’t explain why the 2 that work are running with it on.
I checked the Task Scheduler in Services, no issues there.
I have tried to match the ones that don’t work to the ones that do in every way I can think of with no luck.
Any suggestions at this point would be much appreciated.

[Chris]

If you're loading a network drive, scheduled tasks might not have access to drive mappings. Instead of using a network drive letter like Z:, it might work better to use UNC paths like \\server\share\folder.

If you're loading a saved session in the script, it might also help to try loading paths without using a saved session.

Replace: load "saved session name"
With: load c:\folder\ \\server\share\folder

[cainemarko]

Chris,
No Network drives involved. Just a folder on the C: drive running a compare and saving changes to another sub-folder on the same C: drive. That sub-folder then gets backed up.

This is how the script is setup;

log verbose "C:\Synclog.txt"
option confirm:yes-to-all

load "fc backup (foldername)"
sync create-empty update:left->right

In Beyond Compare itself fc backup (foldername) is in the Shared Sessions tree

On the specs tab it says:

Left Folder:
c:\(foldername)

Right Folder:
C;\app_bak\(foldername)

That's all its doing. Nothing complex. But I am getting "unable to load base folder" in the error log.

And again, as I mentioned above, this is only happening on 6 of the 9 machines I am running it on. The 3 that are successful are running the exact same configuration, down to the folder permissions. I have literally spent days comparing all of these systems. I can not find any differences.

If possible, I will gladly open a ticket and pay for a support call. We can set up a remote session so that you can see for yourselves. I need some resolution to this issue.

[Aaron]

Hello,

We just got off the phone. For users running into this thread, the solution needed was to verify that BCState.xml and BC4Key.txt both existed in the Portable Install's directory (C:\Tools\Beyond Compare 4\). Once both these files were in place, the Portable was configured and the automated task began to run smoothly.

[cainemarko]

Guys,
Ok, so the problem is corrected!

I spoke to Aaron and after we went over everything, it turns out that the portable install, while the ultimate solution, was partly the issue. It had installed the BCState.xml (among others) into the AppData\Roaming folder for the specific user that I was logged in at the time of the install. So it was tied to that user. Hence it working just fine when I was logged in as that user, but not when I logged out.

Once I copied the files over to the C:\Tools\Beyond Compare 4\ folder that I created for the portable install it worked like a champ.

I have not been logged into the servers since my discussion, and they have run flawlessly each night.

Thanks again for all of the help.

[Aaron]

A slight clarification. The Portable Install setup.exe process does not create the BCState.xml in AppData, but in the main install directory. However, if BCState.xml is removed or renamed from the Install directory, this reverts the install to a Normal Install, which will then auto-generate settings files into AppData the next time BCompare.exe is run. The presence of "BCState.xml" within the install directory determines, as Bcompare.exe is run, if it should be a Portable Install or Normal Install. The Setup.exe allows the user to choose which install type then need.

If creating a Portable Install, always pick a directory which has read/write access. With Windows Vista/7/8/10, Program Files\ is locked down with extra security and is not an appropriate location for a portable install. It would need to be elsewhere (such as a new folder created in C:\Tools\).