Client Management Suite

We are seeing a flood of warnings in the log file on the SMP 7.1 server:

Description: Task instance 233309e9-4a85-420c-989e-1d8ff8e57ea6 didn't return "@ReturnValue"

After running a SQL script provided on another post, we found that the Detection Check for the Software Deliver policy we enabled is causing the issue. However, we were under the impression that the detection check needs to be enabled in order for the job to know if the software has already been installed or not.

Has anyone else encountered this issue and if so, is there a way to stop the messages?

if, for example. is Symantec Workspace Virtualization Agent policy (where we had the problem). is not much of a problem because it run on a dynamic filter.

the detection check is so it does not keep trying to install, in the case of Symantec Workspace Virtualization Agent policy the is done by the dynamic filter.

can you post the detection rule that causes the problem?

The task name the SQL script refers to is "Detection check for 'Software Delivery Policy', (where 'Software Delivery Policy' is the name of our policy). In other words, it is referring to a SWD policy that we created. The errors also occur for any new SWD policy we create.

exe or msi

if it is a .msi file, it creates the Detection check automaticly.

if it's a .bat or .exe -file you had imported, you need to create a Detection rule manually (in the software ressoure)

need more info to help

The package is an .exe file.

The detection rule is as follows:

Expression type: Static File Expression

Base Folder: Static Path

File Path: C:\IS_Data\Install_Logs\Local Group Setup v2.log

Version: >

the problem is you do not have a version of a log file. If right click on Exe file, you can se a version.

altiris cant find a version, When It scans the log file, it will return an error. your error message

can you tell what the program details, I can perhaps suggest a Detection rule

you need a new Detection rule

you can use sql in the link to find the name of the polecys, if the is more the one policy has got the error

 https://www-secure.symantec.com/connect/forums/description-task-instance-cd8c0e8f-ac82-4d70-b131-fef8270fab0f-didnt-return-returnvalue

I appreciate your help,  but we are starting to go around in circles. I have already identified the policy using the SQL script and know which detection rule it is using. The question is why is it creating the errors and how do I stop them?

the one named the problem

altiris cant find a version, When It scans the .log file, because the .log has not got one.

it will return an error. your error message

-------

Sorry, I didn't see your other previous post.

The executable in the package updates local group members (we are having trouble with our GPOs).

The detection rule just checks for the existence of the log file, which confims the executable ran on that machine. So, I'm really not sure how the file version ties into this, since it just makes the change, it doesn't actually install.

you have a Detection rule whit a Version: > and altiris can not read a version on a log fil and then altiris vill create you error 

If you change Detection rule to a regfile or something elles the problem vill stop 

Did you include this file as part of the software resource?  Did you then add it to the File Inventory tab?  Per the Software Management best practices for a static file expression detection rule:

For the Software Resource this detection rule is a part of, you need to add the file in question under the File Inventory tab. This was required until 7.1, where we have had success without having to add the file to the File Inventory tab, however if you run into problems it is a good troubleshooting step.

We followed the instructions you posted and it has greatly reduced the number of warnings. Thank you. However, we are still getting about three per minute. When cross referencing the GUID, they are still coming from the same SWD job. Any idea why they have not stopped completely?

My best guess would be that some clients have not updated their configuration, and are still operating with the old rules.  The log entry on the SMP should provide enough detail for you, I would think, to narrow this down.  Does the complete error include a client GUID that's reporting the problem?

Thanks for all of your help. We have disabled the policy and gave it plenty of time for the clients to check in, but we're still seeing errors. I am working with Symantec support and it looks like the issue might actually be with our filters, not the detection rule, as per this article:

http://www.symantec.com/connect/forums/task-instance-x-didnt-return-returnvalue

I'll keep you posted...

The 'Install SWV agents' is exactly the policy causing this problem for me.  I'm not sure I understand your explanation.  How do I resolve this?

if you run the sql in https://www-secure.symantec.com/connect/forums/description-task-instance-cd8c0e8f-ac82-4d70-b131-fef8270fab0f-didnt-return-returnvalue you can find the problem.

but you have.

we solved our problem by creating a new detection rule after we hate deleting the old detection rule

Detection Rule for Workspace Virtualization solution 6.1 SP7 (32 bit)

MSI product code: f0903be8-e528-405d-8ae5-2a4c7048827a

and chek in the Detect per-user installations for the interactive user box

-----------------

2 time we had problems it was one of my colleagues the hate made a detection rule

File Version to a file

and the file did not exist and that create the error

-----------------

hope it help and write if you need more help or if it solve your problem

After some testing, we found it was not the custom filters. The issue was still with our detection rules. We disabled the offending jobs for now until we find a better rule configuration. The Symantec Support tech suggested we use registry rules instead of static file expression.

After disabling the SWD jobs, we still had errors messages coming into the SMP server logs for a few days. By using the SQL (from a previous post by Pedahl)  we looked under 'Resource Name' at the computer name listed. We found it was only a few computers generating multiple errors. For some reason, they were having trouble reporting in and purging the old jobs. Pushing out an SMP agent uninstall and then reinstall to those computers fixed the issue.

So, we are still not 100% sure why the at the static file expression doesn't work correctly. Seems like it should be easy enough to configure. But, we will explore other rule options if we can't get it figured it out.

My Detection Rule for Workspace Virtualization solution 6.1 SP7 (32 bit) has the detect per-user installations already checked.  Did you mean that I should UNcheck it?

.

Well, that didn't seem to help.  My logs are still littered with this error.  Thanks for the suggestion though, it was worth a shot...

when we had the errors both times I talk with a susporter named Aleksander and we solved by

by creating a new detection rule after we hate deleting the old detection rule

Detection Rule for Workspace Virtualization solution 6.1 SP7 (32 bit)

MSI product code: f0903be8-e528-405d-8ae5-2a4c7048827a

and chek in the Detect per-user installations for the interactive user box

-----------------

2 time we had problems it was one of my colleagues the hate made a detection rule

File Version to a file

and the file did not exist and that create the error  (and I know symantec write that you do not have to write something in the version number, but then you can get this error

and

the files you run cheks on must have a version number)