Software compliance check issue

[Tomasz Woźniak]

Wello,

Currently we are working on Self-Service software portal for the end users. The portal will leverage Symantec Workflow Solution and SMP platform.

Each piece of software will have 2 policies Install/Uninstall and 2 correspondig filters applied as targets.

The install/uninstall requests are handled by adding or removing the computers from the filters.

We have stumbled across an issue when detecting compliancy. Take the below as an example.

1. New machine, I want to install a piece of SW in this example Filezilla.

2. If I run the Compliance check using SQL query, both Install/Uninstall Policy GUIDs bring back NULL – which is expected as the machine has never been in any of the 2 filters.

3. I install Filezilla using SW Console

4. If I run the Compliance check using SQL query, immediately the Install Policy GUID gives me a value of 3. Uninstall Policy GUID gives me NULL. – Again expected.

5. I uninstall Filezilla using SW Console.

6. If I run the Compliance check using SQL query, immediately the Uninstall Policy GUID now gives me a value of 3. But also the Install Policy GUID gives me a value of 3 as well – even though the computer is no longer in the Install filter. These values seem to stick and I cannot find a way to reset them.

   I need a way of resetting the compliance when I remove a computer from the Filter so that it will give me either NULL or a value <3. 
   It seems to stay at 3 forever. The used table is Inv_Policy_Compliance_Status.

select Compliance from [Inv_Policy_Compliance_Status]

where

[_ResourceGuid]='5a6a4924-06dc-479e-9b63-c91ed0b2245b'-- --ZPLCZC2410VHD

AND

[PolicyGuid]='f127c3d9-f0c0-45d9-9802-7ce36aa7015a' --302370 - FileZilla Client 3.3.5.1 1

 

Any ideas ?

Thanks,

Tomasz

 

[WDRAIN1]

This is a great question!

Does anybody know the question of how to reset or recheck the compliance on a client so it updates the [Inv_Policy_Compliance_Status] table?

[Arthur Prosso]

Hello guys !

As you noticed the compliance reflects the last run status of the the policy (which may contain N components with different commandline types and/or tasks)! Compliance does not give info about whether SW component in the policy is installed or not.  There is table Inv_InstalledSoftware for that purpose.

I am wondering what is the purpose of "resetting" the status?  The most straightforward way  is to allow the policy to run again  (change the schedule or  wait for next runs for recurring schedules) , but the then if it is not compliant it will run commandline on client and become compliant. 

You may uncheck  Remediation checkbox and then the policy WILL NOT run the commanline and refresh compliance status
However Thomasz's use case involves Software Portal policies which I suppose are desired to be always functional, i.e run commanlines , thus unchecking Remediation is not a good option. 

There might be a solution if the purpose of resetting Inv_Policy_Compliance_Status is clarified.
Regards
Artur














------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[WDRAIN1]

Hi Artur

Thanks for the quick reply. The purpose of using  "Compliance" Value in Inv_Policy_Compliance_Status table is reporting the deployment compliance of software deployed. 

I'm experiencing a situation where a Software Delivery Policy is deployed to a number of clients and on some clients (not all ) the Compliance Value is not updating or creating a record in the Inv_Policy_Compliance_Status table for some of these clients.

In troubleshooting this issue I have confirmed that the clients not updating are members of the SWD Policy Target and this is validate by seeing the SWD policy in the Software Delivery Tab with a "Compliant"  status for the Compliancy from the Symantec Management Agent. The SWD Policy has even been ran manually in the Symantec Management Agent in an attempt to force the client to update/Add the Compliance Status in the Inv_Policy_Compliance_Status table. Even doing this fails to update the record for the client in Inv_Policy_Compliance_Status table.

My thinking is something on these clients is corrupted related to that SWD Policy, which is why the records are not updating the table for these select clients even though in the Agent logs it show the opposite.

My question to you is "would you know of solution outside of "re-installing the client or creating a new SWD Policy" that would fix this issue"?

Regards

[Arthur Prosso]

HI!

What ITMS release version do you have ?

>  on some clients (not all ) the Compliance Value is not updating or creating a record in the Inv_Policy_Compliance_Status table for some of these clients.

"Not Creating" and "Not updating" are different issues
"Not creating" could happen if Client Message Dispatcher Service on NS is down, but the situation should be resolved by itself once the service is up and running again.

"Not updating" is by design- if the compliance check result result is equal to the previous one (to avoid extra redundant NSE Xmls sending up to server) 

To enforce resending compliance results every N days create registry tree node HKLM\SOFTWARE\Altiris\Altiris Agent\SMFAgent\Delivery\Options

Under Options create DWORD entry MinimumComplianceStatusInterval - holding DAYS interval threshold) when compliance must be resent relative to previous sending timestamp  - will only work if policy execution is kicked off - so kick off it manually 


>   creating a new SWD Policy" that would fix this issue ?
The new policy will add its own entry in the table. It will NOT add bits for another policy.

However it would be useful to know whether agent can send anything to NS, so yes, please test other policies.
Compliance status must be always resent if it changes or if policy is new.
If it is not the case I would suggest you to turn to the Broadcom support.

Regards
Artur




------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[WDRAIN1]

Hey Artur

We have 8.5 RU4.

[Arthur Prosso]

Hi!
8.5 RU4 is good enough for the registry option mentioned above- it will work for compliance status sending enforcement .
Regards,
Artur

------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[WDRAIN1]

Hey Artur,

Thanks for the registry key:
"HKLM\SOFTWARE\Altiris\Altiris Agent\SMFAgent\Delivery\Options"

and  the "MinimumComplianceStatusInterval"  DWORD Registry Value

I was able to test and this work and forces the client to update the Inv_Policy_Compliance_Status table and this was my goal.

Checking the client log I was able to see this entry...

Could you elaborate a little more on... 
(1) what could cause a client not to update the Inv_Policy_Compliance_Status table

(I did note your reply regarding that "Not creating" could happen if Client Message Dispatcher Service on NS is down, but the situation should be resolved by itself once the service is up and running again., but this is not our case.)

(2) and also more about this undocumented registry "MinimumComplianceStatusInterval"  value and other possible undocumented registry values that might be helpful.

Thanks
Regards
William

[Arthur Prosso]

Hello, William!

1)  It must never happen. Even if the policy schedule to run in the future it would send the "unknown" compliance status right away.
If you experience frequent problems with non sending the compliance status with other new policies  I would suggest to use your support channel to escalate the issue. 

2) The only thing that comes to my mind is bypassing functionality that blocks Software Delivery .

Background :
If managed delivery policy X was setup to restart after successful component installation then when it successfully installs a component it wants the machine to reboot. BEFORE reboot happens the software delivery is blocked. This was designed to avoid other policies to break environment when a sudden reboot happens and they deploy bits .

However reboot may be delayed by user opting to defer the reboot - so there might be no software delivery allowed for a long period  (days ???) 
To avoid the execution blockout for other policies use  DWORD
DisregardPostRunAction=1  under 
HKLM\SOFTWARE\Altiris\Altiris Agent\SMFAgent\Delivery\Options"

Regards
Artur

------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[WDRAIN1]

Thanks Artur,

 

Would there be any repercussion or negative impact of deploying the following registry key

 

MinimumComplianceStatusInterval = 1

"HKLM\SOFTWARE\Altiris\Altiris Agent\SMFAgent\Delivery\Options"

to clients in our environment?

 

 

 

[Arthur Prosso]

Hi William !

It will be a certain number of EXTRA small NSEs (NS event xmls) sent from all the clients daily.  
1 per policy per client in case policy has a daily recurring schedule. 

If number of policies is less than 20 per each client I believe the setting is affordable for any environment.
Otherwise please control your NSE queue on the server.
Regards
Artur




------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------