I currently have a PowerShell script that calls Beyond Compare v3 to copy files from a secure SFTP site over to my network. Whenever I run the PowerShell script in the PS GUI and PS Console, it works perfectly fine. It is able to connect to the SFTP site and my network, and it copies the files over.
I created a job in Control-M that calls the PowerShell script with 2 paramaters passed through. When I run the job, it does not copy the files and the Beyond Compare log says:
Connecting to XXX.XX.XX.XXX
Server key [ssh-rsa XXXX XX:XX.....]
Connection failed: Attempted to open a "Unknown Host Key" dialog when running silently
Attempted to open a "Unknown Host Key" dialog when running silently
Load comparison: "My Location Path" <->
Fatal Scripting Error: Unable to load base folder
Like I said, when I run it through PowerShell itself it is able to connect no problem and copy all of the files over, so my Beyond Compare script file has no issues. I believe this is an error with Control-M itself.
The first time you connect to an SFTP server in Beyond Compare, it prompts you to accept the server's host key with the check box "Add host key to trusted cache".
The error message indicates the script run via Control-M doesn't have the SFTP host key in its trusted list. Because it's running as a script, it can't display the GUI prompt to accept the key and the script fails.
The trusted cache for SFTP servers is stored on a per-user basis in "%appdata%\scooter software\beyond compare 3\". If Control-M is running Beyond Compare as a different user account, it won't have access to the trusted list for your account and generate the error. You can either use the same user to run the Beyond Compare script via Control-M, or copy the settings to the Control-M job's user account.
This error will also sometimes display if you're running a Beyond Compare script as the same user account you used interactively, but the non-interactive run doesn't have access to your user profile. An example of this is running Beyond Compare scripts as scheduled tasks on Windows Server 2012, because it has a bug that loads the default profile instead of the user profile. Running the task from a portable install after connecting once interactively to accept the key is a workaround for the Windows Server 2012 issue.