I recently had a problem where a server side (Altiris DS) script was outright failing to run giving an error 1314 - A required privilege is not held by the client. If the job was run on a client, it worked first time.
I did a little searching and saw this article on the support forums:
http://www.symantec.com/connect/forums/running-ser...
There didn't appear to be an answer in the thread and it was since locked.
After playing with the job in quiestion I've managed to replicate this symptom twice in different circumstances, one with a blank job another with a job that contained file paths. In my job, it didn't seem to matter what I put into the script at any point, even the first line was not getting processed, so the script itself didn't seem to matter. That made me think about how the DS works when it parses a script to be run - I thought the problem may involve UAC / user elevation.
In my particular job I had file paths specified that pointed to C:\windows\temp as a directory for a temporary output text file.
Content was supposed to be written into this text file that was then parsed for various strings.
The job would fail outright with the error message above - A required privilege is not held by the client (1314)
Our Altiris DS implementation runs under a Windows service account, not local system.
The service account that the Altiris DS runs under is a local administrator and the ACL on the C:\windows\temp folder did contain "administrators".
However I'm fairly sure as we run UAC on our servers, to be able to actually use this ACL group membership an elevation will be required.
It appears that the DS application is potentially unaware or unable to cope with this mechanism in 6.9 SP5.
.
Placing the service account onto the ACL for the C:\Windows\Temp directory, directly with modify rights solved the issue and the script ran.
So onto the issue of a blank job, I think the same principal applies here.
When the DS parses a script it usually writes the content into a file called "RxScript.bat" and places it in the temp directory on the machine of execution.
The thing to check here if *any* script doesn't run at all, including a blank one when executed server side is the ACL on the DS temp directory.
Ensure your service account (if you are using one) has modify access to the local temp directory - try %temp% for a user account or c:\windows\temp for the system by default. As long as the account that the DS runs under has write/modify access to the temporary working area without the need for elevation the script will not error on execution.
You may also consider removing UAC completely from your server platform hosting the DS, but if you do chose this route be aware of the security implcations before doing so and obtain the appropriate sign off from a documented change control process. (In other words, test it and cover yourself).
P