Before & After Job Scripts not executing successfully

[MAS]

This refers to case # 02269438. We want to have the account used for backup disabled most of the time. We would then run a PowerShell script at the beginning of backup jobs to enable the account and a PowerShell script at the end of a job to disable it again. I have written the PowerShell scripts which work correctly if run directly, that is by right-clicking and selecting "Run with PowerShell." I have also written a batch file for each PowerShell script which also runs successfully. However, when I try to run the scripts by selecting "Run the following script before the job:" and Run the following script after the job:" from Storage > Advanced Settings > Scripts within the GUI, this does not work. The job log reports that the pre-job and post-job scripts completed successfully, but the account remains disabled. I have tried both that batch files and the PowerShell scripts from within the job settings and get the same results either way. There are no errors in the Windows PowerShell event log.

The Console is installed on the Backup and Replication Server, so the scripts are executed on that server. Testing of the scripts external to Veeam has also been done on the same server. Support said that they could not help since the logs indicate that the scripts are successfully completing and suggested that I post here. Ideas or suggestions?

[PTide]

Hi,

Just going to ask you a few diagnostic questions regarding the problem. You said

We would then run a PowerShell script at the beginning of backup jobs to enable the account and a PowerShell script at the end of a job to disable it again

and then you state that

The job log reports that the pre-job and post-job scripts completed successfully, but the account remains disabled.

Please correct me if I'm wrong, but doesn't the fact that the job finished successfully and the account remains disabled means that everything had worked just as intended?

Thank you

[MAS]

Good question. The job does not finish successfully. I'll expand on what happens. The job log reports that the pre-job script completed successfully, but then there is an error: Failed to connect to guest agent. Errors: 'Cannot connect to the host's administrative share. This user can't sign-in, the account is currently disabled.'

I can also enable the account, change the pre-job script to the script that disables the account, and the job runs successfully instead of failing as it should.

[PTide]

Failed to connect to guest agent. Errors: 'Cannot connect to the host's administrative share.

Which host, VBR or VM? There should be an IP address following the message.

Regarding the pre-job script - I believe that there is a string in your script that is supposed to enable the user account, is that correct? Do you have any code in your script that checks if the account has been toggled successfully? I suspect that in general your script returns '0' (zero) for some reason, while in fact the particular command within it fails to enable the account due to insufficient rights of the user that the script is started under. To troubleshoot please try to run either of your scripts manually under the same account under which Veeam Service is being run.

Thank you

[MAS]

Sorry, I thought that I had replied. I must have not clicked on 'Submit.' The host is the VM. I determined part of the problem. The Veeam services were configured to use the Local System Account. I modified the Veeam Backup Enterprise Manager service, Veeam Backup Service, Veeam Broker Service, Veeam Data Mover Service and Veeam Guest Catalog Service to use a domain admin account. Now the scripts are executing properly so that the account is enabled at the beginning of a backup job and disabled at the end of the backup job. The problem is that some (7) of the VMs in a job of 10 VMs are successfully backed up and the remainder fail with the error: "Cannot authenticate user. Soap fault. Cannot complete login due to an incorrect user name or password." The odd thing is that all of the VMs use the same account to be backed up. It is not always the same VMs which fail to backup.

Case 02281345 has been opened for this.