How does the Tickle Agent task work and how can we troubleshoot this in SMP?
search cancel

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

book

Article ID: 180745

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

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.

Environment

ITMS 8.x

Resolution

Process Flow of the Task:

The task chooses an agent (up to 30) on the same subnet as the target computer, sends 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: ######
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: ######
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~........######.R…´q½°ÑG†.Ï.ôRº—0.0.-.0.C.-.2.9.-.F.5.-.2.2.-.3.2.

In case agents on the same subnet have received the packet (please note that Tickle functionality needs to be enabled in the client policies!), they will broadcast a 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='ABCD123' 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 should 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 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 (e.g. 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.