Skip to main content

TIES: use Powershell command as pre command locks up

Thread needs solution

Hello

We're using TIES build 8.203 in order to perform backups. Every first Sunday, the server shall perform a new Full-Backup, the other days it will perform an incremental backup. The server uses Windows Server 2008 64bit.

As Acronis for _whatever_ reason, simply overwrites existing full-backups, successfully breaking the history of existing incremental backups, we decided it would be a great idea to either execute full backups manually, right after securing the last months history. Or to write a pre-command that would exactly do this.

In order to have a satisfying amount of options, we wrote a little powershell script, that takes current date, tests if an archive location with same name already exists, creates a proper archive location and moves the last months backup history into that folder. When this was done successfully, Acronis may continue with a full backup. If something went wrong, the full-backup must not start, as it will overwrite the existing one.

My first step was to test my powershell script. It works. Execution-policy is fine, when invoked from command-line, everything is ok.

Now I tried to set it as pre-command in Acronis. The command is the full-path to the powershell.exe, tried both 32bit and 64bit with exactly same behavior. The working dir is the backup location and the parameter is the fullpath to the script to run. All that opens is a blank commandline window, then nothing happens. If I close the window manually, Acronis says "Task failed".

I searched the forum here, found that CMD files are not supported properly and wrote a BAT file. But, whenever I call the powershell-task from the BAT, the window hangs again. If I spawn yet another cmd with the windows command "start", the powershell-task will run, but I cannot check my return value. Start will return only it's own return value, not the return value of the command it ran.

My next work-around would be, to invoke my powershell-script, which for itself will create a result.txt file, holding the return value of my powershell script. This file I can open with BAT commands, evaluate the return value and return this to Acronis.

This is such a long chain of work-arounds, that I found it worth to contact the support. Creating a script, that will do a task I had expected Acronis to be capable to in the first place, that calls another scripting tool - as I can't call it directly - that will create a file to store its result, as I cannot evaluate it directly, is so ugly, that I simply deny of doing this.

If Acronis scheduling is not capable of handling even such simple tasks, I'm afraid I will give windows scheduled tasks the mastership and invoke the full-backup directly with the command line option and burrow the logic and intel into yet another powershell-script. Don't get me wrong, concerning the image-creation the backup is working great. But the logic sourrounding the Acronis core know-how seems to be a little weak so far.

Hope you can give me a hint.

Kind Regards,
Stefan Stern

0 Users found this helpful

Just found a little step to get my return value from start. I missed the "/WAIT" option in start. When given this option, start will wait for the command to terminate and return its errorcode.

So, no need to create yet another file with the return code.

But if you could give me a hint, how I can call the powershell.exe directly, I could remove one more workaround.

Regards,
Stefan Stern

Stefan,
Thanks a mil for posting workaround with "start /wait" to get powershell scripts working. Worked great!

Hi Stefan,

I am not running the same environment as you do but experienced a similar issue. I have Acronis True Image Home running on a Windows Vista 64 bit system. I too tried to use a PowerShell script as to run in the pre-backup portion of the job but could not make it work.

The weird issue was that when using the UI in the Acronis task scheduler, the software could not locate the script that was located in %WINDIR%\System32\Scripts. It turns out that a 32 bit apps running on 64 bit system may not be presented different objects in the same way, see http://www.nynaeve.net/?p=133.

As for PowerShell, the execution policy that I set in the console was not working when running the script through the Acronis console. The problem above is the same here: if you set the execution policy in the 64 bit PowerShell console, it does not change the 32 bit PowerShell policy. Since Acronis True Image Home is a 32 bit app, I had to manually edit the registry for the 32 bit PowerShell execution policy to be able to make things work. Still have to use .BAT file launch the PowerShell script though but it works.

You may want to see if this makes any difference in your environment.

Alain