Mac OS X 10.4.10 Agents not deploying Fixlets

(imported topic written by mellis200091)

We have two Macintosh systems that we are using in testing, and have followed the instructions found on support.bigfix.com to install the agents.

When we installed the agents, steps 1-4 worked as the instructions indicated, but step 5 had some differences, and it also indicated that “the installer should install silently.”, but it didn’t.

However, after installing, the computers showed up in our list of computers, and relevant (and correct) data appears with regard to architecture stuff, such as how big the hard drive is, how much memory, etc. Lastly, the agents are reporting back to the server on a regular basis.

The problem is that, when we attempt to send a command, whether it be a fixlet patch, or a task such as a reboot, to either of these Macintosh computers, it appears like the systems are getting the information, but they never do anything. The console always reports back “Not reporting” as the status of the task/fixlet.

Does anyone have any suggestions on how to correct this?

Thanks, and sorry for the long posting.

Mike

(imported comment written by jessewk)

Is the ‘Mac Firewall is Blocking BES Traffic (OS X 10.4)’ or ‘Mac Firewall is Blocking BES Traffic (OS X 10.3)’ Fixlet in BES Support relevant on those machines?

(imported comment written by mellis200091)

No. I specifically checked that the firewalls are not on, and neither of those items are showing up on the console for those computers. I have also verified that there is communication between the server and the agent by sending a refresh from my console (located on my laptop, not on the server). It has been updating that time.

Thanks for helping with this – any other suggestions are greatly appreciated!

(imported comment written by mellis200091)

Here is the summary page for the computer for one of my Macs:

Core Properties

OS Mac OS X 10.4.10

CPU 800 MHz PowerPC G4 7440

DNS Name DT07IMIT019

IP Address 192.168.25.85

Last Reported 4/24/2008 10:27:24 AM

Locked No

Custom Properties

_BESClient_UsageManager_EnableAppUsage not set

_BESClient_UsageManager_EnableAppUsageSummary not set

_BESClient_UsageManager_EnableAppUsageSummaryApps not set

_BESClient_UsageManager_OperatorApps not set

BIOS $0004.45f3

Free Space on System Drive 70428 MB

RAM 1024 MB

Subnet Address 192.168.24.0

Total Size of System Drive 76311 MB

User Name administrator

Web Browser Safari.app 2.0.4

BES Client Relay Status

BES Relay Selection Method Manual

Primary Relay

Secondary Relay

Distance to BES Relay n/a

BES Root Server

Computer Group Memberships

Subscribed Sites

ActionSite (actionsite)

BES Asset Discovery (assetdiscovery)

BES Inventory and License (besinventory)

BES Power Management (bespowermanagement)

BES Support (bessupport)

Enterprise Security (bessecurity)

Patches for AIX (aixpatches)

Patches for HP-UX (hpuxpatches)

Patches for Mac OS X (macpatches)

Patches for RedHat Enterprise Linux (rhelpatches)

Patches for RedHat Linux (redhatpatches)

Patches for Solaris (solarispatches)

Patches for SUSE Linux Enterprise (slepatches)

Updates for Windows Applications (updateswindowsapps)

BES Client Settings

_BESClient_LastShutdown_Reason Stop event detected ***Does this line perhaps have anything to do with the problem? ***

_BESClient_RelaySelect_FailoverRelay

BES Component Versions

BES API Version The operator “key” is not defined.

BES Client Version 6.0.9.56

BES Console Version Not Installed

BES Relay Version Not Installed

BES Server Version The operator “key” is not defined.

BES Relay Status

BES Client’s Parent Relay patch.msad.unctv.org:52311

BES Relay Installed Status Not Installed

BES Relay Selection Method Manual

BES Relay’s Parent Relay n/a (BES Relay Not Installed)

Manual Selection Status Primary and Secondary Relay Not Set

Power Options Information - Windows 2000/XP/2003/Vista and Mac OS 10.4/10.5

Computer Type Workstation

Current Power Scheme Custom

Hibernation N/A

System Standby Never

Turn Off Hard Disks Never

Turn Off Monitor Never

(imported comment written by jessewk)

Hi Mike,

Your fastest path to resolution is probably to give support a call. But here are some questions for you: Was your initial install 6.0 or 7.0? What version of 7.0 are you running? Are you sending multiple action groups by any chance? What happens if you send a blank custom action? Can you take an action, send the client a force refresh, wait for the last report time to update in the console, and then post the log file from the time you took the action to the time the client reported back?

Jesse

(imported comment written by SystemAdmin)

Was there resolution for this issue, because I’m seeing something similar.

Mac OS X 10.4.11

BES 7.0.9.110

The client is reporting and promptly responds to manual refresh.

Errors in the client log show that it’s having issues synchronizing with a specific site (opsite23).

Fixlets show the client is “Not Reporting”.

Activity monitor shows “BESAgent (Not Responding)”.

Any help would be greatly appreciated.

(imported comment written by mellis200091)

Hey Mike,

I opened a support case, and was told that the problem lay with the Effecient MIME. Here are the instructions on what they told me to do, and it fixed it perfectly. The problem lies in the fact that the MAC agent is version 6, whereas my server is version 7. You have to tell the server to work with older agent versions.

Here are the instructions they gave me:

It sounds like you have efficient MIME turned on. Pre 7.0 clients will do this with efficient MIME turned on, as the Mac OS client is Pre 7.0 it has to be turned off. To do this go to the “Advanced Options” tab in the BESAdmin utility, select the option usePre70ClientCompatibleMIME, select the Edit button, and set the value to true. Then click OK and then OK to exit BESAdmin. This should fix your issue.

Hope this helps!

Mike

(imported comment written by SystemAdmin)

Thanks for the reply.

We may have a different issue, as we already have usePre70ClientCompatibleMIME set as True.

(imported comment written by jessewk)

Did you have ‘usePre70ClientCompatibleMIME’ set to true before you took the actions? You’ll need to reissue any actions after the change has been made for the Mac clients to take them.

(imported comment written by SystemAdmin)

usePre70ClientCompatibleMIME was set as True prior to these actions taking place.

I resolved the opsite issue, and the logs look clean.

Gathering looks good, and the device shows up in the “Computer” list and actively reports.

The device only shows as when attempting to deploy a fixlet.

Activity Monitor still shows BESAgent as (Not Responding) and statistics shows an ever growing Fault count.

(imported comment written by jessewk)

Hi Mike,

That still sounds pretty strange. Have you contacted support at all? It looks like this will take more extensive investigation than I can provide via the forum.

Also, it’s “normal” for the agent to show not responding in the Activity Monitor. This issue is fixed in upcoming versions.

Jese

(imported comment written by SystemAdmin)

Thanks. We haven’t moved forward with a full Mac deployment, so resolution wasn’t urgent. I’ll call support to see if they can provide me with a solution. I’ll post a follow-up, in case someone else is experiencing a similar issue.

(imported comment written by SystemAdmin)

Resolution:

usePre70ClientCompatibleMIME was set to “True” with an upper-case T.

When we set it to “true” with a lower-case T, and issued new fixlets, deployment was successful.

(imported comment written by jessewk)

Sorry about that Mike.

I’ve filed a bug to make the setting case insensitive.

Jesse