Error 1314 running powershell script as a post command

[Spencer_Simpson]

It seems simple enough: I'd like to run a PowerShell script as a post job command.   The script does what it should, but when I make it a post job command, Backup Exec refuses to run it, with the following message in the job history:

Error: Could not start Post Job Command < C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -nologo -noninteractive -file "blah.ps1" -test >. Error (1314): A required privilege is not held by the client.

I've searched around and found various suggestions in Symantec support and Technet, none of which seem to make a difference.  I'm backing up a user defined share because there's no way to put a remote agent on the remote server. This also means the media server's remote agent service has to run as a domain user to connect.

The post job command is configured to run on the backup exec media server.     The system logon account is a domain user, and all of the sevices run as te same account on the media server.

I'm not seeing any failure messages in the security log in Windows Event viewer, and the server is configured to audit all such failures.

[Backup_Exec1 · Accepted solution]

Hi Q This also means the media server's remote agent service has to run as a domain user to connect. Remote agent service never should be ran on domain account ,it should always use local system account to run, so in your case it seems you running it on domain account ,please change it to local system account and try job again Thanks.

[pkh]

I'm backing up a user defined share because there's no way to put a remote agent on the remote server.

I don't understand.

1) what OS is the remote server running that you cannot put a remote agent on it?  It is a NAS?

2) What version of BE are you running?

3) What is your Powershell script doing?

4) If you are using your script to backup the share, why can't you backup the share in BE using its FQDN.

5) Can you run the Powershell script when you are logged on as the BESA?

[VJware]

Have you looked at this KB - http://www.symantec.com/business/support/index?page=content&id=TECH70754

[Backup_Exec1]

Hi

I have already mention it quiet before, to run remote agent service using local system account.

Thanks

[VJware]

Yes, I did see that, however I intended to point out the KB article (the OP had mentioned he had looked at several posts/articles, was just checking if he checked Symwise as well or not)..

[Backup_Exec1]

Hi

Fine ,got your point too

Thanks

[Spencer_Simpson]

1) It's a NAS (EMC VNXe). The granular access to the backup gained from backing up as a user defined share trumps the speed benefits of NDMP.

2) 2012 but it also hapened in 2010 R3

3) The script deletes the contents of the shared folder it just backed up (no agent, so no backup and delete jobs), taking care not to delete things that would corrupt the shared folder if they were deleted.

4) N/A. I'm content to let Backup Exec do the backing up.

5) Yes, it works perfectly.  A Technet article suggested editing local security policy to allow the BESA to "log on as part of the operating system"

[Spencer_Simpson]

Yes, I saw that, but the script isn't for controlling Backup Exec.   I thought maybe changing the execution policy for CurrentUser would solve the problem but it didn't.

[pkh]

@spencer - How about trying to run this simple script as a post-command?

import-module "\program files\symantec\backup exec\modules\bemcli\bemcli"

get-bejobhistory -fromlastjobrun -jobtype backup > C:\ps-output.txt

[Spencer_Simpson]

Exactly the same error.  The system doesn't want to let the Remote Agent run powershell at all, never mind what's in the script.

[Spencer_Simpson]

I'm floored.  This turns out to be an answer.  Sort of.  It's impossible to accept such a categorical reply without some explanation.

Since pkh's mini-script had the same problem as mine, I decided to try changing the remote agent over to Local System Accont. All the other services run as the domain account.

My test job backs up one file on the NAS device and runs the script. Not only did it run the script, it backed up and verified the file.  A point restore job successfully restored the file.

What's the real reason that using Local System Account for the remote agent works?   If you're backing up a user defined share without the a remote agent on the other machine, the remote agent on the media server isn't actually used for backing up.   Even when the job log says "The Backup Exec server will use the local agent to try to complete the operation."  All the remote agent appears to do is run the post-command. 

Why doesn't the agent run the script when it's run as the domain user?  My guess is that the login session needs elevation in order to run powershell.   There may be setings and tweakings I can do to get the domain user to run with elevation by default, but it seems to work.

Of course, my script deletes files stored on the NAS device.   And it's running as the local system account.   I did an Effective Permissions for the media server's computer account on the shared folder and it appears to have the file system permissions to delete files.

We'll know for sure when the scheduled job runs this evening.

[Spencer_Simpson]

To verify this bit:

> the remote agent on the media server isn't actually used for backing up.

I successfully backed up and restored a file that the media server's local system account decidedly did *not* have access to.   I'm not sure which of the services is backing up the files, but it's not the media server's remote agent.

[Colin_Weaver]

I just tested that script

Had a .BAT file containing

powershell.exe C:\LastJob.ps1

and inside LastJob.ps1 I had

import-module "D\program files\symantec\backup exec\modules\bemcli\bemcli"

get-bejobhistory -fromlastjobrun -jobtype backup > C:\ps-output.txt

The post command contained the batch file and it was set to run on the media server itself (default is run on remote and will fail if you do not change this as your command is media server specific)

It worked with no issue.

My beremote service is set to local system as such the security context would have been the System Logon account defined inside BE. Although as I backed up local resoruces on the media server it is possible that the security context might be the account used to access the remote system in the Backuop job configs for your environment.

As such what you probably need to do is login to the Windows/Operating System console of the media server using whatever account is the System Logon and then start the powershell based BE Management Command Line Interface and check that it starts and that you can run your get-xxx command without error.

[Spencer_Simpson]

Please explain this:

> My beremote service is set to local system as such the security context would have been the System Logon account defined inside BE.

The local system account is called NT AUTHORITY\SYSTEM locally and the Active Directory computer account DOMAIN\SERVER$ from other computers in the domain.

The System Logon account has completely different credentials, e.g. a domain user such as DOMAIN\BKUPEXEC

They're two different things.  Does the remote agent impersonate the System Logon credentials during the backup? 

[pkh]

Not being able to run Powershell scripts is an interesting side-effect of not using the LSA to start up the BE remote agent service.  By default, the BE remote agent service uses the LSA on all servers, media as well as remote servers.

[Colin_Weaver]

The bremote agent runs as local system in terms of the services but to access data for the backup the account name specified in the backup job properties is used and would be DOMAIN\user

Also please bear in mind when I refered to System Logon Account earlier, I meant the account defined as "System Logon Account" inside of Backup Exec - I was not referring to the Microsoft/Operating system use of the same term, This account will also use a DOMAIN\user account.