Jamf files on my harddrives but I don't use Jamf

[pr]

I'm managing a couple of Macs. They don't use any Jamf software at all.
But when I look in the root of the harddrive, I see the following files:

Jamf install certificate.sch
Jamf install certificate.sch.lgf
Update Scheduler.sch
Update Scheduler.sch.lgf

The Jamf install certificate.sch file is recreated every minute. The other files multiple times per day.

I've checked the LaunchAgents and LanchDeamons folders, but don't see any Jamf related files. Nor do I see any Jamf related processes in Activity Monitor.

Are these really files from Jamf? And how can I determine what process is creating them?

Any help would be greatly appreciated.

(As I don't know where to post this I selected the first board in the list)

[bradtchapman]

Where did you get these Macs from?  Did your institution purchase them new, or were they acquired second-hand?

And... out of curiosity, do you know if you are using software from SAP on that Mac?

[pr]

These are Macs we purchased new. Have always been managed by my and users don't have admin rights. We don't use SAP.

[junjishimazaki]

Hi pr, there are a few places you can look at. I would start at the Console log app. Either look in the log report to see if there is a jamf.log file or in the System log. Also, to see if the Jamf binary is really running, in terminal type sudo jamf checkJSSConnection

That command will tell you if the jamf binary is connecting and it will display which Jamf instance it may be pointing to.

If I may ask, what made you look in the hard drive to begin with?

[pr]

There is no jamf executable available on these Macs so I can't execute that command. There is also no jamf.log file available.

As these files are in the root of the hard drive, they just showed up immediately when I opened it. I don't expect these kind of files there, so immediately I'm wondering what's going on.

[pr]

There are no Jamf products installed on these Macs. That's the weird thing. So the result from your command is this:

MHR03:~ mac$ sudo jamf checkJSSConnection
Password:
sudo: jamf: command not found
MHR03:~ mac$ 

Yet I see these files:

MHR03:~ mac$ ls -lart /*sch*
-rw-r--r--  1 root  wheel  613 27 dec 16:59 /Update Scheduler.sch.lgf
-rw-r--r--  1 root  wheel  613 27 dec 16:59 /Update Scheduler.sch
-rw-r--r--  1 root  wheel  643 27 dec 17:32 /Jamf install certificate.sch.lgf
-rw-r--r--  1 root  wheel  643 27 dec 17:32 /Jamf install certificate.sch
MHR03:~ mac$ 

And here is the content of one of these files:

MHR03:~ mac$ cat /Jamf\ install\ certificate.sch
{
	"Jamf install certificate task" : 
	{
		"repetitive" : 
		{
			"Jamf certificate Trigger" : 
			{
				"settings" : 
				{
					"endDate" : 0,
					"maxFireCount" : 0,
					"repeatInterval" : 30,
					"startDate" : 1640259677,
					"timezone" : ""
				},
				"statistics" : 
				{
					"fireCount" : 7796,
					"lastFireTime" : 1640626427
				}
			}
		},
		"settings" : 
		{
			"allowConcurentExecution" : true,
			"recoveryInterval" : 0,
			"recoveryMode" : 1
		},
		"statistics" : 
		{
			"lastDuration" : 0,
			"lastRunTime" : 1640622827,
			"lastRunTimeSuccess" : 1640622827,
			"runCount" : 26297,
			"runCountSuccess" : 26297
		}
	}
}
MHR03:~ mac$ 

[alexjdale]

Hmm, a little poking around leads me to my best guess of something involving SuperCard (the .sch files) and they are outputting log files when executed.  But I have no idea what is putting them there or running them.  It could be a launchdaemon/agent with a name that is unrelated to Jamf.

It's an interesting puzzle.  Are the files in text format and readable?  They probably contain clues.

[pr]

Yes, these files are readable. Here's the content of them:

MHR03:~ mac$ cat /Jamf\ install\ certificate.sch
{
	"Jamf install certificate task" : 
	{
		"repetitive" : 
		{
			"Jamf certificate Trigger" : 
			{
				"settings" : 
				{
					"endDate" : 0,
					"maxFireCount" : 0,
					"repeatInterval" : 30,
					"startDate" : 1640259677,
					"timezone" : ""
				},
				"statistics" : 
				{
					"fireCount" : 9492,
					"lastFireTime" : 1640677307
				}
			}
		},
		"settings" : 
		{
			"allowConcurentExecution" : true,
			"recoveryInterval" : 0,
			"recoveryMode" : 1
		},
		"statistics" : 
		{
			"lastDuration" : 0,
			"lastRunTime" : 1640673707,
			"lastRunTimeSuccess" : 1640673707,
			"runCount" : 27993,
			"runCountSuccess" : 27993
		}
	}
}
MHR03:~ mac$ cat /Jamf\ install\ certificate.sch.lgf 
{
	"Jamf install certificate task" : 
	{
		"repetitive" : 
		{
			"Jamf certificate Trigger" : 
			{
				"settings" : 
				{
					"endDate" : 0,
					"maxFireCount" : 0,
					"repeatInterval" : 30,
					"startDate" : 1640259677,
					"timezone" : ""
				},
				"statistics" : 
				{
					"fireCount" : 9492,
					"lastFireTime" : 1640677307
				}
			}
		},
		"settings" : 
		{
			"allowConcurentExecution" : true,
			"recoveryInterval" : 0,
			"recoveryMode" : 1
		},
		"statistics" : 
		{
			"lastDuration" : 0,
			"lastRunTime" : 1640673677,
			"lastRunTimeSuccess" : 1640673677,
			"runCount" : 27992,
			"runCountSuccess" : 27992
		}
	}
}
MHR03:~ mac$ cat /Update\ Scheduler.sch
{
	"Update task" : 
	{
		"repetitive" : 
		{
			"Update Trigger" : 
			{
				"settings" : 
				{
					"endDate" : 0,
					"maxFireCount" : 0,
					"repeatInterval" : 3600,
					"startDate" : 1640260788,
					"timezone" : ""
				},
				"statistics" : 
				{
					"fireCount" : 79,
					"lastFireTime" : 1640674788
				}
			}
		},
		"settings" : 
		{
			"allowConcurentExecution" : true,
			"recoveryInterval" : 0,
			"recoveryMode" : 1
		},
		"statistics" : 
		{
			"lastDuration" : 0,
			"lastRunTime" : 1640671188,
			"lastRunTimeSuccess" : 1640671188,
			"runCount" : 4187,
			"runCountSuccess" : 4187
		}
	}
}
MHR03:~ mac$ cat /Update\ Scheduler.sch.lgf 
{
	"Update task" : 
	{
		"repetitive" : 
		{
			"Update Trigger" : 
			{
				"settings" : 
				{
					"endDate" : 0,
					"maxFireCount" : 0,
					"repeatInterval" : 3600,
					"startDate" : 1640260788,
					"timezone" : ""
				},
				"statistics" : 
				{
					"fireCount" : 79,
					"lastFireTime" : 1640674788
				}
			}
		},
		"settings" : 
		{
			"allowConcurentExecution" : true,
			"recoveryInterval" : 0,
			"recoveryMode" : 1
		},
		"statistics" : 
		{
			"lastDuration" : 0,
			"lastRunTime" : 1640667588,
			"lastRunTimeSuccess" : 1640667588,
			"runCount" : 4186,
			"runCountSuccess" : 4186
		}
	}
}
MHR03:~ mac$ 

[bradtchapman]

The mystery deepens.  These files don't appear to contain any "instructions" i.e. a script, or any call to an external script, but are just full of schedules and parameters.  It's almost like some other script depends on it.  

You say they are being created every minute... which would require a LaunchDaemon somewhere to trigger it, or possibly a cron script.

Can you show the contents of these folders?  

• /Library/LaunchAgents
• /Library/LaunchDaemons

Finally, can you open Terminal and run: 

sudo crontab -e

[pr]

Here's the list. I don't see any files that I don't expect there. 

MHR03:~ mac$ ls /Library/LaunchAgents/
com.adobe.ARMDCHelper.cc24aef4a1b90ed56a725c38014c95072f92651fb65e1bf9c8e43c37a23d420d.plist
com.citrix.AuthManager_Mac.plist
com.citrix.ReceiverHelper.plist
com.citrix.ServiceRecords.plist
com.epsecurity.EndpointSecurityforMac.plist
com.googlecode.munki.ManagedSoftwareCenter.plist
com.googlecode.munki.MunkiStatus.plist
com.googlecode.munki.app_usage_monitor.plist
com.googlecode.munki.managedsoftwareupdate-loginwindow.plist
com.googlecode.munki.munki-notifier.plist
com.microsoft.update.agent.plist
com.thinprint.thnuclnt-ica.helper.plist
MHR03:~ mac$ ls /Library/LaunchDaemons/
com.adobe.ARMDC.Communicator.plist				com.epsecurity.bdupddaemon.plist				com.googlecode.munki.managedsoftwareupdate-install.plist
com.adobe.ARMDC.SMJobBlessHelper.plist				com.epsecurity.epag.plist					com.googlecode.munki.managedsoftwareupdate-manualcheck.plist
com.citrix.ctxusbd.plist					com.epsecurity.redline.plist					com.microsoft.autoupdate.helper.plist
com.dymo.pnpd.plist						com.epsecurity.upgrade.plist					com.microsoft.teams.TeamsUpdaterDaemon.plist
com.epsecurity.AuthHelperTool.plist				com.github.munkireport.runner.plist				
com.epsecurity.bdch.plist					com.googlecode.munki.appusaged.plist				
com.epsecurity.bdconnectorservice.plist				com.googlecode.munki.authrestartd.plist				
com.epsecurity.bdcoreissues.plist				com.googlecode.munki.logouthelper.plist
com.epsecurity.bdldaemon.plist					com.googlecode.munki.managedsoftwareupdate-check.plist
MHR03:~ mac$ sudo crontab -e
crontab: no crontab for root - using an empty one
crontab: no changes made to crontab
MHR03:~ mac$ 

[mainelysteve]

It's a long shot but it could be that you've installed a package or disk image that was created in Jamf Composer or another packaging  tool that uses snap-shots and that gathered those specific files into the installer and they weren't removed. You're using Munki so it's a possibility since the files are on both machines.

I'd do a thorough check to see what you're deploying from Munki.

[pr]

That might be a solution, but then I would expect those files to have an old date. Now they are renewed each minute or a couple of times per day.

Let's start with another question: do any of you recognise these files as being valid Jamf files?

I have no Jamf experience and the only reason I'm here is because the filename contains "Jamf". At this moment that is my only clue.

[bradtchapman]

Those are not created by Jamf.  Someone at your organization created these.  @mainelysteve has a good point; it could be coming from Munki.  Examine the contents of those LaunchDaemons for clues.  Check the console logs to see which daemons are firing.

Furthwrmore.:. since you said the files are at the "root" of the drive, you must be looking at a system with Mojave, or working in a Mac management environment that was designed several years ago.  Ever since the volume split in Catalina, the root folder is no longer a "safe" place to write files.  It should be stored elsewhere like /etc/companyname, or /Library/CompanyName, etc.

[mainelysteve]

These files are using Jamf in name only and have nothing to do with it's management framework. If it's an application installer added to Munki and you don't have the version checking correct then it will install each time a scheduled Munki run occurs. The files in the root would keep incrementing the modified date until the installer is removed from the manifest.

As mentioned above the only application that matches this file extension is SuperCard. Do an inventory of all of the third party applications and look for one with a slightly undercooked or less polished user interface. Then search your Munki repo for that installer.

[pr]

Let's start by thanking all of you who took the time to react and try to help me in finding the cause. 
Your suggestions helped my in thinking in a direction that helped me to find to software that created these files.

I've been able to stop the creation of these files on 2 Macs. A ticket with the software company has been created to verify if they really are creating those files.

Until I receive their confirmation I will not mention the name of this software. But I will keep you posted on how this ends.

[bradtchapman]

If you can join the MacAdmins Slack, you can discuss it a bit more freely since it's not as "public" as this forum and won't be searchable by Google.  

macadmins.org

My username there is the same if you want to send a private message.  

[548matt]

Hi pr

I would like to add to this conversation by saying - I have the same issue. Same files create. Same contents - but this is across a large number of Mac's.
I don't use JAMF. I don't use Munki.

My current thinking is that it's created by an anti virus software company. No reply to my ticket - so I'm going to have to send it again.

I'll post here if I get any results.

Matt

[momoj]

These files just appeared on some of our devices. Coincidentally on the devices that have them also are having a huge slowdown. We did remove BitDefender on a couple of the devices as that was taking up a huge amount of CPU power. Removing BitDefnender did stop the slowdown. I am trying to find out how these devices are connected. 

[548matt]

Hi Momoj

Yes - it's a BitDefender issue. They are saying that they have not had any other reports of this issue - so - can you please report this (raise a ticket) with BitDefender.
The more people report this - the quicker it will be fixed.

[pr]

I can confirm as well that it is BitDefender. They are aware of this and will take action.

[cm]

Been struggling with Bitdefender issue as well. Submitted ticket via webform with not confirmation, so submitted screenshots and logs via email support and received a confirmation of receipt. I have not heard any response and have not seen any posts that they are aware of an issue. Do we know the JAMF files and Bitdefender are related? 

[548matt]

I guess you could do your own IT support investigation and remove Bitdefender - delete the files and reinstall BitDefender and watch the files return to the root director.

[548matt]

Hi Everyone

An update has been released to resolve this issue.
We have enabled  fast ring onto a subset of machines and are testing the new version (EPS MAC 7.4.8.200008).
So far - so good.

[cm]

1. For the JAMF files found on Macs, Bitdefender tech claims they don't do anything that uses JAMF.

2. For the Bitdefender slowdown, I have a ticket open with them and have see the issue even with Product Version: 7.4.8.200008. Oddly, I have some now with Product Version: 4.17.34.200184. All the same OS. I have submitted this and logs to BD and waiting response.

[548matt]

Unfortunately we have also seen the slowdown with Product Version: 7.4.8.200008.
Sent another ticket update to BitDefender.

[548matt]

Hi Everyone

Product Version: 7.4.8.200008 seems to removed the files from the root directory.

We are still have an issue with BitDefender running on Mac OS.

All workstation have been upgraded to the latest version available - 7.4.8.200010

Issue is more problematic on a machine running Mac OS 10.14 (Mac OS Mojave)

Machine becomes unusable - only option is to uninstall the software. Has been the same since I initially contact support back on the 5th of January 2022 - now 28 days ago.

Considering other AV options - what are peoples thoughts on a good AV that offers EPP?