Backup & Recovery

One of the changes that BE 2012 has brought about is the change in the BE commandline interface from BEMCMD to BEMCLI.  BEMCLI is based on Powershell which is a more powerful scripting language than the DOS commands.  Needless to say, to fully exploit BEMCLI, you got to be familiar with Powershell.  There are a lot of books on Powershell and also a lot of resources on the Web that you can refer to.

This article is not for the Powershell expert.  This article is for the people who are less familiar with Powershell and just want to use BEMCLI to control BE, either from the command-line or as part of a pre/post command.

1) Get Powershell v2.0

BEMCLI requires Powershell v2.0.  If you are using Server 2008 R2, then you already have Powershell v2.0.
For earlier OS releases, check whether someone has already loaded Powershell v2.0 by running the BE clilauncher
Start > All Programs > Symantec Backup Exec > Backup Exec Management Command Line Interface
If the clilauncher loads properly, you are good to go.  Otherwise, download Powershell v2.0 for your OS from
and install it.

2) Change your Powershell execution policy

By default, the Powershell execution policy is set to Restricted which means that you cannot run scripts.  Depending on  the security standards of your installation, you would need to change the execution policy to a less restrictive one.  I think RemoteSigned is a good execution policy.  It allows you to run unsigned scripts that are written on your machine, but it will only run scripts and configuration files that are downloaded from the Internet (including e-mail and instant messaging programs) which are properly signed with a digital signature from a trusted publisher.
To change your execution policy, 
a) run Powershell
Start > All Programs > Accessories > Powershell > Powershell
or start a command prompt and enter powershell.
b) Check your execution policy by entering
get-executionpolicy -list
c) if necessary, change the execution policy. Enter
set-executionpolicy remotesigned

3) Import the BEMCLI module

If you want to run BEMCLI from a Powershell console or Powershell script, you would need to import the BEMCLI module.
import-module "\program files\symantec\backup exec\modules\bemcli\bemcli"
You can do the import for every Powershell session and script, or do include the import-module command in your profile.  If you use the latter method, then the import-module is done automatically.  You can decide which profile that you want to modify.
        Name                                        Description                
        -----------                                      -----------
        $Profile                                      Current User,Current Host  
        $Profile.CurrentUserCurrentHost   Current User,Current Host  
        $Profile.CurrentUserAllHosts        Current User,All Hosts     
        $Profile.AllUsersCurrentHost        All Users, Current Host    
        $Profile.AllUsersAllHosts             All Users, All Hosts  
Edit the appropriate profile and add in the import-module command, e.g.
notepad $profile.AllUsersCurrentHost

4) Get familiar with BEMCLI

To see all the BEMCLI cmdlets, you can open the BEMCLI_en.chm file which is found in the BE installation directory.  Alternatively, you can enter
get-command -module bemcli
in a Powershell session.
To get details of each BEMCLI, you can enter
get-help <BEMCLI cmdlet>
in a Powershell session, e.g.
get-help Get-BEjob

5) Run BEMCLI cmdlet or scripts as pre/post commands.

Below is an example of a post-command running a BEMCLI cmdlet
c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe start-bejob -i '"Server1 Backup 00005-Backup"' -confirm:$false
Below is an example of a pre-command running a Powershell script from the root directory.
c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe '\script.ps1'
I would encourage you to explore BEMCLI which is a lot more comprehensive and powerful than BEMCMD.  If you combine BMECLI with Powershell, you would have a powerful tool to control and report on BE.  See my follow-up articles on how to use BEMCLI to start BE jobs and to report on them.
You might also want to enlarge your command prompt window to accommodate wider and longer outputs.  Right click on the top left-hand corner of your command prompt window and then select select Defaults.  Change the window and buffer sizes like below.
The changes will take effect the next time you start a command prompt.
You may want to read my article on using BEMCLI to chain jobs.
or download my script to import tapes into the first empty slot


For those of you having difficulties (like me) reading error message in red on a black background, you could issue those commands so that to get black text on white background (along with error message in red):


It is probably possible to enter them in a default configuration file but don't search for it!



Is it possible to edit the password for logon account in BE?

I am trying following command, but get the error:

BEMCLI> Get-BELogonAccount "administrator" |Set-BELogonAccount -NewPassword 'p'

Set-BELogonAccount : Cannot bind parameter 'NewPassword'. Cannot convert the "p
" value of type "System.String" to type "System.Security.SecureString".
At line:1 char:68
+ Get-BELogonAccount "administrator" |Set-BELogonAccount -NewPassword <<<<  'p'
    + CategoryInfo          : InvalidArgument: (Smiley Happy [Set-BELogonAccount], Param
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,BackupExec.Manage

How to use 'SecureString'?


I posted the following to the Backup Exec blog (Get-BEMCLI entry) about this topic:

Regarding shell configuration, PowerShell doesn't provide a mechanism to associate a profile to a specific *module* -- but you can easily create a shortcuts that launch customized PowerShell environments.

Customizing BEMCLI's shell experience

Here's what I'd do to give a custom look to my BEMCLI shells:

1. Create a file (say, C:\scripts\BEMCLI_profile.ps1) with the following:

Import-Module BEMCLI

2. Make a desktop shortcut that runs the following line to launch PowerShell using only the contents of that script:

PowerShell.exe -noprofile -noexit -file "c:\scripts\BEMCLI_profile.ps1"

Notice the "-noprofile" and "-noexit" switches; you can omit "-noprofile" if you have a global profile that you want to have loaded before the contents of the BEMCLI_profile.ps1 script.

...which leads me to the next solution:

Another approach: use your global profile ($profile)

Each shell (the standard cmd.exe-style shell, and the PowerShell ISE) has its own global profile as well.  To discover where the global profile for your particular shell is, take a look at the $profile variable:

PS C:\Users\Kfreiheit> $profile

It's in your userprofile's Documents folder.  However, it's not created by default.  In fact, its containing folder isn't created, either.  Here's how I create it, edit it, and then make it 'live' in my current shell:

PS C:\Users\Kfreiheit> new-item -itemtype file $profile -force

    Directory: C:\Users\Kfreiheit\Documents\WindowsPowerShell

Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---         6/18/2012  10:31 AM          0 Microsoft.PowerShell_profile.ps1

PS C:\Users\Kfreiheit> notepad $profile
PS C:\Users\Kfreiheit> . $profile

The -force parameter to new-item makes it create the intermediate folders (in this case, the "WindowsPowerShell" folder).

Running "notepad $profile" does what you'd hope -- this is where I edit and save the script I want to run every time I start up a new shell.

The ". $profile" makes my current powershell session "dot-source" the new script, to make its contents run in the current scope.  That way, I don't have to exit and restart a new shell to get the benefits of my edited profile.  Every time I want to add something to my profile, I go through a similar workflow (minus the New-Item step, of course).

Now, when I launch a new PowerShell window, it has BEMCLI loaded and a while background.

Hope this helps!

-Kirk out.


Hello everybody !

I need some help.
Today we have an application that starts the backup Job from the command line and working in BE 2010.
It was upgraded to BE 2012 and now this script does not work, I found some posts that has changed the form of Job command line, now using the power shell.
I used the command and started the backup job, however I need this file .BAT doesnt close until this job  finishes (with error or success) so that my application continues with the process.

I tried some functions like $LASTEXITCODE but unsuccessfully. The file with the command, starts and close, even with the job running, the application keeps working and can only continue after finishing the backup.

I'm currently running this:

The file that will be executed by the application is a .BAT with the following lines:

powershell.exe-file "c: \ policy.ps1";

Policy.ps1 -  the file contains the following lines:

set-executionpolicy remotesigned
import-module "\ program files \ symantec \ backup exec \ modules \ bemcli \ bemcli"
start-BEJob In SAO-DB-ORTEMS-D-Confirm: $ False

Does anyone have a command line where can bring me the result but while the job doesnt finish, keep the .BAT opened?


 Thank you


Hi PinhoM,

I'm the lead developer for BEMCLI, the PowerShell module for Backup Exec.

What you'll want to do to block your .bat from returning before the job finishes is use "Wait-BEJob".

To get the error code (if any) from the job and return it like a .bat file would, you'll need to get the job history and return its ErrorCode property.

I think this will do the trick for you:

# Note: you can just give the parent directory that contains the module files
import-module "c:\program files\symantec\backup exec\modules\bemcli"
$job = start-BEJob "In SAO-DB-ORTEMS-D" -Confirm: $ False
Wait-BEJob $job

$errorCode = $job | Get-BEJobHistory | Select -ExpandProperty ErrorCode
return $errorCode

# Another way -- you can use a single pipeline for the whole operation like this:
return Start-BEJob "In SAO-DB-ORTEMS-D" -Confirm: $ False | Wait-BEJob | Get-BEJobHistory | Select -ExpandProperty ErrorCode

Nice document, thank you


See this document for what is not supported by BEMCLI

BE functions and utilities that BEMCLI does not support in BE 2012