Video Screencast Help

MSD installing on clients outside of the policy

Created: 05 Nov 2012 • Updated: 05 Nov 2012 | 18 comments
ckgsdad's picture

All,

We have one of our 6 active MSD policies installing on clients outside of the filter applied (about 1k so far). What we do here is create a master filter for each deployment then add sub filters as inclusions. The sub filters are built either by query (name ranges) or CSV so nothing out of the norm. The master filter and each of the sub filters DO NOT contain any of the clients that it incorrectly went to and neither does the policy. One of the clients that got the MSD was mine so I was able to check the logs, and know (since I built the filters) that my client ID is nowhere near the ranges that have been used in the filters. I've also made sure that there are no DNS reated issues and no duplicate GUID's.

 

We have an open case with Symantec on this, and like I said we have 6 active policies all built the same way and this is the only one going off the reservation. Any thoughts or ideas are greatly appreciated.

SMP 7.1 MP1 SP2

Steve

 

Comments 18 CommentsJump to latest comment

andykn101's picture

I take it you've checked the Target of the Policy to double check your Client ID isn't in that list.

Next I'd check Resource Explorer for your Client ID to see if the Policy is applied there.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

ckgsdad's picture

Yes, I verified the target for the policy, client not there, and no the policy is not applied to the client.

I'm stumped, looking thru the executions for the policy I have found 954 (so far) clients that are not part of the policy (filters/targets) that received the policy.

andykn101's picture

Can you see the Policy on your client itself?

Is the GUID on your actual client the same as that shown on the Resource Explorer you are looking at?

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

ckgsdad's picture

My GUID (client side) is the same in the console.

ckgsdad's picture

Sorry, the policy does not show on the client and the client GUID is good.

andykn101's picture

So, if you can't see the Policy on the client itself how do you know it was the Policy that installed the software?

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

ckgsdad's picture

The software was installed on the client late last week, so I dug into the agent logs and saw the execution of the policy. Below is what I pulled, and the GUID for the policy is correct, but not applied to my client (in the filter or policy itself)

 

<event date='Oct 30 00:00:00' severity='4' hostName='UD92068' source='CDeliveryPolicy::IsWakeupDue()' module='smfagent.dll' process='AeXNSAgent.exe' pid='1312' thread='3712' tickCount='900629636' >

  <![CDATA[Checked if policy {D176FAD6-BCF7-4B80-B456-043C95C039F8} for job index 9 is due: 1 ]]>

</event>

<event date='Oct 30 00:00:00' severity='4' hostName='UD92068' source='CDeliveryPolicy::OnWakeup()' module='smfagent.dll' process='AeXNSAgent.exe' pid='1312' thread='3712' tickCount='900629636' >

  <![CDATA[Wakeup called for policy {D176FAD6-BCF7-4B80-B456-043C95C039F8}]]>

</event>

<event date='Oct 30 00:00:00' severity='4' hostName='UD92068' source='CDeliveryPolicy::IsWakeupDue()' module='smfagent.dll' process='AeXNSAgent.exe' pid='1312' thread='3712' tickCount='900629636' >

  <![CDATA[Checked if policy {D176FAD6-BCF7-4B80-B456-043C95C039F8} for job index 9 is due: 1 ]]>

</event>

<event date='Oct 30 00:00:00' severity='4' hostName='UD92068' source='CDeliveryPolicy::RunJobQueue()' module='smfagent.dll' process='AeXNSAgent.exe' pid='1312' thread='3712' tickCount='900629636' >

  <![CDATA[Adding next task from policy USPTO OACS 3.3.1 Pkg2 - Install({D176FAD6-BCF7-4B80-B456-043C95C039F8}) to job queue.  Task trigger: 0f919497-a97c-4f04-b66b-21f6cf220e76]]>

</event>

<event date='Oct 30 00:00:00' severity='4' hostName='UD92068' source='Client Task Agent' module='client task agent.dll' process='AeXNSAgent.exe' pid='1312' thread='3712' tickCount='900629808' >

  <![CDATA[CTaskAgentBase::MergeParamLists()]]>

</event>

<event date='Oct 30 00:00:00' severity='4' hostName='UD92068' source='Client Task Agent' module='client task agent.dll' process='AeXNSAgent.exe' pid='1312' thread='3660' tickCount='900629901' >

  <![CDATA[Task: Execute install command for *** has started]]> (left that blank)

andykn101's picture

Use the Remote Altiris Agent Diagnostics (RAAD) tool to see of you can see any clues with that:

http://www.symantec.com/docs/HOWTO21449

It may be your filter membership went awry at some point.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

ckgsdad's picture

Been down that road too, the filters are all clean, RAAD and the console are not showing the policy applicable to the client, but as you can see from the logs the client received the policy and executed it. It's one of the most bizarre things I've seen to date.

 

Its like we built the filter to use clients abc1-abc100 and the policy shows all 100 but it deployed to abc1-abc500 skipping abc300-abc399 in the process.

andykn101's picture

Check the audit history of the filters, see if anyone was editing them around that time.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Andrew_Shishkov's picture

Hi Steve,

 

Can you give an example of the policy target which included wrong clients?

 

Thanks,

Andrew.

ckgsdad's picture

Andrew, the policy targets the master filter which contains explicit inclusions of sub filters that are created based on requests from management. The sub filters are created by query (range of client id's) or a specific group imported by csv. I have triple checked the filters and they look fine and contain the systems to be targeted. I also searched the policy (changed from targets to computers) and my client wasn't there (like it should be) but like I posted earlier with the logs you can see it got the policy.

Looking at the audit trail shows only the normal changes that we made when adding new systems to the policy. We always have the other techs review the filter creation and policy changes and have not seen any other anamolies and we have 5 other policies built exactly the same way and they aren't having any problems. (Yet) :-)

Andrew_Shishkov's picture

Do you use "exclude computers not in" or "exclude computers in" filter types in the problematic target? Do you use hierarchy in the environment? Is it possible that clients incorrectly included to the policy changed its client ID recently (it could happen for example if Altiris Agent was reinstalled on the client)?

 

Thanks,

Andrew.

 

andykn101's picture

To follow on from Andrew's question, the Symantec recommendation is to make Filters simple and Targets more complex. So you'd use the exclusions in Targets instead of Filters.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

ckgsdad's picture

We're using "Exclude Computers Not In - Filter" for the policy and point to the master filter which contains the correct number of clients. We have not re-installed any clients that I know of, and especially not a mass re-installation that would cover the 950+ clients that are improperly getting the policy. As of this morning the ranges of clients and number are still spot on for what we had set up, there's been no change or fluxuation in the target.

Andy, I agree with what you said, and we try to keep our filters as simple and clean as possible. We create a sub-filter for each new deployment and add it to a master filter until we know we're 100% complete with it, this has proven to be the easiest way to keep tabs on what gets done and what doesn't. With that our policy says to look at nothing outside of the master filter and up until this policy we have not had any problems, and again I have 7 other active MSD policies running now that are all built the same exact way and none of them are having this problem.

andykn101's picture

If it's only happened to the one policy I'd look at an execution report for the machines not supposed to be targeted and check when that was.

If they're clustered around the same time I'd definitely suspect finger trouble when adding filters to the master filter. I'd look at what the wrong machines have in common, maybe all computers was included for a while and they all have config update times around the same time.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Andrew_Shishkov's picture

I suspect that there is a problem with the policy target and not on the client side, but finding a root cause unlikely possible on the forum. As I see you have already opened support case for this problem, I think it is the proper way to find a root cause and resolve it.

 

Thanks,

Andrew.

ckgsdad's picture

Thanks Andrew, we have escalated the ticket as the tech assigned has been steadfast in saying that this is a duplicate GUID issue which I know is not the case as we have only 2 currently in the system. I've combed thru the filters on the day that the deployment hit my client (as with the other 950+) as well as the previous day and see no problem with the filter defenition and no changes were made after they were built. I am stumped, but hopefully we'll get it all figured out.