Showing results for 
Search instead for 
Did you mean: 

Backup Exec 2012 - Wait-BEJob is not waiting.

Rather than scheduling BE jobs via the GUI, I use a PowerShell script.  And it works very well except for one issue; the Wait-BEJob commandlet doesn't seem to be doing what (I believe) it is supposed to.   I am using this script to back up three servers, using Full and Differential jobs.  All jobs were defined via the GUI, they all run verfication after backup, and were all defined On Hold.  The script fires up via Windows Task Scheduler.  The jobs to be run are determined by the script depending on what day of the week it is.  After the script starts a job (Start-BEJob) it is supposed to wait around until it is finished (Wait-BEJob) and then puts the job back On Hold.  It then starts a Duplicate job (Start-BeJob) and then again, it is supposed to wait around (Wait-BeJob) until it is finished before moving on.  Here is a code snippet showing what is a D2D phase of the D2D2T:


# Load the BEMCLI module
import-module "C:\Program Files\Symantec\Backup Exec\Modules\BEMCLI\BEMCLI"

# Backup Server 1 to disk and verify
Start-BEJob -In "Server1-Full Weekly" -Confirm:$False | Wait-BEJob

# Put the job back on Hold
Suspend-BEJob -In "Server1-Full Weekly" -Confirm:$False

# Duplicate Server1 backup from disk to tape
Start-BEJob -In "Server1-Duplicate Full Weekly" -Confirm:$False | Wait-BEJob

# Put the Duplicate job back on Hold
Suspend-BEJob -In "Server1-Duplicate Full Weekly" -Confirm:$False


The problem I am having is that the Duplicate job is launching before the primary job is finished.   I'm not positive, but I think that the Duplicate job launches between the end of the backup and verification phases of the primary job.  I want it to wait until the verify is finished.  I would be fine if the Duplicate job only queued up to run, but it doesn't... they both go to work on the disk simultaneously.   You can imaging what this is doing to the target disk and performance.

I can't manually put the Duplicate job On Hold after it launches.   If I select "Hold" form the context menu for that job, it says that it is removing the job from On Hold (remember, it was defined as being on hold even though it launches).

I'd appreciate any suggestions here.   Thanks much.



5 Replies

I would suggest that you use

I would suggest that you use the console to schedule your jobs.  It can handle the scheduling rules better than you can using BEMCLI.  You are just creating work for yourself and re-inventing the wheel.

Also, misunderstanding of the purpose of each BEMCLI can cause problems like this.  The Wait-BEJob cmdlet is used by the script to wait for the completion the job and NOT to cause the job to wait.  The only way to delay the execution of a job is to hold it.  If you had used the console, the duplicate job would only be executed after the backup is completed.

BEMCLI is meant to supplement the console and not to replace it.

@pkh, perhaps I've explained

@pkh, perhaps I've explained the problem poorly, but I think you're mis-understanding the problem.   My script is not attempting to hold up the job.   The problem is that the Duplicate job (i.e., the second job in the chain) is launching before the backup job (the first job in the chain) has completed.  This suggests to me that Wait-BEJob is terminating prematurely.  That is, it is NOT waiting for the job to complete as it is supposed to.

(BTW, just for reference sake, the term "console" is typically used to refer to a command-line style of interface and not a GUI.  In that sence, PowerShell IS a console.   The GUI however is not.)



It might help if you could

It might help if you could explain why you feel the need to script something that the GUI can do for you


However against your script, it may be the syntax of your pipe into the Start-BEJob command that is causing the problem. I know their are some exmpales in the hlpe file, however they do not include an example involving Start-BEJob.


Have you tried putting Wait_BEJob on a separate line (with the -InputObject specified to the job name)?



@Colin; The purpose of

@Colin; The purpose of resorting to the script is for job chaining across servers.  I have three servers to back up (D2D2T) and the window is tight.  So, I thought the best sol'n would be to define the jobs using the GUI, putting them all on hold and then launching them using a PowerShell script and Task Scheduler:


Using the GUI I could chain (link, in BE parlance) the Duplicate jobs to their respective primary job, but since Wait-BEJob wouldn't know about the Duplicate job, I'd expect trouble.  Thus I treat the D2D and D2T as separate jobs, launched in sequence via the script.

I don't see a way using the GUI to queue a server backup right behind a previous server's duplication job in the way that scripting allows.  And because the backup jobs use the same disk for the D2D part of the backup, I don't want to start backing up the second server while the first server job is being duplicated.

The syntax for Start-BEJob and Wait-BEJob, I got from here:

(@pkh: The irony is not lost on me that you were the OP on that!  ;)   )

I will try your suggestion regarding putting the Wait-BEJob command on a separate line rather than piping.  Thank-you.


It does not matter whether

It does not matter whether your definition of a console is correct or not. What matters is that on this forum, the BE GUI is referred to as the BE console.  The word "console" is never used with BEMCLI.

What is the irony of me being the author of the article that you based your scheduling on?

The job chaining described in my article can be used in certain circumstances.  It is not meant to replace the scheduler in the console. It was needed to address one of the short-comings of BE 2012.  This short-coming of not being able to backup multiple servers in one job is addressed in BE 2014, so the obvious solution to your problem is to upgrade to BE 15.  The upgrade is free if you are on a current maintenance contract.

The output of the Wait-BEJob cmdlet is the job history object and this can only be produced when the job ends because it contains the job status.  The Wait-BEJob cmdlet CANNOT end before the verification phase if it is part of the job and hence it is not possible for the duplicate job to start before the end of the job which the Wait-BEJob cmdlet is waiting on.