babgond

On macOS, you can use the DumpManagementStatus function of the mdmclient command line tool to provide a lot of useful information if your Mac is enrolled with an mobile device management (MDM) server. This function outputs information in a JSON-like format that looks similar to this:

The above output is how MDM management may look if a Mac was enrolled using a profile, as opposed to being enrolled via Automated Device Enrollment (ADE). A Mac which was enrolled via ADE may display information which looks like this:

Meanwhile, a Mac which is not enrolled with an MDM server may display output which looks like this:

For more information, please see below the jump.

The information provided by this tool can be used in a variety of ways. For example, if you want to get the URL of your MDM server, you can run the following command:

You should get output which looks similar to this:

If you want to check if your Mac was enrolled via ADE, you can run the following command:

A Mac which is enrolled via ADE should return output which looks like this:

A Mac which not is enrolled via ADE should return output which looks like this:

If you want to check if your Mac was enrolled via Account Driven User Enrollment (ADUE) or via profile-based user enrollment, you can run the following command:

A Mac which is enrolled via ADUE or via profile-based user enrollment should return output which looks like this:

A Mac which not is enrolled via ADUE or via profile-based user enrollment should return output which looks like this:

If you want to check and see if your Mac was enrolled via Account Driven Device Enrollment (ADDE) vs being enrolled via ADE or a profile-based device enrollment, you can run the following command:

A Mac which is enrolled via ADDE should return output which looks like this:

A Mac which is enrolled via via ADE or a profile-based device enrollment should return output which looks like this:

One thing to be aware of is that this output is not actually in JSON format, though it looks like it is. The output is in Apple’s property list (plist) format, which can be expressed in a JSON-like format. The reason I mention this is that trying to parse the output using tools like jq may result in errors similar to what’s shown below:

On macOS, Microsoft has made its Office 365 applications available via three different channels:

• Directly from Microsoft (available for folks via office.com and other Microsoft resources.)
• Apple’s Mac App Store (available for folks using their personal Apple Accounts)
• Apple’s Volume Purchase program (available via Apple Business Manager and Apple School Manager)

In turn, this means updates for these apps may be coming from a variety of sources:

• Microsoft AutoUpdate: For Office 365 applications installed using Microsoft’s installers obtained from office.com or other Microsoft resources.
• Apple’s Mac App Store: For Office 365 applications installed via the Mac App Store by someone using their personal Apple Account.
• An organization’s MDM service: For Office 365 applications installed by that MDM using Volume Purchase licensing.

Depending on how tightly an organization controls the ability of its users to install applications, it’s possible to have a scenario like this:

• Microsoft Excel: Installed using an installer from Microsoft’s office.com site.
• Microsoft Outlook: Installed using a personal Apple Account from the Mac App Store.
• Microsoft Word: Installed by the organization’s MDM using a Volume Purchase license.

This can lead to challenges with keeping the apps updated, since there are three different update mechanisms for the three separate apps.

• Microsoft Excel: Updates coming via Microsoft’s AutoUpdate application.
• Microsoft Outlook: Updates coming via the Mac App Store.
• Microsoft Word: Updates coming via commands sent by the organization’s MDM service to the managed device which tell the managed device to connect back to Apple and get the latest update.

To help with figuring this out, it’s possible to query the application’s metadata using the mdls command line tool to see if the app has an associated App Store receipt. If it does, it’s possible to further figure out if the App Store receipt in question is for a Volume Purchase program (VPP) license or for a Mac App Store (MAS) license.

To check, you can run the following command and examine the output you get back:

For example, here’s the output you should see for Microsoft Outlook.app installed using an installer from office.com or other Microsoft resources:

Note: The (null) result is because the app does not have an associated App Store receipt.

Here’s the output you should see for Microsoft Outlook.app installed via the Mac App Store by someone using their personal Apple Account:

Here’s the output you should see for Microsoft Outlook.app installed by an organization’s MDM using a Volume Purchase license:

For more information, please see below the jump.

Using this method, I’ve written several Jamf Pro Extension Attributes for the following Office 365 applications to assist with figuring out which tool should be updating a particular Microsoft Office 365 application:

• Microsoft Excel
• Microsoft OneDrive
• Microsoft OneNote
• Microsoft Outlook
• Microsoft PowerPoint
• Microsoft Windows App
• Microsoft Word

All of the Extension Attributes should return output like that shown below:

If the app was installed using the Mac App Store with a person’s Apple Account, the Extension Attribute will return the following result:

MAS

If the app was licensed using the Volume Purchase program and installed by an MDM, the Extension Attribute will return the following result:

VPP

If the app was not installed via either the Mac App Store or the Volume Purchase program, the Extension Attribute will return the following result:

MAU

In all other cases, including where the app in question is not installed, the EA will return the following result:

NA

The Extension Attributes are available from GitHub via the following links:

• Microsoft Excel: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_Excel_Update_Source
• Microsoft OneDrive: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_OneDrive_Update_Source
• Microsoft OneNote: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_OneNote_Update_Source
• Microsoft Outlook: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_Outlook_Update_Source
• Microsoft PowerPoint: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_PowerPoint_Update_Source
• Microsoft Windows App: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_WindowsApp_Update_Source
• Microsoft Word: https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/Microsoft_Word_Update_Source

As part of setting up an AWS-hosted cloud distribution point for Jamf Pro, you will need to set up a user in AWS and get an access key and secret access key. I describe that process as part of an earlier post on how to set up an AWS-hosted cloud distribution point. However, many shop’s security policies mandate rotating AWS credentials on a regular basis. For those with requirements like this, please see below the jump for how to rotate these credentials for an AWS-hosted cloud distribution point.

The following procedure will walk you through the process of setting up a new AWS access key and secret access key which can be used to update the credentials used for an AWS-hosted cloud distribution point. This process assumes the following:

• A. You have an existing AWS-hosted cloud distribution point set up in Jamf Pro.
• B. You have an existing AWS IAM programmatic user account set up with the correct permissions to access and manage the AWS-hosted cloud distribution point set up in Jamf Pro.
• C. You can log into the AWS console using an account with console access with sufficient permissions to perform the following actions:
  • i. Access AWS’s IAM service for the account which has the existing AWS IAM programmatic user account referenced in pre-requisite B above.
  • ii. Change the security credentials for the existing AWS IAM programmatic user account referenced in pre-requisite B above.
• D. You can log into your Jamf Pro admin console using an account with sufficient permissions to perform the following actions:
  • i. Access the cloud distribution point settings.
  • ii. Edit the cloud distribution point settings.

1. Log into the AWS console.

2. Select the IAM service.

3. Identify and select the existing AWS IAM programmatic user account referenced in pre-requisite B above.

4. For that user account, select Security Credentials.

5. See how many access keys (active and inactive) are currently associated with the account.

An AWS IAM user account can have up to two total access keys set up in it. This procedure assumes you have one active access key which is being used as credentials for the AWS-hosted cloud distribution point. You will need to set up a second active access key as part of rotating the credentials for the cloud distribution point and both sets of access keys must be active for the rotation process to successfully complete.

If you already have two active access keys showing for the existing AWS IAM programmatic user account, stop here. Before proceeding, you will need to identify if a) if second access key is being used by something else, b) what the second access key is being used for and c) get its functionality moved to another IAM programmatic user account.

The rest of the procedure assumes that you have one active access key associated with the account.

6. Click the Create Access Key button.

7. For use case, select Other. Once the Other case has been selected, click the Next button.

8. Set a description tag (if desired), then click the Create Access Key button.

9. The access key will be created, with an access key ID and secret access key.

This is the only time you will have access to both the access key ID and secret access key information. You can click the Show button to reveal the secret access key information.

You also have the option of downloading both the access key ID and secret access key information in a .csv file.

The information in the .csv file will look similar to what’s shown below:

10. Once you have both the access key ID and secret access key information stored for later reference, click the Done button.

You should now see a second active access key appear in the AWS console. The access key ID is displayed, but the secret access key is never shown again following the access key’s creation (described in step 9.)

11. Log into the Jamf Pro admin console for the Jamf Pro instance which has the relevant AWS-hosted cloud distribution point.

12. Go to Settings: Server: Cloud Distribution Point.

13. In the Cloud distribution point window, verify that Content Delivery Network is set to the following:

Amazon Web Services

14. Click the Edit button to update the credentials for the AWS-hosted cloud distribution point.

15. In the Access Key ID entry field, put in the following information:

Access key ID

16. In the Secret Access Key and Verify Secret Access Key entry fields, put in the following information:

Secret access key

17. Once you’ve verified that the correct information has been entered into the Access Key ID, Secret Access Key and Verify Secret Access Key entry fields, click the Save button.

18. Once the changes have been saved, click the Test button.

19. In the Cloud distribution point test window, click the Test button.

If the credentials were successfully rotated, you should see a message that the cloud service was successfully contacted.

If you see anything other than a message that the cloud service was successfully contacted, contact Jamf Support.

Once the credentials have been successfully rotated, I would recommend going back into the AWS console to deactivate the previously-used access key. To do this, use the following procedure.

1. Log into the AWS console.

2. Select the IAM service.

3. Identify and select the existing AWS IAM programmatic user account referenced in pre-requisite B above.

4. For that user account, select Security Credentials.

5. Identify the previously-used access key.

6. Click the Actions menu. In the Actions menu, select Deactivate.

7. Confirm that you want to deactivate the previously-used access key.

Once deactivated, the previously-used access key should still be shown in the AWS console as a deactivated access key.

Note: This deactivated access key is still taking up a slot as one of the two access keys associated with the AWS IAM programmatic user account, so it will need to be deleted before you’ll be able to set up a new access key later. To delete a deactivated access key, use the procedure shown below:

1. Log into the AWS console.

2. Select the IAM service.

3. Identify and select the existing AWS IAM programmatic user account referenced in pre-requisite B above.

4. For that user account, select Security Credentials.

5. Identify the deactivated access key.

6. Click the Actions menu. In the Actions menu, select Delete.

7. Confirm that you want to delete the deactivated access key by entering the deactivated access key into the relevant text input field, then click the Delete button.

Once deleted, the deactivated access key’s listing is removed from the AWS console.

As part of making some screen recordings of app behavior recently, I noticed that the Notification Center notifications I was expecting to see weren’t appearing. As soon as I stopped making the screen recordings and replicated what I was doing, I saw the Notification Center notifications appear like they should.

After verifying that I hadn’t somehow enabled Focus or done something else to stop Notification Center notifications from appearing, I did some research which uncovered the solution. For more details, please see below the jump.

As part of the Notifications preferences in the Settings app, there is the following option:

Allow notifications when mirroring or sharing the display

This setting also apparently includes making screen recordings, because enabling it allowed Notification Center notifications to appear during screen recordings. To enable this setting, please use the following procedure:

1. Open Settings

2. Go to Notifications.

3. Enable the Allow notifications when mirroring or sharing the display setting.

You should now see notifications appearing while mirroring, sharing the display, or when making screen recordings.

As a follow-up to my earlier posts on managing Apple Intelligence features on macOS Sequoia 15.1 and 15.2 , Apple has added a couple of new management options for Apple Intelligence as part of the release of macOS Sequoia 15.3. For more details, please see below the jump.

As of macOS 15.3, management options are available for the following Apple Intelligence functionality:

• Genmoji
• Image Playground
• Writing Tools
• Summarizing emails
• Enabling Siri to connect to third party cloud-based intelligence services
• Managing non-anonymous login to third party cloud-based intelligence services
• Allowing third party cloud-based intelligence service workspace IDs
• Notes transcription summaries

The relevant key values are below:

It’s important to note that while all of the settings listed above work on macOS Sequoia 15.3, not all work on earlier versions of macOS Sequoia. Here’s the compatibility list:

macOS 15.0 and later:

• allowGenmoji
• allowImagePlayground
• allowWritingTools

macOS 15.1 and later:

• allowMailSummary

macOS 15.2 and later:

• allowExternalIntelligenceIntegrations
• allowExternalIntelligenceIntegrationsSignIn

macOS 15.3 and later:

• allowedExternalIntelligenceWorkspaceIDs
• allowNotesTranscriptionSummary

Most of these settings can be managed by a configuration profile, where setting a boolean value of false will disable the Apple Intelligence feature in question. The one exception at this point is the one for managing workspace IDs for allowed external intelligence integrations, which uses a string value. An example profile which allows one workspace ID is available below:

If you need to allow the use of multiple workspace IDs, an example profile which allows multiple workspace IDs is available below:

Please see below for example profiles. The example profiles are also available via the following links:

Note: If you’re planning to use the example profiles with Jamf Pro, it will need to be signed before it can be uploaded to Jamf Pro. If you’re not familiar with how to sign profiles, the post linked below is a good guide to how that process works:

https://macblog.org/sign-configuration-profiles/

• Genmoji: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableGenmoji
• Image Playground: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableImagePlayground
• Writing Tools: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableWritingTools
• Summarize emails: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableMailSummary
• Block Siri from connecting to third party cloud-based intelligence services: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableExternalIntelligenceIntegrations
• Disable non-anonymous login to third party cloud-based intelligence services: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableExternalIntelligenceLogins
• Allow external intelligence workspace IDs: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceAllowExternalIntelligenceWorkspaceID
• Notes transcription summaries: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableNotesTranscriptionSummary

Genmoji:

Image Playground:

Writing Tools:

Summarize emails:

Block Siri from connecting to third party cloud-based intelligence services:

Disable non-anonymous login to third party cloud-based intelligence services:

Allow external intelligence workspace IDs:

Notes transcription summaries:

One of the options available in Jamf Pro is creating user accounts which are specific to a Jamf Pro instance. These user accounts can be used for a variety of purposes, including service accounts and emergency use admin accounts for Jamf Pro’s failover functionality for SSO. One limitation of Jamf Pro standard user accounts is that as of this time the authentication option for Jamf Pro standard accounts is username and password. For Jamf Pro standard user accounts, you can set a password policy which allows you to configure the following options:

• Number of login attempts allowed before a Jamf Pro user is locked out of the account
• Password length and age
• Password reuse limitations
• Password complexity

However, the password is not the only option you’re setting when creating a Jamf Pro standard user. Assuming that this is an account not tied to a specific person (as would be the case for a service account or an emergency use admin account), you can set to the username to a long randomized string. This can help secure the account because an attacker needs both the username and password for an account in order to authenticate and the long randomized string should make it more difficult for an attacker to guess the username. For more details, please see below the jump.

The Jamf Pro standard user’s username field can support up to 255 characters. The username field itself supports using lowercase letters and numbers when creating usernames. Within this 255 character limit, you can set a very long randomized string as the username.

Note: The Jamf Pro standard user’s username field should be able to support more than lowercase letters and numbers, but in my experience usernames are normally set using lowercase letters and numbers, like this:

localadmin121

Usernames are usually not set using the following:

• UPPPERCASE LETTERS
• Special characters like the following: ! @ # $ % ^ & * ( ) – _ = + \ | [ ] { } ; : / ? . >

When folks historically don’t do something, it also usually means that there hasn’t been a lot of testing of those conditions. In turn, that may mean there’s yet-undiscovered problems which can crop up.

For this reason, I’m going to stick with only using lowercase letters and numbers in the examples used in this blog post. It’s possible the use of uppercase letters and special characters is just fine and setting a username like LOLRICHISWRONG!@()_ works without problems, but I’ll leave further experimentation on this topic to my readers and for this post stick with a format which I see the least problems with: lowercase letters and numbers.

To leave some room in the character limit, let’s generate a username which is 250 characters long which is a randomized string of lowercase letters and numbers. You can do this using the following command:

Note: The export LC_CTYPE=C.UTF-8 part of the command is there because the tr command will otherwise return tr: Illegal byte sequence on macOS when working with /dev/urandom‘s output:

https://andres.jaimes.net/linux/random-string/

That command should return a 250 character string like the one shown below:

You can then use that string when creating a Jamf Pro standard user.

Beginning with macOS Ventura, Apple’s Mail app adds a rich link preview when you’re composing an email and paste a web address into the email window. For example, here’s how it looks when I paste the following URL into a new email:

https://wwww.apple.com

For those who find this behavior undesirable and wish to turn it off, it can be disabled using the following process:

1. Launch Mail

2. Under the Mail menu, select Settings.

3. In the Settings window, select the Composing option.

4. Uncheck the Add link previews option.

With this option disabled, here’s how it looks when I paste the following URL into a new email:

https://wwww.apple.com

I have not found a way to disable the Add link previews option in Apple’s Mail app on macOS Sequoia using a defaults command, but it is possible to disable the Add link previews option 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.mail
• Key: AddLinkPreviews
• Value: Boolean

Setting a boolean value of false will disable the Add link previews option in Apple’s Mail app on macOS Sequoia. I’ve built a configuration profile with the boolean value of false set, where the profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/main/AppleMailDisableLinkPreviews

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac and sometimes also after an OS update. Apple added a new Welcome to Mac screen as part of macOS Sequoia. This screen appears before you are given access to the Desktop.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Welcome to Mac 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: Welcome

The profile is available on GitHub via the link below:

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

One of the challenges in figuring out why a Mac isn’t responding to MDM commands is sometimes just figuring out if the Mac is receiving MDM commands at all. Fortunately, this is possible to figure out via the unified system logging using the right predicates when searching. For more details, please see below the jump.

To start, send an MDM 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:

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 include a log entry that looks similar to this:

Since we can see from the log entry that the relevant process is mdmclient and the string to search for includes “Processing server request: DeclarativeManagement for“, then if you know 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:

From there, we can see the UUID identifier of the MDM command. In this example, the UUID is the following:

We can then use that to figure out from the Mac’s side if the MDM command was successful by running the following command:

From there, we should see output that looks similar to what’s shown below:

If the blank push command was successful, we should see three log entries like the ones that showed up in the output above:

Different MDM commands will have different output, but if you’re using Jamf Pro and need to figure out if a particular Mac is receiving MDM commands successfully, the process described above should assist with this. If you want to stream the logs in real time, so that you can check the logs as you’re sending a blank push command, you can use the following:

That should provide output similar to what’s shown below when you send a blank push:

Hat tip to Bryson and his teammates for figuring out most of this and sharing it with me.

As part of supporting Jamf Pro‘s API functionality, Jamf has made interactive documentation pages available with every Jamf Pro installation via the following address:

https://jamf.pro.server.here/api

When choosing to view the Classic API or Jamf Pro API documentation, there’s an option to log in and authenticate, so that you can run API commands interactively to see how running the commands works in real time and what results you see. This functionality is also useful when setting up API accounts with least privileged access, as it allows testing to verify that all necessary privileges have been assigned to the accounts.

Up until now, this authentication mechanism only supported using username and password authentication but as of Jamf Pro 11.2.0, the authentication mechanism now supports both of the following authentication methods:

• Username/Password authentication
• API client authentication

To use your preferred authentication method, please select it from the relevant drop-down menu.