Skip to main content

There is another thread with this that starts with discussing the managed preference involved. Wanted to start a new thread with the user-facing error message as the subject. So far I have been running into this on pre-WWDC 2023 Apple Silicon MacBooks running macOS Ventura 13.4(22F66) and 13.4.1(22F82), while older releases seem to be able to leap into 22F82 and then begin enjoying the broken updates. This error is showing up now on systems attempting to install the rapid security response (c) too, so even more reason to bump the thread up. Our solution was to remove the Defer Updates from our restrictions payload entirely. The image below shows the only thing I changed to get it working. That instantly allowed people to install updates. Hope this helps and that Apple fixes it.

 

Also worth it to see what we had set before that is causing problems.

@russell_garriso This issue has been mentioned in at least two threads created since macOS 13.4.1 came out, but having a thread titled with the error message is a good idea to increase visibility.

What do you guys think of what was posted here re: custom xml payload instead of using what's in the MDM payload?

https://discussions.apple.com/thread/254979639?page=2

XML below:

Instead of configuring MDM build in restriction settings in MDM server, try to apply custom XML file with payloads, see below:

 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>PayloadContent</key>

    <array>

        <dict>

            <key>PayloadDisplayName</key>

            <string>Restrictions</string>

            <key>PayloadIdentifier</key>

            <string>com.apple.applicationaccess.C72C75C5-EFFC-4107-99AE-BF586B060B2C</string>

            <key>PayloadType</key>

            <string>com.apple.applicationaccess</string>

            <key>PayloadUUID</key>

            <string>9446E80E-6735-408E-9DC1-E80A6666CF74</string>

            <key>PayloadVersion</key>

            <integer>1</integer>

            <key>allowRapidSecurityResponseRemoval</key>

            <true/>

            <key>allowRapidSecurityResponseInstallation</key>

            <true/>

            <key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>

            <integer>65</integer>

            <key>enforcedSoftwareUpdateMinorOSDeferredInstallDelay</key>

            <integer>15</integer>

            <key>forceDelayedMajorSoftwareUpdates</key>

            <true/>

            <key>forceDelayedSoftwareUpdates</key>

            <true/>

        </dict>

    </array>

    <key>PayloadDisplayName</key>

    <string>An update restriction</string>

    <key>PayloadIdentifier</key>

    <string>6155859A-643F-4F70-9371-99D3D3AB25E9</string>

    <key>PayloadType</key>

    <string>Configuration</string>

    <key>PayloadUUID</key>

    <string>420C79D4-15B7-4875-A656-E042D5E8AE16</string>

    <key>PayloadVersion</key>

    <integer>1</integer>

</dict>

</plist>

What do you guys think of what was posted here re: custom xml payload instead of using what's in the MDM payload?

https://discussions.apple.com/thread/254979639?page=2

XML below:

Instead of configuring MDM build in restriction settings in MDM server, try to apply custom XML file with payloads, see below:

 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>PayloadContent</key>

    <array>

        <dict>

            <key>PayloadDisplayName</key>

            <string>Restrictions</string>

            <key>PayloadIdentifier</key>

            <string>com.apple.applicationaccess.C72C75C5-EFFC-4107-99AE-BF586B060B2C</string>

            <key>PayloadType</key>

            <string>com.apple.applicationaccess</string>

            <key>PayloadUUID</key>

            <string>9446E80E-6735-408E-9DC1-E80A6666CF74</string>

            <key>PayloadVersion</key>

            <integer>1</integer>

            <key>allowRapidSecurityResponseRemoval</key>

            <true/>

            <key>allowRapidSecurityResponseInstallation</key>

            <true/>

            <key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>

            <integer>65</integer>

            <key>enforcedSoftwareUpdateMinorOSDeferredInstallDelay</key>

            <integer>15</integer>

            <key>forceDelayedMajorSoftwareUpdates</key>

            <true/>

            <key>forceDelayedSoftwareUpdates</key>

            <true/>

        </dict>

    </array>

    <key>PayloadDisplayName</key>

    <string>An update restriction</string>

    <key>PayloadIdentifier</key>

    <string>6155859A-643F-4F70-9371-99D3D3AB25E9</string>

    <key>PayloadType</key>

    <string>Configuration</string>

    <key>PayloadUUID</key>

    <string>420C79D4-15B7-4875-A656-E042D5E8AE16</string>

    <key>PayloadVersion</key>

    <integer>1</integer>

</dict>

</plist>

@cmac-1 This isn't a Jamf Pro problem, it's an error in how Apple handles the restriction when there are multiple builds for the same macOS version, so manually building the .plist for the restriction isn't going to help.

Had the same issue on 2 x MacBook Pro (13-inch, M2, 2022), they had problems upgrading from 13.4 to 13.4.1. Had to remove all Deferred Updates settings in Jamf and they are able to update now. Thank you so much.

This appears to be fixed with the release of 13.5. I put the restrictions profile with the defer updates on an M1 Pro MacBook running 13.4.1 (c) (22F770820d) and was able to use System Settings to update to 13.5 (22G74) without issue. Not sure if (22F82) still has the issue, but I am going to revert my workaround profiles and see if anyone still gets the build error.

This appears to be fixed with the release of 13.5. I put the restrictions profile with the defer updates on an M1 Pro MacBook running 13.4.1 (c) (22F770820d) and was able to use System Settings to update to 13.5 (22G74) without issue. Not sure if (22F82) still has the issue, but I am going to revert my workaround profiles and see if anyone still gets the build error.


Have you found this to be working ever since? We haven't implemented the deferrals again but would be useful to know if we'll be able to use them when Sonoma comes out.

Reply


Terms & ConditionsCookie settings