Unable to access shared folder in scheduled task

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • myriaxis
    Journeyman
    • Mar 2016
    • 12

    Unable to access shared folder in scheduled task

    Hi,
    I have a backup PC where files from different sources are copied every night using BC4 scripts running as scheduled tasks.
    In one particular case, the backup PC cannot access a shared folder on a target PC.
    The backup PC is a domain joined Windows 8.1 logged with a domain user.
    The target PC is a workgroup Windows 10 logged with a local user.
    On the backup PC, I added persistent Windows Credentials for the target PC.

    When I'm logged in the backup PC with the domain user, I can access the shared folder on the target PC.
    If I open the compare session in BC4, it works.
    If I run the BC4 script manually, it works.
    If I run the BC4 script as a manual scheduled task, it works.
    But if the backup PC reboots, the BC4 script fails when it runs as a automatic scheduled task.
    The error is "Unable to load base folder".

    To diagnose the problem, I made the backup PC to automatically log in with the domain user after a reboot.
    Still, the BC4 script always fails when run as a scheduled task, until I access the shared folder via a BC4 GUI session.
    It seems that the Windows Credentials for the target PC are not taken into consideration until I unlock the shared folder.

    One way to fix this would be to join the target PC to the domain, but that would be a last resort option.
    Any other ideas on how to fix this?

    Thanks
  • Aaron
    Team Scooter
    • Oct 2007
    • 16000

    #2
    Hello,

    Sometimes we see a couple issues like this where things look like they are configured correctly but still aren't accessible. The first tip I can offer is if you are accessing as a bound drive letter (X:\) try switching to the network shared path (\\computername\folder\).

    It doesn't sound like this is happening, but just in case: from BC4's perspective, if the automated task is set to run as a specific Windows User, then we should have access to that user's settings, but sometimes find environments where this isn't the case. The easiest workaround is to set up a global Portable Install that shares settings with any User, and use this for automation if this is happening. Run the setup.exe and create a Portable Install in a location where all users would have read/write access (not Program files, but someplace like C:\Tools\Beyond Compare 4\). You can run the original install, and use the Tools menu -> Export to export your settings, then run the new Portable install and Tools -> Import to bring them in.
    Aaron P Scooter Software

    Comment

    • myriaxis
      Journeyman
      • Mar 2016
      • 12

      #3
      Thanks Aaron,

      Just to clarify my setup.
      I'm using network shares (\\Target PC\shared folder).
      The Backup PC has a domain user, say A.
      The Target PC has a local user, say B.
      The BC4 program was installed on the Backup PC using the domain user A.
      The scheduled task calls the BC4 program to run the compare script on the Backup PC and is set to run using the domain user A credentials.
      To access the shared folder on the Target PC, I added a persistent entry for the target PC in the Windows Credentials, under Control Panel/User Accounts/Credential Manager, to use the local user B credentials when accessing the shared folder.
      With this Windows Credentials entry, I can access the Target PC shared folder in Windows Explorer or BC4 GUI without reentering the local user B credentials.

      The Backup PC normally runs by itself.
      I remotely connect to this PC only when required (mainly for windows updates and log cleanup).
      The problem occurs after a reboot.
      The BC4 script runs automatically via the scheduled task and fails until I remotely connect to the Backup PC and open the BC4 session, normally called by the script, in the BC4 GUI.

      You think a Portable install will fix this issue?
      OK, I'll give it a try.

      Comment

      • myriaxis
        Journeyman
        • Mar 2016
        • 12

        #4
        Hi Aaron,

        With a Portable install, it improves a little bit, but doesn't fix it.
        After a reboot, the script fails when executed via a scheduled task launched automatically.
        However, the same script runs fine when executed via the same scheduled task launched manually.

        Any ideas?

        Comment

        • Aaron
          Team Scooter
          • Oct 2007
          • 16000

          #5
          Hello,

          Does this present a new error message? Or still failing to load the base folder?

          So when running as an automation from TargetComputer as Domain User A, Domain User A is having trouble accessing the Backup/A machine remotely from TargetComputer. Is this connection established by a login script? It's possible you will need to disable the task's ability to Run As A Service (run without logging in as User A), in order for the other login actions to occur.
          Aaron P Scooter Software

          Comment

          • myriaxis
            Journeyman
            • Mar 2016
            • 12

            #6
            Hello,
            I'm getting the same error "Unable to load base folder".

            The BC4 automation is not running on the Target PC. It runs on the Backup PC.
            I'm sorry. I guess my previous explanations were confusing.

            The Backup PC runs the BC4 script that sync the content of the Target PC shared folder with it's replica on the Backup PC.
            The Backup PC is a domain joined PC and the BC4 script is executed with Domain User A credentials.
            The Target PC is not a domain joined PC and it has only one local user B.
            User B is not a domain user.
            To access the Target PC shared folder from the Backup PC, I created a Windows Credentials entry in the Backup PC Credential Manager for the Target PC. This allows the Domain User A on the Backup PC to use the Local User B credentials to access the files in the Target PC shared folder.
            This setup works great when using BC4 GUI, but doesn't work when using BC4 script called by a scheduled task.
            I narrowed down the problem to running the script after a reboot and before I use BC4 GUI.
            It sounds like BC4 command-line doesn't use the Local User B credentials stored in Credentials Manager as BC4 GUI does.

            Do I make sense?

            Comment

            • Aaron
              Team Scooter
              • Oct 2007
              • 16000

              #7
              Hello,

              If you place your script call into a .bat file (instead of directly calling bcompare.exe) and add "net use" to either specify the credentials or bind to a drive letter. Does Net Use work in this environment immediately previous to BC4? And if so, does this also kick the credentials into gear for BC4 to use?

              From the command line run:
              net use /?
              to find a full list of commands.
              Aaron P Scooter Software

              Comment

              • myriaxis
                Journeyman
                • Mar 2016
                • 12

                #8
                Hello Aaron,

                It turns out that the problem is related to the Task Scheduler.
                I found similar problem reports on the Microsoft forums.

                Using "net use" solves the problem.
                Since all my BC4 scripts were already setup in one scheduled task, I simply add a "net use" batch file as the first action.
                The batch file does this:

                net use S: \\TargetPC\SharedFolder PasswordUserB /user:UserB /p:no
                S:
                dir

                I don't know if listing the files of the Shared Folder is necessary or not, but it helped me confirm this solution was working.

                Thanks for your help.
                I don't know if it's only me, but I always manage to use Windows in a way that the designers never thought of.
                It's frustrating to always have to resort to work around.
                Again, Thanks.

                Comment

                Working...