Deployment Solution

In Altiris NS 7.1, I am attempting to create a few jobs that run a script task, then run a copy file task.  These were copied from the NS 6.9 server that we are migrating away from.  The script portion is, for the most part, to remove an outdated directory on the clients machine.  The copy file/folder portion copies a file or a folder from a server, using a UNC path, to a path on the client machine.  I have placed both of these in a job in the order I would like them to run.  The SMA receives the job, but within a second, comes up with Result: Failure - Return Code 0.  In the client log, it lists:

<event date='Jul 30 14:54:02' severity='4' hostName='MAN-SYSTH-5429' source='Client Task Agent' module='client task agent.dll' process='AeXNSAgent.exe' pid='6000' thread='1468' tickCount='195488050' >
  <![CDATA[Task: Adobe Profiles.Copy File has started]]>
</event>
<event date='Jul 30 14:54:03' severity='4' hostName='MAN-SYSTH-5429' source='Client Task Agent' module='client task agent.dll' process='AeXNSAgent.exe' pid='6000' thread='1468' tickCount='195489080' >
  <![CDATA[CTaskStatusEngine::OnTaskFinished(): Got status for 35dfb467-4505-4f2f-a81c-7dd4151fc2c9]]>
</event>
<event date='Jul 30 14:54:03' severity='4' hostName='MAN-SYSTH-5429' source='Client Task Agent' module='client task agent.dll' process='AeXNSAgent.exe' pid='6000' thread='1468' tickCount='195489080' >
  <![CDATA[Task: Adobe Profiles.Copy File has finished]]>
</event>

Checking reveals that a) the script isn't doing anything and b) the copy file task isn't doing anything on the client machine.  I have checked and the machine/users are able to access the shared folder (its a pretty open share, permissions wise).  I have also made sure the client machine has the Deployment Agent installed (which is working since I can push installation packages to these machines.

Computers I am trying to get this to work on are mainly Windows 7 machines.

UPDATE: I received an e-mail from someone who had this same issue.  To resolve it, he used the FQDN, and it worked.  After trying that, it worked for me as well.

Can you post your script?

You might want to try running a Run Script task on your job first that will net use the UNC location and then have the 2nd task to be the copy file task run on the job. 

Usually the Altiris Agent/Symantec Management Agent won't copy files from a UNC path because it uses the NT Authority [Local]\System account, which has no rights outside the PC it's running on.

The script started working after the server was rebooted yesterday.  It is a simple rd command.

Attempted this; both the rd command and the net use command completed succesfully (drive was created).  The file copy task, though still fails immediately after starting.

The only options for the copy file task (that I can find) are to copy from a UNC path (it asks for credentials to it), and to upload the file to the Altiris server.  I'm considering changing the script to do the copying instead of the agent.

Hey Jobby

It might be true what andy said, that your problem simply is you use "local system" priviledges to access the share.

Are you 100% sure that your computer can access the share?
If priviledges are as open as you say, you could simply put on "Authenticated users" as a read to the share, this means all that are authenticated on the system can access the share (the computer account, whose priviledges are used when using "SYSTEM" account, is also a part of this permission).

At least then you are 100% sure that you have the proper access.

/Morten

Morten (and Andy),

I am 100% sure it can access the share.  We are in an Active Directory environment (should have mentioned that earlier), so it is using my domain user name to access it (I can browse to the folder and access it with full permissions).  Also, I redid the script portion to use xcopy to copy the folder, which worked exactly like I wanted the Copy File task to do.

As far as the copy file task, I also tried entering an AD user for the credentials in the properties of that task.  Whether trying it with or without credentials, the task fails.  For now, I am setting up the script to use xcopy, but for the long term, with the number of jobs we have to create in a year's time, I am still going to have to track down what is causing this to fail.  I'll check with someone to make sure the permissions are set to authenticated users, but I have a feeling it is set to the end customers that use it and the technicians here, so I doubt it will be able to be changed.

Another question on the "SYSTEM" account accessing the share... do you know if DS 6.9 used the same account to access shares when making a copy file task?  If so, then this isn't the issue, as 6.9 worked correctly when deploying this job.

unless you put other credentials in the job.

How about trying a copy task from your NSCap share?

I attempted a copy task from the NSCap share, and it ended with the same result of Failure - return code 0, with nothing being done.

Hi Jobby

Well, this sure is a weird one.
As i reacall, every time you create a "copy folder" job, your folder actually gets shared out, maybe you should start there, and see if the share does contain all your files.
After you have verified/deverified the existens of the files, you should have a look at your site servers, again this is based upon memory, i am not 100% sure it in fact is like this.

The site servers, if i remember correctly should contain your files also.

/Morten

at the time the copy fails? (Do you have failure auditing turned on?)

Where can you check to see if it is on?

Also, if it is off... if we were to turn it on, how does it do resource wise, (does it run full time, will it affect processor/memory usage, etc.) if I may ask.

I have checked the share(s), and they do contain the folders and files that are being specified in the "copy folder" task.

on the computer where the share is to see if it's turned on. It shouldn't take much in the way of system resources, I've never heard of this being an issue.

After fighting this for a few weeks, and looking and seeing that this is a known issue in 7.1 (no solution listed), I have decided that the best workaround for now is to just use xcopy with the /i /e /z /y attributes appended.

Upon looking at the logs, there is no information about why it isn't copying anything, or at what point it is failing.  All access is correct to the shared folder, the path(s) are correct, and the correct options are selected;  just fails immediately (within less than a second of starting).