• Allow History Clearing: Set to false, to disable clearing history in Safari.
• Allow Private Browsing: Set to false, to disable private browsing in Safari.

For more details, please see below the jump.

Safari settings can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari bookmark management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari settings managed.

As of Jamf Pro 11.20.1, there is not a Blueprints template available for creating blueprints which manage Safari settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. Give it a name when prompted and click the Create button. For this example, I’m using Safari Settings.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the Safari settings component.

6. Click on the Safari settings component and drag the Safari settings component to the Declaration group section.

7. Mouse over the Safari settings component and you will see a Configure button appear. Click the Configure button.

8. To add the settings for the Safari settings in this example, set the following settings as follows:

• History clearing: Set to Disallowed
• Private browsing: Set to Disallowed

9. Once all the settings choices have been made and verified, click the Add button.

10. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

11. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Safari Settings Deployment Group.

14. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Safari Settings blueprint as being deployed.

On your managed devices, you can verify that the new Safari settings management configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom.

In the case of this example, you should see a User Declarations section with a listing for Safari Settings.

If you click on the Safari Settings listing, it should report the following:

• Allow History Clearing: No
• Allow Private Browsing: No

You should also be able to open Safari and verify that the desired settings are being applied by trying to clear Safari’s history and opening a private window.

• Company Name Intranet: https://intranet.company.com
• Company Name Developer Site: https://developer.company.com
• Company Name Travel: https://travel.company.com

For more details, please see below the jump.

Safari bookmarks can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari bookmark management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari bookmarks managed.

As of Jamf Pro 11.20.1, there is not a Blueprints template available for creating blueprints which manage Safari bookmarks so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. Give it a name when prompted and click the Create button. For this example, I’m using Safari Bookmarks.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the Safari bookmarks component.

6. Click on the Safari bookmarks component and drag the Safari bookmarks component to the Declaration group section.

7. Mouse over the Safari bookmarks component and you will see a Configure button appear. Click the Configure button.

8. At this point, you will see an Managed Bookmarks section without any listed bookmarks. Click the Add bookmark group button.

9. To add the settings for the Safari bookmarks in this example, set the following entries as follows:

• Title: Company Name
• Group identifier: 875D8D76-20EE-43DB-B874-9FC9F1CCC3A9

Note: The Group identifier field can be any unique string and the only thing that matters is that it is unique. Acceptable unique strings include the following:

• 875D8D76-20EE-43DB-B874-9FC9F1CCC3A9
• Finance Department Bookmarks
• Man I Love Donuts Especially Those With Chocolate Frosting

If the string is not unique, the bookmarks which have a not-unique group identifier will be composited together into one set of bookmarks.

Bookmarks:

• Company Name Intranet: https://intranet.company.com
• Company Name Developer Site: https://developer.company.com
• Company Name Travel: https://travel.company.com

10. Once all the settings choices have been made and verified, click the Add group button.

11. If everything looks right, click the Save button.

12. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

13. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Safari Bookmarks Deployment Group.

14. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Safari Bookmarks blueprint as being deployed.

On your managed devices, you can verify that the new Safari bookmark configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom.

In the case of this example, you should see a User Declarations section with a listing for Safari Bookmarks.

If you click on the Safari Bookmarks listing, it should report the following:

Present

You should also be able to open Safari and verify that the desired bookmarks are appearing in Safari’s Bookmarks menu.

This behavior is managed in System Settings: Desktop & Dock and is listed as the Show Widgets setting. This has two selectable settings:

• On Desktop
• In Stage Manager

The default behavior is for both the On Desktop and In Stage Manager options to be enabled.

To prevent desktop widgets from appearing on your desktop, disable the On Desktop option.

Fortunately for my preferences, the desktop widgets behavior can also be controlled via the following setting:

• Domain: com.apple.WindowManager
• Key: StandardHideWidgets
• Value: Boolean

To disable desktop widgets and prevent them from appearing, run the following command as the logged-in user:

To enable desktop widgets to appear again, run the following command as the logged-in user:

In my case, I wanted to disable desktop widgets and prevent them from appearing so I’ve also written a profile which can enforce this. It’s available via the link below:

https://github.com/rtrouton/profiles/blob/main/DisableDesktopWidgets

For more details, please see below the jump.

On macOS Sequoia 15.7.0, System Profiler shows an entry for FireWire.

On macOS Tahoe 26.0, System Profiler no longer shows an entry for FireWire.

Running the following command on both macOS Sequoia and macOS Tahoe also shows that SPFireWireDataType has been removed from macOS, which means that System Profiler is not longer gathering data from that area:

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress this screen on macOS Tahoe using a configuration profile. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.SetupAssistant.managed
• Key: SkipSetupItems
• Value: FileVault

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/blob/main/SkipFileVaultSetup

• Device channel: Allows MDM settings to be delivered to devices and apply device settings to the entire device.
• User channel: Allows MDM settings to be delivered to user accounts on devices and apply user settings just to the relevant users.

When enrolling a device into an MDM server using device enrollment, a couple of things happen as part of the MDM enrollment process:

• The device becomes a managed device.
• The local user account which installs the MDM enrollment profile becomes a managed user.

There’s additional details on what it means to be a managed user, but one of the most important is that in this context, being a managed user means that the local user account can be managed with settings delivered via the user channel. Other local accounts on the Mac are not able to access the user channel and cannot be managed by user level settings.

Declarative device management (DDM) has these same concepts of device channel and user channel and as far as I can tell, it works exactly the same as it does for MDM:

• Device channel: Allows DDM declarations to be delivered to devices and apply device settings to the entire device.
• User channel: Allows DDM declarations to be delivered to MDM-managed user accounts on devices and apply user settings just to the relevant users.

What this means is that a MDM-managed user account is able to be managed via settings delivered by the DDM user channel and other accounts which are not MDM-managed are not part of the DDM user channel and cannot be managed by DDM user level settings.

An example of DDM management which uses the user channel are the Safari extension management options. If you check the documentation, as of September 9th, 2025, Safari extension management has the following configuration availability listing:

• Allowed in supervised enrollment: iOS, macOS, Shared iPad, visionOS
• Allowed in device enrollment: NA
• Allowed in user enrollment: NA
• Allowed in local enrollment: NA
• Allowed in system scope: iOS, visionOS
• Allowed in user scope: macOS, Shared iPad

This means that DDM Safari extension management is using the device channel on the following Apple platforms:

• iOS
• visionOS

DDM Safari extension management is using the user channel on the following Apple platforms:

• macOS
• Shared iPad

https://apps.apple.com/us/app/wayback-machine/id1472432422?mt=12

For more details, please see below the jump.

Safari extensions can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari extension management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari extensions managed.

The following options are available for Safari extension management:

• Allowed Domains
• Denied Domains
• Private Browsing
• State

• Allowed Domains:
  •  Controls the DNS domain(s) and sub-domain(s) that the extension is allowed to access.
• Denied Domains:
  •  Controls the DNS domain(s) and sub-domain(s) that the extension is blocked from accessing.
• Private Browsing:
  •  Controls whether or not the extension is allowed for use when using private browsing.
    •  Options:
      •   Allowed: The extension can be turned on or off when using private browsing.
      •   AlwaysOn: The extension is always enabled when using private browsing if the extension is also enabled outside of private browsing.
      •   AlwaysOff: The extension is never enabled when using private browsing, even if the extension is enabled outside of private browsing.
• State:
  •  Controls whether an extension is allowed for use in general.
    •  Options:
      •   Allowed: The extension can be turned on or off.
      •   AlwaysOn: The extension is always enabled.
      •   AlwaysOff: The extension is never enabled.

Note:

For Allowed Domains and Denied Domains, the following values are supported:

• Specific domain: Using a specific DNS domain name.
  •  Example: company.com or subdomain.company.com
• Wildcard domain: Using a wildcard domain which uses a single asterix character ( * ) as a prefix for the domain. This wildcard will allow both the top-level domain to be matched, as well as matching any sub-domains, with a wildcard domain entry like *company.com being used to match against company.com as well as subdomain.company.com.
  •  Example: *company.com
• Global wildcard: Uses a single asterix character ( * ). This will match any DNS domain.
  •  Example: *

You can also allow an extension to be specifically used on a specific or wildcarded domain, while blocking it for use on all other domains. For example, if you wanted to allow an extension to be used on the top-level company.com domain and all company.com subdomains, but block it on all others, you could define Allowed Domains and Denied Domains like this:

• Allowed Domains: *company.com
• Denied Domains: * 

For this example, we’re going to set the Wayback Machine Safari extension to use the following settings:

• Allowed Domains: *
• Private Browsing: AlwaysOff
• State: Allowed

This setting will do the following for the Wayback Machine Safari extension:

• Allow the extension to be used.
• Allow the extension to be used with all domains.
• Block the extension from being used with Safari’s private browsing option, even when the extension is enabled outside of private browsing.

I can set up a Blueprint in Jamf Pro to deploy this Safari extension management configuration using the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Manage Safari extensions box.

4. Give it a name when prompted. For this example, I’m using Manage Wayback Machine Extension.

5. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Safari Extension Deployment Group.

6. At the following screen, we need to provide the identifier of the extension along with our settings.

To do this, we need to get the code signature of the Safari extension file. To obtain the code signature, once you have the extension’s file location, you will need to use the codesign command line tool to run a command similar to the one below:

In the case of the Wayback Machine extension, the extension’s file is available in the following location:

/Applications/Wayback Machine.app/Contents/PlugIns/Wayback Machine Extension.appex

To get the code signature, you would run the following command:

That should provide output similar to what’s shown below:

From this output, we are looking for the values of the following lines:

• Identifier
• TeamIdentifier

For the Wayback Machine extension, these are the values shown:

• Identifier: archive.org.waybackmachine.mac.extension
• TeamIdentifier: ZSFX78H3ZT

For the Blueprint, this information needs to be formatted as shown below:

Identifier (TeamIdentifier)

For the Wayback Machine extension, this means that the identifier for the Blueprint is the following:

Now that we have the correct identifier, let’s configure the Blueprint settings for the following:

• Identifier: archive.org.waybackmachine.mac.extension (ZSFX78H3ZT)
• Extension state: Allowed
• Private browsing state: Always off
• Allowed domains: *

7. Once all the information has been entered and verified to be correct, click the Save button.

8. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Manage Wayback Machine Extension blueprint as being deployed.

On your managed devices, you can verify that the new Safari extension management configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom. In the case of this example, you should see a User Declarations section with a listing for Safari Extensions.

If you click on the Safari Extensions listing, it should report the following extension is allowed:

archive.org.waybackmachine.mac.extension

For additional information on the configuration, you would need to open Safari and access the extension information for the Wayback Machine extension. There, you should see the following:

• The Allow in Private Browsing checkbox is unchecked and grayed out.
• A notification that the extension works on all websites

There should also be notifications that these settings have been configured by device management.

You should also be able to confirm that the Wayback Machine extension is available in regular Safari browser windows, but not available in private browsing windows.

This search uses the com.apple.remotemanagementd subsystem as a predicate when searching the logs. However, you can get even more granular by searching for a specific category of information within the com.apple.remotemanagementd subsystem. For example, let’s look at the data returned from running the command above:

Within the data returned by searching for the com.apple.remotemanagementd subsystem, there’s several categories included as part of the subsystem log entries:

• XPCListenerDelegate
• client
• mdmConduit

Those categories show up following the listing for the com.apple.remotemanagementd subsystem in the returned log entries like this:

If we wanted to get more granular and search the unified system log for only the logs associated with a particular category for a logging subsystem from the last ten minutes, the following command could be used to search using the following predicates:

• Subsystem: com.apple.remotemanagementd
• Category: mdmConduit

That would return only those log entries which matched both the com.apple.remotemanagementd subsystem and the mdmConduit category:

To start, have your MDM server send an DDM declaration command to the device in question. If your MDM server says it sent successfully, see what shows up on the Mac’s end using the following command to get information logged within the last ten minutes:

In this case, the following process and logging subsystem are being checked for their corresponding log entries:

• Process: remotemanagementd
• Subsytem: com.apple.remotemanagementd

This will likely give you a large number of log entries, but it’s possible to filter for what you’re looking for. For example, a blank push remote command sent from a Jamf Pro MDM server will trigger a Mac to send in a DDM status report to its MDM server. This process of prompting the Mac to send in a DDM status report should include logging a line similar to this:

Since we can see that the relevant process is remotemanagementd and the string to search for includes Syncing only if needed, then if you sent a blank push within the last ten minutes you can use the following command to see if the entry appears in the returned logs:

That should pull up the relevant log entry:

To look up information specifically about DDM status item logging, using only the com.apple.remotemanagementd subsystem as a predicate when searching the logs looks like it returns this information without including additional information involving only the remotemanagementd process. For example, using the command below should get any DDM status item logging from the last ten minutes:

If no status items needed to be updated with the MDM server, you may see logging like this:

If there were status items to send to the MDM server, you may see logging like this:

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Analytics screen on macOS Sequoia using a configuration profile. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.SetupAssistant.managed
• Key: SkipSetupItems
• Value: Diagnostics

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/blob/main/SkipAppAnalyticsSetup