Has anyone else noticed in their environments MacOS agents losing some or all of their client settings? We use client settings extensively for inventory tagging and distributed management, so they’re very important to us. We currently see almost 10% of our MacOS agents in this state (thousands of systems). I’d like to see how widespread this issue is. Anyone else seeing this happen?
1 Like
This has been happening in my org to Macs running 10.10 and above for several months now. Some problem clients are running 9.5.7 and others are running 9.5.9.
1 Like
I have long noticed Mac clients lacking relay affiliation settings. I’ve never tracked it enough to determine if they had them and then lost them. They tend to appear in units that are probably using older installer packages that might not have the settings I’d later baked into the clientsetttings.cfg. Or, they have older clientsettings.cfg that I later replaced with a more barebones file and relevance/actions to control settings.
Possibly related, I’ve had cases (mostly Windows, a couple Mac) where the client gets seemingly wedged — it checks in and shows as online, but doesn’t process actions. The only solution I’ve found is to forcibly remove the client and all data (e.g. BESRemove.exe) and reinstall. These cases seem to be rooted in horked disk permissions on the client.
- Do you know how settings are generally configured for the Macs / others?
- Do you primarily use
clientsettings.cfgto set initial settings? - Are you using actions / policy actions to set some settings generally?
- Are you using Defaults Write or something similar on the command line to configure settings before or after BigFix is installed?
- Is there anything that would trigger client settings changes occasionally?
I’m trying to understand what could cause this issue. I’m also curious what the permissions generally are for the plist file: /Library/Preferences/com.bigfix.BESAgent.plist
- What are the permissions set to when they are good?
- What are they set to when they are not?
Command Line example:
Command: ls -l /Library/Preferences/com.bigfix.BESAgent.plist
Output: -rw-r--r-- 1 root wheel 4829 May 17 17:54 /Library/Preferences/com.bigfix.BESAgent.plist
A GUI example:
I don’t actually know if these are correct, but they seem to be and are what is on one of my systems.
It would also be interesting to know the contents of the plist before and after they lose settings if possible, as well as the modification time of it.
If the settings are still in the file, even though they aren’t being reflected in the console, then I wonder what happens if you defaults write one of the settings that already exists to write it back again.
It would also be interesting to know if the plists are in binary or xml format before and after losing settings.
Some settings are configured at install time. Others via actions, later. At install time, I believe that our installer wrapper customizes clientsettings.cfg to set them. I don’t believe that we use defaults write to set settings manually as a general practice.
Mac filesystem object inspectors don’t appear to read Unix permissions, so this is harder to answer remotely via Fast Query. Will try to get my hands on one to see.
Under instruction from Support, I’m trying to gather client diagnostics from systems before and after the failure mode, so hopefully I’ll be able to answer this before too long. My Archive Manager functionality isn’t working well, but maybe we’ll get that resolved such that I can collect a large enough population of “before” client diagnostics to end up with a before and after.
Quick playing via Fast Query indicates that on the good and bad systems the files are binary.
1 Like
This is still happening to several computers every week, despite running 9.5.9. Anyone having any luck with solutions to this?
I’m still trying (at IBM Support’s request) to capture diagnostic data from an endpoint BEFORE and AFTER it loses all its client settings. Unfortunately, we have other trouble with our relay/root server infrastructure that’s preventing bulk gathers via archive manager from working, so we’re troubleshooting that first. But this is indeed still happening to us and we’ve made little progress on identifying root causes.
Looks like we currently have ~25 Macs which exhibit this problem. I can identify them because they’ve chucked the ‘ownership’ client setting that we use to assign them into different customer buckets. This tag is embedded in clientsettings.cfg file using during client installation. (The setting is occasionally assigned or changed post-bootstrap, but that is rare.)
All are on client 9.5.8; nearly all are running macOS 10.13.x. One I had reimaged personally, less than six weeks ago.
We too are seeing this behavior…
The Computer Group Membership in the Summary is fine yet the Client has lost a setting (Dept_ID=COB) and also has reverted to Manual relay selection when it was set to automatic. Infact, it seems to have lost a boat load of settings like the cache size etc…
Any progress with this ?
Yes, we are still seeing this issue, although it seems to have gotten better since we discovered in the BigFix Slack that it mostly/entirely happens to settings which do not have effective dates, meaning that they were set in the clientsettings.cfg file at time of install.
I haven’t had any computers in my test group lose settings since I pushed effective dates to their client settings, but I don’t know if that’s because I got lucky or it fixes the problem. @jtavan said that it didn’t fix the problem for him.
That’s correct… I have a policy action in place setting effective dates for all machines missing them, and still seeing a dozen machines a day losing client settings. Still trying to work through it with support.
I hate to “me too” and bring up an oldish thread, but we’ve been seeing this for a while as well. When it happens the client seems to do a full reset of all client settings except for computerID, at least on the last one I found. I have a set of custom client settings that are set on install using clientsettings.cfg, but also have a policy action running that creates blank ones if the client settings are ever “missing” like from a rogue installer. Theoretically this policy should barely touch any systems at all, but when I look at it’s history, there are a ton of Macs in there…
I wasn’t aware of the missing effective date thing, I’ll have to look into that one…
And yes, we’re still attempting to work this through with a ticket with IBM…
Anyone else still seeing this?
1 Like
Ys we are Still seeing this…
Typicallly I have a property that identifies the department the machine belongs to… Ideal for use with non domain joined machines…
The filter is an Automatic group based on this property.
The property is set in the clientsettings.cfg or manually editing the computer settings and applying the property with a value.
This also applies to things like, precache size, command poll enable and number of seconds set to poll (10840 or 7200)
So when the computer settings go blank, I can still see on the summary tab that the Computer Group memberships remain correct, but the acual reported settings in " edit computer settings" is totally missing along with all the other details like command poll enable and relay select etc.
This is a big problem because that propery going missing meant the computer becomes orphaned from its department , not visible in any console except the master console.
Re-applying the settings works for a while but they soon revert and loose everthing again… This is only happening on Macs… Less so on macs that are domain joined.
We are still seeing this as well, and have thousands of computers in this state. I’m building some content now to pull data from our Splunk records of historical settings values and restore them to those machines where I can find appropriate previous values.
Still happening for us too.
Still here too, but less often now that I have a policy action that applies dates to client settings.
Ok… I have just had it happen… I have been working on a mac which is Bound to a AD. It had a nice client setting combination to include the usual dept ident, the Command poll enable, number of seconds, Power tracking and a host of other settings.
I was waiting for 3 actions to finish and the machine dissapeared from the actions (The only computer that the actions were targeted against)
The Actions remained. A few seconds later, the Computer re-appears in Computers , and in the actions as the only target BUT all the Client settings had gone except for the “defaults” as pictured.
This is VERY strange…
Ok… Caught the Logs… Nothing untowards in the BESRelay.log BUT here is the client logs…
At 14:34:06 -0500 - mailboxsite (http://pm-prod-01.cc.vt.edu:52699/cgi-bin/bfgather.exe/mailboxsite11306117)
Not Relevant - Deploy Pulse Secure 9.0.3.0-b1599 VPN Client for Mac (Optimized for Mojave) (fixlet:2380499)
At 14:34:08 -0500 -
Encrypted Report posted successfully
At 14:34:15 -0500 -
ActionLogMessage: (action:2113932309) Action signature verified for Execution
ActionLogMessage: (action:2113932309) starting action
At 14:34:15 -0500 - BES Inventory and License (http://sync.bigfix.com/cgi-bin/bfgather/besinventory)
Deleted - Install or Upgrade Scanner (fixlet:1)
Deleted - Hardware Information (Mac OS X) (fixlet:44)
Deleted - Network Information (Mac OS X) (fixlet:45)
Deleted - (Deprecated) Physical / Virtual Computer Type Analysis (fixlet:55)
Deleted - Operating System Information (Mac OS X) (fixlet:308)
Deleted - Application Information (Mac OS X) (fixlet:318)
Deleted - Scanner Information (fixlet:37)
Unsubscribed from FixSite and delete fixlets.
At 14:34:20 -0500 -
ActionLogMessage: (action:2113932309) ending action
At 14:34:20 -0500 - actionsite (http://server:52699/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Unsubscribe from Site http://sync.bigfix.com/cgi-bin/bfgather/besinventory (fixlet:2113932309)
At 14:34:20 -0500 -
ActionLogMessage: (action:2113937318) Action signature verified for Execution
ActionLogMessage: (action:2113937318) starting action
At 14:34:20 -0500 - Power Management (http://sync.bigfix.com/cgi-bin/bfgather/powermanagement)
Deleted - Enable Client Dashboard (fixlet:4)
Deleted - Set “Default” Cost Assumptions (fixlet:56)
Deleted - Power off Computers (fixlet:9)
Deleted - Restart Computers (fixlet:10)
Deleted - Enable All Input Devices to Allow Wake from Standby - Windows (fixlet:35)
Deleted - Remove Wake-on-LAN Forwarders (fixlet:46)
Deleted - Disable Wake-from-Standby by Magic Packet - Windows and Mac OS (fixlet:55)
Deleted - Power Consumption Analysis (fixlet:2)
Deleted - Reset Power Tracking (fixlet:16)
Deleted - Disable Power Tracking (fixlet:61)
Deleted - Configure Power Tracking Default Settings (fixlet:66)
Deleted - Designate Last Man Standing (fixlet:47)
Deleted - BigFix Wake-on-LAN Analysis (fixlet:45)
Unsubscribed from FixSite and delete fixlets.
At 14:34:22 -0500 -
ActionLogMessage: (action:2113937318) ending action
At 14:34:22 -0500 - actionsite (http://server:52699/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Unsubscribe from Site http://sync.bigfix.com/cgi-bin/bfgather/powermanagement (fixlet:2113937318)
At 14:34:23 -0500 -
ActionLogMessage: (action:2113937326) Action signature verified for Execution
ActionLogMessage: (action:2113937326) starting action
At 14:34:23 -0500 - Tivoli Remote Control (http://sync.bigfix.com/cgi-bin/bfgather/tivoliremotecontrol)
Deleted - Uninstall IBM BigFix Remote Control Controller for macOS (fixlet:93)
Deleted - Uninstall IBM BigFix Remote Control Target for macOS (fixlet:95)
Deleted - Remote Control Controller Logs (fixlet:6)
Deleted - Remote Control Target Logs (fixlet:20)
Deleted - IBM BigFix Remote Control Controller - Installed versions (fixlet:83)
Deleted - IBM BigFix Remote Control Target - Installed versions (fixlet:85)
Unsubscribed from FixSite and delete fixlets.
At 14:34:23 -0500 -
ActionLogMessage: (action:2113937326) ending action
At 14:34:23 -0500 - actionsite (http://Server:52699/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Unsubscribe from Site http://sync.bigfix.com/cgi-bin/bfgather/tivoliremotecontrol (fixlet:2113937326)
At 14:34:24 -0500 -
ActionLogMessage: (action:2113937582) Action signature verified for Execution
ActionLogMessage: (action:2113937582) starting action
At 14:34:24 -0500 - Server Automation (http://sync.bigfix.com/cgi-bin/bfgather/serverautomation)
Deleted - Sample Baseline With Notification Fixlets included (fixlet:997)
Deleted - Restart Endpoint (fixlet:94)
Deleted - Restart Endpoint and Wait for Restart to Complete (fixlet:126)
Deleted - Dynamically Run Baselines from a Site (fixlet:137)
Deleted - Restart Endpoint on Pending Restart and Wait for Restart to Complete (fixlet:160)
Unsubscribed from FixSite and delete fixlets.
At 14:34:24 -0500 -
ActionLogMessage: (action:2113937582) ending action
At 14:34:24 -0500 - actionsite (http://Server:52699/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Unsubscribe from Site http://sync.bigfix.com/cgi-bin/bfgather/serverautomation (fixlet:2113937582)
At 14:34:24 -0500 -
ActionLogMessage: (action:2113938404) Action signature verified for Execution
ActionLogMessage: (action:2113938404) starting action
At 14:34:25 -0500 - Software Distribution (http://sync.bigfix.com/cgi-bin/bfgather/softwaredistribution)
Deleted - Generate a PIN for Self Service Portal Registration (fixlet:20)
Deleted - Deploy IBM BigFix Self-Service Application (Mac OS X) (fixlet:303)
Deleted - Active Directory Security Groups and Organizational Units (fixlet:8)
Deleted - Software Distribution Deployment Results (fixlet:11)
Deleted - Software Distribution Self Service Portal (fixlet:19)
Unsubscribed from FixSite and delete fixlets.
At 14:34:26 -0500 -
ActionLogMessage: (action:2113938404) ending action
At 14:34:26 -0500 - actionsite (http://server:52699/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Unsubscribe from Site http://sync.bigfix.com/cgi-bin/bfgather/softwaredistribution (fixlet:2113938404)
At 14:34:26 -0500 -
ActionLogMessage: (action:2113938558) Action signature verified for Execution
ActionLogMessage: (action:2113938558) starting action
At 14:34:26 -0500 - Client Manager Builder (http://sync.bigfix.com/cgi-bin/bfgather/clientmanagerbuilder)
Unsubscribed from FixSite and delete fixlets.
At 14:34:26 -0500 -
ActionLogMessage: (action:2113938558) ending action
At 14:34:26 -0500 - actionsite (http://server:52699/cgi-bin/bfgather.exe/actionsite)
Not Relevant - Unsubscribe from Site http://sync.bigfix.com/cgi-bin/bfgather/clientmanagerbuilder (fixlet:2113938558)
At 14:34:45 -0500 - CustomSite_BFME_Apple (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_Apple)
Relevant - BES Client Info - Mac (fixlet:982520)
Relevant - Local Admin/User Audit - Apple (fixlet:982519)
Relevant - write System Profiler info - Mac (fixlet:982518)
Relevant - Install/Update Bluetooth Explorer 4.4.0 - Mac (fixlet:982516)
At 14:34:46 -0500 - CustomSite_BFME_Apple (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_Apple)
Relevant - Remove Dock Item - Maps - dockutil - Mac (fixlet:1838534)
Relevant - Remove Dock Item - Siri - dockutil - Mac (fixlet:1838533)
Relevant - Remove Dock Item - iBooks - dockutil - Mac (fixlet:1838532)
Relevant - Remove Dock Item - iTunes - dockutil - Mac (fixlet:1838531)
At 14:34:47 -0500 - CustomSite_BFME_Apple (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_Apple)
Relevant - Remove Dock Item - Mail - dockutil - Mac (fixlet:1838529)
At 14:34:48 -0500 - CustomSite_BFME_Apple (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_Apple)
Relevant - Remove Dock Item - FaceTime - dockutil - Mac (fixlet:1838528)
Relevant - Remove Dock Item - Contacts - dockutil - Mac (fixlet:1838527)
Relevant - Remove Dock Item - Messages - dockutil - Mac (fixlet:1838526)
Relevant - Remove Dock Item - Reminders - dockutil - Mac (fixlet:1838525)
Relevant - Remove Dock Item - Safari - dockutil - Mac (fixlet:1838524)
At 14:34:49 -0500 - CustomSite_BFME_Apple (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_Apple)
Relevant - Remove Dock Item - Notes - dockutil - Mac (fixlet:1838523)
Relevant - Remove Dock Item - Calendar - dockutil - Mac (fixlet:1838521)
Relevant - Change ScreenSharing (VNC) Password - Mac - BETA (fixlet:1680099)
At 14:34:50 -0500 - CustomSite_BFME_Apple (server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_Apple)
Relevant - Set Root Password to resolve vuln in High Sierra - Apple Mac OS X (fixlet:1559392)
Relevant - Set Root Password to resolve vuln in High Sierra - Apple Mac OS X TODO:testing! (fixlet:1557269)
Relevant - write System Profiler info - Mac (fixlet:1038341)
At 14:34:50 -0500 - CustomSite_BFME_C3_Inventory (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_C3_Inventory)
Relevant - Invoke - Configuration Profiles Probe - Mac (fixlet:992483)
Relevant - Operating System - Mac (fixlet:983662)
Relevant - Login Window - Mac (fixlet:983661)
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983659.fxf
At 14:34:53 -0500 - CustomSite_BFME_C3_Inventory (http://server:52699/cgi-bin/bfgather.exe/CustomSite_BFME_C3_Inventory)
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983658.fxf
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983657.fxf
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983656.fxf
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983655.fxf
Relevant - Volumes - Universal (fixlet:983654)
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983653.fxf
BackgroundAdviceEvaluation::FinishDataLoop side line file Fixlet 983652.fxf
At 14:34:53 -0500 -
GatherHashMV command received.
At 14:35:06 -0500 - mailboxsite (http://server:52699/cgi-bin/bfgather.exe/mailboxsite11306117)
Downloaded ‘http://relay8:52699/mailbox/files/8a/8f/8a8fe9dea5200d14fbabebff00f82a97c54cd979’ as 'Action 2380522.fxf’
Gather::SyncSiteByFile adding files - count: 1
Why did it basically unregister from nearlt all the sites and then re-register?
1 Like
Do you have logs starting from a few minutes before? This looks like everything that happens after a client reset, I’d like to see what was happening before and during.
Sure Jason… I wont post them here as there is too much obfuscation to be done.