This appears to been touched based on in the past, but appears to of died once catcher was put into place for check coverage.apple.com however, I noticed in Monterey and possibly big sur, you can see applcare+ status, under >Apple Logo > About my Mac > SupportAnd was wondering, if this can be added to an extension attribute, as like the ability to get the battery condition of a MacBook, and if so where on earth is the information stored.

Collecting Warranty Status

Integrating with Apple GSX allows Jamf to pull in warranty data. Not sure if you have a GSX account, but might be something to look into:

https://docs.jamf.com/technical-articles/Integrating_with_Apples_Global_Service_Exchange_GSX.html

Check the application called MUT (https://apps.apple.com/us/app/mut/id1133234759?mt=12)

This helps in getting the warranty information added to Jamf but it's not an automatic process that needs all the warranty details in a sheet to do a bulk upload.

Since we don't have a GSX connector access we use this with the procurement data and upload the warranty details in JAMF.

Hello I have the same need.

Now apple display this information directly in macOS. The point will be to extract it in an attribute extension. But where is stoked this information on the mac ? :-)

Sorry to resurrect a dead thread. Thought it might be okay since this is a top search result!

I found a blog post on techitout.xyz and thought it would be useful for others trying to get the same info into an extension attribute.
https://techitout.xyz/2023/07/12/jamf-pro-get-mac-warranty-information/

This works when I use it in CodeRunner, but it doesn't seem to work for me as an EA in Jamf Pro. Maybe someone else can help shed some light on why.

Sorry to resurrect a dead thread. Thought it might be okay since this is a top search result!

I found a blog post on techitout.xyz and thought it would be useful for others trying to get the same info into an extension attribute.
https://techitout.xyz/2023/07/12/jamf-pro-get-mac-warranty-information/

This works when I use it in CodeRunner, but it doesn't seem to work for me as an EA in Jamf Pro. Maybe someone else can help shed some light on why.

Nice find, I will have a play with the script also and see if I can come up with something

Appears to be working in my environment,

what I did wrong at first is put it under description, instead of as a script in the extension attribute query

see how I have it setup in the images below within extension attribute (shame we can't do the same for iPad)

Sorry to resurrect a dead thread. Thought it might be okay since this is a top search result!

I found a blog post on techitout.xyz and thought it would be useful for others trying to get the same info into an extension attribute.
https://techitout.xyz/2023/07/12/jamf-pro-get-mac-warranty-information/

This works when I use it in CodeRunner, but it doesn't seem to work for me as an EA in Jamf Pro. Maybe someone else can help shed some light on why.

Looking closer at it, It seems the Warranty.plist path is not available pre macOS 13.

No actually this is not the reason, I suspect the link of weather the path exists might be due to the existance of an Apple ID.

that doesn't appear to be the reason either, but there does appear to be a reason for some devices not to have the folder and plist file

I've been trying to figure it out as well. The article author says that he noticed it wasn't there for Intel devices. I have used this on two environments and have noticed the same thing.

I'm inclined to say it's the first user account and not AD accounts, post a certain version release. on my machine it came down 25th July 2023, this might have actually been when I demobilised my account, back to a standard account, or post a software update. I have old Macbook 2019 Intels reporting in the information, and that specific one is likely using a non AD account and likely the first use user and due to the system level security not he user folders, this will present to be harder to obtain if a different user account is holding the data and not the account in use. Moving forward for our environment and current setup, for the majority I hope to see this become reliable, but an easier fix would be for apple to populated it into the library folder and not the users library. I will have a chat to our Apple Education Solutions Architect, to float the possibility to have them expand the plist file to an space on the MacBook, so that it cane be functional and allow for obtainable information that can be relied on.

I believe the warranty.plist is created for any user who checks the warranty of the system from the system. They would browse to the warranty lookup Apple Portal and provide the systems serial number https://checkcoverage.apple.com/ whatever user is logged in will then have the warranty.plist written in the context of their login

Appears to be working in my environment,

what I did wrong at first is put it under description, instead of as a script in the extension attribute query

see how I have it setup in the images below within extension attribute (shame we can't do the same for iPad)

@Malcolm upon deploy this EA in Jamf, i'm getting blank output. Is it working for anyone?

Anyone come up with a solution to this?

GSX integration with Jamf really helped my desktop team with this. Once it was done, I didn't need to worry about EAs getting populated or not.

Is GSX integration something that is possible for you? The process isn't too bad. Let me know if you need the steps to complete it.

what's the requirements?

Follow these articles. If you/your organization has a service contract with Apple, you can create a GSX account. It takes a few days, depending on how responsive they/you are to questions asked.

https://learn.jamf.com/en-US/bundle/technical-articles/page/Integrating_with_Apples_Global_Service_Exchange_GSX.html

Then you will do the actual integration here (this is also linked at the bottom of the above article):
https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/GSX_Connection.html

Interesting, I've put through the inquiry to apple, but likely without having the approval to service devices, we might not get approval for that. Shame it couldn't integrate with an ASM account. But that would still leave our BYOD as an unknown.

they had indicated that we can apply for a Self-Servicing Account Program which would give us access to GSX.

Self-Servicing Account Program — Official Apple Support

So looking at doing that now.

they had indicated that we can apply for a Self-Servicing Account Program which would give us access to GSX.

Self-Servicing Account Program — Official Apple Support

So looking at doing that now.

I don't think we would be eligible, might be struggling to reach the 500 device count, more specifically ones with current AppleCare available.

they had indicated that we can apply for a Self-Servicing Account Program which would give us access to GSX.

Self-Servicing Account Program — Official Apple Support

So looking at doing that now.

Nice! Hope that works for you. As for your BYOD devices, at this time, I haven't found any other ways to do it other than what I posted previously.

I asked if it could be added as an Apple feature, so that all devices collect their own warranty status and store it. An unlikely thing to occur, but seemingly something the OS could easily execute.

I've tested a few things and a few script options and i think i have a solution which is not 100% reliable because it depends on your hardware and software. As far as i can tell it only works on Apple Silicon hardware and it requires macOS Sonoma 14.x as a minimum operating system. But this solution doesn't require a GSX Account or anything else.

It seems like you can check a *_warranty.plist file for the coverageEndDate attribute. On a few machines i've unfortunately seen more than one of these files located in:

~/Library/Application\\ Support/com.apple.NewDeviceOutreach

.. but fortunately only one of those two files really has a coverageEndDate attribute!

After a few adjustments i was able to create an extension attribute which is working fine in our jamf environment. Just format the date as you like - the scripts current output is DD.MM.YYYY!

#!/bin/bash

# If AppleCare is active, there may be one or more files in the Users Library folder.

# Get the current username
loggedInUser=`stat -f "%Su" /dev/console`
echo Current logged in user is: $loggedInUser

# Check if the Warranty file(s) exist
cd /Users/$loggedInUser/Library/Application\\ Support/com.apple.NewDeviceOutreach
warrantyFile=( $(ls | grep "_Warranty"))

# Loop to check each file and stop if condition is true
for i in "${warrantyFile[@]}"
do
echo "$i"
expires=`defaults read /Users/$loggedInUser/Library/Application\\ Support/com.apple.NewDeviceOutreach/$i coverageEndDate`

if [ -z "$expires" ]
then echo "File has no expiration date – skipping this file."
else
# Convert epoch to a standard date format
ACexpires=$(date -r $expires '+%d.%m.%Y')
echo "<result>$ACexpires</result>"
exit 0
fi
done
echo "<result>No Warranty File found</result>"
exit 0

As Data Type we've used the "String" option because this is fine for us, but if you would like to use this extension attribute in a smart group you would like to change the Data Type to "Date" and reformat the output to YYYY-MM-DD hh-mm-ss.

Feel free to try this solution in your environment.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded