Well as mentioned 70 clients are being listed as managed by SACM but only 34 ish are receving commands with the rest not showing as pending or erroring..

Going through the SMacClientErr.log found in /Library/Application Support/Symantec/SMac/ on the macs that are not receiving commands reveals various error messages,these are:

Status Report err = -10
ReportStatus.php error : -10
Status Report err = -51
ReportStatus.php error : -51
Status Report err = -18007
Status Report err = -18006
HTTP error -18006, on status post

Also on some clients the logs are near 9GB in size. Is there anyway of restricting the log length?

After doing some digging on the SQL DB that is the backend of SACM shows that the clients that are not updating are not receiving the correct ‘command sequence id’ as per the clients that do update.

So I can see that they are not receiving commands, the issue is really why aren’t they receiving the commands & even though we uninstall & reinstall the client why are they not working???

Thanks.

The HTTPD access_log is filled with:

10.44.62.34 [09/Apr/2008:17:44:49 +0100] “POST /sacm/ReportStatus.php HTTP/1.1” 200 3

10.44.48.20 [09/Apr/2008:17:43:45 +0100] “POST /sacm/ReportStatus.php HTTP/1.1” 200 4

Any ideas as to what they might mean??

Oh & we cannot remove the AV due to our company policy.

We know the Macs are updating as they have been set to do it at 14:00 everyday, it’s just that our reporting tool is broken for some & not others…..

Actually we’re on PHP 4.4.8.

Will the commands be different?

khiltd thanks for your help, but I think the issues lie elsewhere.. here is what I have found & am posting incase someone else finds this useful.

[b]Client – Server relationship[/b]

[i]A command that you issue from the administration console passes through to the Apache HTTP Web server. The server stores information about the new command in the appropriate database tables and instructs the command server to issue the command to the UDP multicast address that was set when Symantec Administration Console for Macintosh was installed. The command broadcasts through one or more routers to individual clients and client groups registered with the UDP address. – taken from the admin manual[/i]

The client runs as a process called SMac, (for Symantec Antivirus 10.1 this runs from a users Startup Items, from 10.2 this runs as a launchd process).

After installing Symantec Antivirus install the SMacCleint.pkg found in /Library/Application Support/Symantec/SMac/ on the server running the Symantec Administration Client for Macintosh (SACM).

To create the client login to SACM & click on Maintenance > Create Client Package.

This client should have all the settings (IP Address, Multicast Address, Port etc..) for your server as well as the current Private & Public Keys.

Once installed on a client Mac & themac has been restarted or logged out/in you should see the SMac process under activity monitor. If you do open Terminal & type in netstat then hit return.

This will give you all the current tcp, udp & other open connections. You will need to look for something along the lines of;

udp4 0 0 *.8192 *.* (or whatever multicast port you chose).

&

/tmp/.com.symantec.smacs.events.toserver

If these are fine on both server & client then the Mac [i]should[/i] appear on the SACM in a day or to (maybe sooner).

On successful communication with the server the client will be assigned a NodeID which will be written to /Library/Preferences/com.symantec.SMacClient.plist

If you have added the client to an image & rebooted into the image BEFORE distributing it you will need to run the following;

sudo defaults write /Library/Preferences/com.symantec.SMacClient NodeID 0

So that after your image has been deployed it will re-register the client with the server.

[b]So it works then?[/b]

Err.. not for me.. not yet anyways,I have done the last step after removing some 30 unresponsive clients from SACM & 3 have come back. Time will tell & hopefully will Symantec if they ever get back to me!!

[b]Client Errors[/b]

On another note I found these after opening the client package installer in the Bootstrap.php file;

define(‘kSMErr_InvalNodeID’, -1); # malformed kSMSK_NodeID/kSMEK_NodeID param
define(‘kSMErr_UnknownNodeID’, -2); # kSMSK_NodeID/kSMEK_NodeID value not in database
define(‘kSMErr_InvalTimeSent’, -3); # malformed kSMSK_TimeSent/kSMEK_TimeSent param
define(‘kSMErr_InvalIPAddr’, -4); # malformed kSMSK_IPAddr param
define(‘kSMErr_InvalCmdStat’, -5); # kSMSK_CommandsStat param not mult of 3 values
define(‘kSMErr_InvalCmdID’, -6); # kSMSK_CommandsStat has malformed command ID
define(‘kSMErr_UnknownCmdID’, -7); # kSMSK_CommandsStat has unknown command ID
define(‘kSMErr_InvalCmdResult’, -8); # kSMSK_CommandsStat has malformed command result
define(‘kSMErr_InvalCmdTime’, -9); # kSMSK_CommandsStat has malformed command time
define(‘kSMErr_InvalSoftware’, -10); # kSMSK_SoftwareVers param not mult of 2 values
define(‘kSMErr_InvalSoftName’, -11); # kSMSK_SoftwareVers/kSMEK_SoftwareName has malformed software name
define(‘kSMErr_InvalSoftVers’, -12); # kSMSK_SoftwareVers/kSMEK_SoftwareVersion has malformed software vers
define(‘kSMErr_InvalEvtTime’, -13); # kSMEK_EventTime has malformed event time
define(‘kSMErr_InvalEvent’, -14); # kSMEK_Event has malformed event

define(‘kSMErr_DBConnect’, -21); # unable to connect to database
define(‘kSMErr_DBQuery’, -22); # misc error with database

define(‘kSMErr_InvalKeyID’, -31); # malformed public key ID
define(‘kSMErr_UnknownKeyID’, -32); # a public key was requested but ID unknown

define(‘kSMErr_InvalBootstrap’, -41); # missing or bad info in bootstrap attempt

define(‘kSMErr_InvalOsID’, -51); # missing or bad info for OsVersion in bootstrap attempt

Not that they make any odds!!

Cheers for that!

As a company we pay for a certain level of support. Therefore we cannot justify the cost of a PHP engineer to troubleshoot an issue bought from & supported by Symantec.

Anyways, the post requests on the server are correct. It is just that for some reason these macs SMacClients are checking for updates/new commands every 3 seconds instead of every 300 seconds.

Also error -51 points to any error in that whilst it is presented in PHP is actually in reference to a Ruby file that runs the terminal command sys_ver & logs it. At this point I realised I was going into the guts of the application to resolve an issue that we have paid support for.

As this is just for the reporting I wrote some UNIX scripts that we can send out via ARD. I will post these once I have verified that they are indeed working over on extended period.