Skip to main content

Hi all,

A bit new to uploading a configuration profile straight to Jamf vs. using built-in ones. I'm trying to prevent users from updating to a new version of Chrome before IT tests it by using this configuration profile, setting a specific version as the cap (73, in this case). It's a copy of what Google Support provides with an updated version number. https://support.google.com/chrome/a/answer/7591084

I would hope it was as easy as getting the .mobileconfig, uploading it, and distributing it.. but I was still able to update to 74 on a test machine.

Are there any obvious issues with this or I am a bit lost when uploading a new config profile?

Thanks!

<?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>PayloadContent</key>

            <dict>

                <key>com.google.Keystone</key>

                <dict>

                    <key>Forced</key>

                    <array>

                        <dict>

                            <key>mcx_preference_settings</key>

                            <dict>

                                <key>updatePolicies</key>

                                <dict>

                                    <key>com.google.Chrome</key>

                                    <dict>

                                        <key>TargetVersionPrefix</key>

                                        <string>73.</string>

                                        <key>UpdateDefault</key>

                                        <integer>2</integer>

                                    </dict>

                                    <key>com.google.Chrome.canary</key>

                                    <dict>

                                        <key>UpdateDefault</key>

                                        <integer>2</integer>

                                    </dict>

                                    <key>global</key>

                                    <dict>

                                        <key>DownloadPreference</key>

                                        <string>cacheable</string>

                                        <key>UpdateDefault</key>

                                        <integer>3</integer>

                                    </dict>

                                </dict>

                            </dict>

                        </dict>

                    </array>

                </dict>

            </dict>

            <key>PayloadEnabled</key>

            <true/>

            <key>PayloadIdentifier</key>

            <string>MCXToProfile.11822e9e-d7be-47a4-9a07-dba52417ba56.GoogleSoftwareUpdate.9092f47f-b06a-43de-b137-d157f1996441</string>

            <key>PayloadType</key>

            <string>com.apple.ManagedClient.preferences</string>

            <key>PayloadUUID</key>

            <string>9092f47f-b06a-43de-b137-d157f1996441</string>

            <key>PayloadVersion</key>

            <integer>1</integer>

        </dict>

    </array>

    <key>PayloadDescription</key>

    <string>Included custom settings:com.google.Keystone</string>

    <key>PayloadDisplayName</key>

    <string>Google Software Update Policies</string>

    <key>PayloadIdentifier</key>

    <string>com.google.Keystone</string>

    <key>PayloadOrganization</key>

    <string></string>

    <key>PayloadRemovalDisallowed</key>

    <true/>

    <key>PayloadScope</key>

    <string>System</string>

    <key>PayloadType</key>

    <string>Configuration</string>

    <key>PayloadUUID</key>

    <string>11822e9e-d7be-47a4-9a07-dba52417ba56</string>

    <key>PayloadVersion</key>

    <integer>1</integer>

</dict>

</plist>

I've tried this previously and was never able to get the version pinning to work. Have you thought about doing your testing with the beta versions of Chrome instead? This gives you the opportunity to test out future stable releases of Chrome before it's released to your users. This also saves you the hassle of having to update the config profile to pin each new version of Chrome.
https://www.chromestatus.com/features/schedule

@andymcp That's a good idea, definitely adding that to the list of options I'm building out to stakeholders if this config profile doesn't work out. It's that and/or keeping old Chrome installs for rollback if something is incompatible that IT misses to test. (This was all triggered on a web-based phone system that broke as they couldn't keep up with the Chrome updates)

Thanks for the reply!

Terms & ConditionsCookie settingsAccessibility statement