How does the Tickle Agent task work and how can we troubleshoot this in SMP v7.x?

Article:HOWTO60829  |  Created: 2011-11-11  |  Updated: 2011-11-11  |  Article URL http://www.symantec.com/docs/HOWTO60829
Article Type
How To



Conceptually, the Tickle Agent task relies on a setting in the targeted agent settings that enables clients on the same subnet to act as a proxy for the need to wake up other clients.  As a proxy, they send out the broadcast packet that is required to wake the other agent.  This is essentially the same as the legacy methodology used in version 6.x of Notification server, and it is still working in current builds of SMP including 7.1 SP1.

Process Flow of the Task:

The task chooses an agent (up to 30) on the same subnet as the target computer, send a packet to that computer, and that computer then sends the actual WOL broadcast on its own subnet.

If the task is completed successfully on the server side, you should see the following messages in the server log:

Priority: 4
Date: 11/9/2011 4:19:01 PM
Tick Count: 7555187
Host Name: MHWIN2008NS
Process: AtrsHost (1416)
Thread ID: 70
Module: AtrsHost.exe
Source: Altiris.TaskManagement.ClientTask.*
Description: Starting Task Instance Run Tickle Client on Schedule (6ef75fd1-2c64-4a0f-9cba-b80e3245cddd) from Task Tickle Client (928af47c-2d98-4e30-9b4d-de16f88ad4a7)
Priority: 4
Date: 11/9/2011 4:19:01 PM
Tick Count: 7555328
Host Name: MHWIN2008NS
Process: AeXSvc (1148)
Thread ID: 121
Module: AeXSVC.exe
Source: Power Manager
Description: Power Manager: Success performing a WOL operation with the following details :- Subnet:10.31.8.0, Relay:10.31.15.106, Commands:1, Target MAC:00-0C-29-F5-22-32

 

The following sample TCP packet should be sent to the clients selected as WOL proxies (please note that the MAC address is for the client being waked up):

00 0C 29 BD 84 D1 00 0C 29 CF FA C9 08 00 45 00 00 73 6D BE 40 00 80 06 59 7E 0A 1F 0F A1 0A 1F 0F 6A 08 7F CB 36 52 52 61 7B C8 18 CF 3F 50 18 01 00 EA 18 00 00 41 65 58 31 7E 02 00 00 02 00 00 00 00 4D 48 57 49 4E 32 30 30 38 4E 53 00 52 85 B4 71 BD B0 D1 47 86 1A CF 1D F4 52 BA 97 30 00 30 00 2D 00 30 00 43 00 2D 00 32 00 39 00 2D 00 46 00 35 00 2D 00 32 00 32 00 2D 00 33 00 32 00
..)½„Ñ..)ÏúÉ..E..sm¾@.€.Y~...¡...j.Ë6RRa{È.Ï?P...ê...AeX1~........MHWIN2008NS.R…´q½°ÑG†.Ï.ôRº—0.0.-.0.C.-.2.9.-.F.5.-.2.2.-.3.2.

In case agents on the same subnet has received the packet (please note that Tickle functionality needs to be enabled in the client policies!), they will broadcast magic UDP packet to the local subnet and the following message should appear in the client log:

<event date='Nov 09 16:15:04' severity='4' hostName='MHWIN2008A0' source='NetworkSender::SendWOL' module='AeXNetComms.dll' process='AeXNSAgent.exe' pid='1364' thread='992' tickCount='7858781' >
<![CDATA[WOL packet sent to: 00:0c:29:f5:22:32]]>
</event>

The following limited broadcast UDP packet ushould be sent:

FF FF FF FF FF FF
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32
00 0C 29 F5 22 32

Troubleshooting Synopsis:

To start with, check the logs on first the server to be sure the task was sent, and then on the potential clients on the remote subnet to see if they received the task.  Finally, you may need to use a sniffer (eg Wireshark) to determine if the correct packets are being sent, or received, at least on the local segment.  If the broadcast UDP packet is sent, then the troubleshooting continues on that client system to see why it's not responding.
 



Article URL http://www.symantec.com/docs/HOWTO60829


Terms of use for this information are found in Legal Notices