The Package. Mac OS

  1. Mac Os Package Manager
  2. How To Install The MacOS Big Sur Public Beta MacRumors ...
  3. Macos - Install Dmg Package On MAC OS From Terminal - Stack ...
-->

Operating system: Mac, Windows. Price: $195/month, $1,260/year. Try out the free trial! The package structure and complexity is hidden from the user and they can't accidentally move a file that renders the IDE unusable. In this section we'll look more closely at the package structure and how to create a Mac OS X application whether or not our build machine is a Mac. Packages in Mac OS X.

Note

This documentation explains the legacy method for deploying and configuring Microsoft Defender for Endpoint on macOS devices. The native experience is now available in the MEM console. The release of the native UI in the MEM console provide admins with a much simpler way to configure and deploy the application and send it down to macOS devices.
The blog post MEM simplifies deployment of Microsoft Defender for Endpoint for macOS explains the new features. To configure the app, go to Settings for Microsoft Defender for Endpoint on macOS in Microsoft InTune. To deploy the app, go to Add Microsoft Defender for Endpoint to macOS devices using Microsoft Intune.

Applies to:

This topic describes how to deploy Microsoft Defender for Endpoint on macOS through Intune. A successful deployment requires the completion of all of the following steps:

Prerequisites and system requirements

Before you get started, see the main Microsoft Defender for Endpoint on macOS page for a description of prerequisites and system requirements for the current software version.

Overview

The following table summarizes the steps you would need to take to deploy and manage Microsoft Defender for Endpoint on Macs, via Intune. More detailed steps are available below.

StepSample file namesBundleIdentifier
Download installation and onboarding packagesWindowsDefenderATPOnboarding__MDATP_wdav.atp.xmlcom.microsoft.wdav.atp
Approve System Extension for Microsoft Defender for EndpointMDATP_SysExt.xmlN/A
Approve Kernel Extension for Microsoft Defender for EndpointMDATP_KExt.xmlN/A
Grant full disk access to Microsoft Defender for EndpointMDATP_tcc_Catalina_or_newer.xmlcom.microsoft.wdav.tcc
Network Extension policyMDATP_NetExt.xmlN/A
Configure Microsoft AutoUpdate (MAU)MDATP_Microsoft_AutoUpdate.xmlcom.microsoft.autoupdate2
Microsoft Defender for Endpoint configuration settings
Note: If you're planning to run a third-party AV for macOS, set passiveMode to true.		MDATP_WDAV_and_exclusion_settings_Preferences.xmlcom.microsoft.wdav
Configure Microsoft Defender for Endpoint and MS AutoUpdate (MAU) notificationsMDATP_MDAV_Tray_and_AutoUpdate2.mobileconfigcom.microsoft.autoupdate2 or com.microsoft.wdav.tray

Download installation and onboarding packages

Download the installation and onboarding packages from Microsoft Defender Security Center:

  1. In Microsoft Defender Security Center, go to Settings > Device Management > Onboarding.

  2. Set the operating system to macOS and the deployment method to Mobile Device Management / Microsoft Intune.

  3. Select Download installation package. Save it as wdav.pkg to a local directory.

  4. Select Download onboarding package. Save it as WindowsDefenderATPOnboardingPackage.zip to the same directory.

  5. Download IntuneAppUtil from https://docs.microsoft.com/intune/lob-apps-macos.

  6. From a command prompt, verify that you have the three files.

  7. Extract the contents of the .zip files:

  8. Make IntuneAppUtil an executable:

  9. Create the wdav.pkg.intunemac package from wdav.pkg:

Client device setup

You don't need any special provisioning for a Mac device beyond a standard Company Portal installation.

  1. Confirm device management.

    Select Open System Preferences, locate Management Profile on the list, and select Approve.... Your Management Profile would be displayed as Verified:

  2. Select Continue and complete the enrollment.

    You may now enroll more devices. You can also enroll them later, after you have finished provisioning system configuration and application packages.

  3. In Intune, open Manage > Devices > All devices. Here you can see your device among those listed:

Approve System Extensions

To approve the system extensions:

  1. In Intune, open Manage > Device configuration. Select Manage > Profiles > Create Profile.

  2. Choose a name for the profile. Change Platform=macOS to Profile type=Extensions. Select Create.

  3. In the Basics tab, give a name to this new profile.

  4. In the Configuration settings tab, add the following entries in the Allowed system extensions section:

    Bundle identifierTeam identifier
    com.microsoft.wdav.epsextUBF8T346G9
    com.microsoft.wdav.netextUBF8T346G9

  5. In the Assignments tab, assign this profile to All Users & All devices.

  6. Review and create this configuration profile.

Create System Configuration profiles

  1. In Intune, open Manage > Device configuration. Select Manage > Profiles > Create Profile.

  2. Choose a name for the profile. Change Platform=macOS to Profile type=Custom. Select Configure.

  3. Open the configuration profile and upload intune/kext.xml. This file was created in one of the preceding sections.

  4. Select OK.

  5. Select Manage > Assignments. In the Include tab, select Assign to All Users & All devices.

  6. Repeat steps 1 through 5 for more profiles.

  7. Create another profile, give it a name, and upload the intune/WindowsDefenderATPOnboarding.xml file.

  8. Download fulldisk.mobileconfig from our GitHub repository and save it as tcc.xml. Create another profile, give it any name and upload this file to it.

    Caution

    macOS 10.15 (Catalina) contains new security and privacy enhancements. Beginning with this version, by default, applications are not able to access certain locations on disk (such as Documents, Downloads, Desktop, etc.) without explicit consent. In the absence of this consent, Microsoft Defender for Endpoint is not able to fully protect your device.

    This configuration profile grants Full Disk Access to Microsoft Defender for Endpoint. If you previously configured Microsoft Defender for Endpoint through Intune, we recommend you update the deployment with this configuration profile.

  9. As part of the Endpoint Detection and Response capabilities, Microsoft Defender for Endpoint on macOS inspects socket traffic and reports this information to the Microsoft Defender Security Center portal. The following policy allows the network extension to perform this functionality. Download netfilter.mobileconfig from our GitHub repository, save it as netext.xml and deploy it using the same steps as in the previous sections.

  10. To allow Microsoft Defender for Endpoint on macOS and Microsoft Auto Update to display notifications in UI on macOS 10.15 (Catalina), download notif.mobileconfig from our GitHub repository and import it as a custom payload.

  11. Select Manage > Assignments. In the Include tab, select Assign to All Users & All devices.

Once the Intune changes are propagated to the enrolled devices, you can see them listed under Monitor > Device status:

Publish application

  1. In Intune, open the Manage > Client apps blade. Select Apps > Add.

  2. Select App type=Other/Line-of-business app.

  3. Select file=wdav.pkg.intunemac. Select OK to upload.

  4. Select Configure and add the required information.

  5. Use macOS High Sierra 10.14 as the minimum OS.

  6. Set Ignore app version to Yes. Other settings can be any arbitrary value.

    Caution

    Setting Ignore app version to No impacts the ability of the application to receive updates through Microsoft AutoUpdate. See Deploy updates for Microsoft Defender for Endpoint on macOS for additional information about how the product is updated.

    If the version uploaded by Intune is lower than the version on the device, then the lower version will be installed, effectively downgrading Microsoft Defender for Endpoint. This could result in a non-functioning application. See Deploy updates for Microsoft Defender for Endpoint on macOS for additional information about how the product is updated. If you deployed Microsoft Defender for Endpoint with Ignore app version set to No, please change it to Yes. If Microsoft Defender for Endpoint still cannot be installed on a client device, then uninstall Microsoft Defender for Endpoint and push the updated policy.

  7. Select OK and Add.

  8. It may take a few moments to upload the package. After it's done, select the package from the list and go to Assignments and Add group.

  9. Change Assignment type to Required.

  10. Select Included Groups. Select Make this app required for all devices=Yes. Select Select group to include and add a group that contains the users you want to target. Select OK and Save.

  11. After some time the application will be published to all enrolled devices. You can see it listed in Monitor > Device, under Device install status:

Verify client device state

  1. After the configuration profiles are deployed to your devices, open System Preferences > Profiles on your Mac device.


  2. Verify that the following configuration profiles are present and installed. The Management Profile should be the Intune system profile. Wdav-config and wdav-kext are system configuration profiles that were added in Intune:

  3. You should also see the Microsoft Defender icon in the top-right corner:

Troubleshooting

Issue: No license found

Solution: Follow the steps above to create a device profile using WindowsDefenderATPOnboarding.xml

Logging installation issues

For more information on how to find the automatically generated log that is created by the installer when an error occurs, see Logging installation issues.

Uninstallation

See Uninstalling for details on how to remove Microsoft Defender for Endpoint on macOS from client devices.

Note: This post may be a little out of date as it was originally written in 2015. But I’m posting it here as the fundamentals have not really changed much.

Credits: Thanks to Gary Larizza for his post on AFP548.com where most of this documents content was sourced ( https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x )

When managing Mac OS X devices, you will enviably have to deploy files or applications to many devices. There are many ways to achieve this, however the most effective and best practice method is to use Packages.
While packaging is quite simple, it can very quickly become quite complex. This document serves to provide some guidelines to help you avoid some simple mistakes and prevent confusion when creating packages.

There are many tools out there used to create Packages, Apple offer their own built in command line tools like pkgbuild. This guide will not go into detail about how to use any of these tools, it is up to the system admin’s own personal preference on which tools they wish to use in order to create their packages.
However version control is very important, as is the ability to quickly and accurately create and recreate packages. The ability for packages to be peer reviewed and package versions to easily be diff’d is also important and the admin’s choice of tools should take this into account. It is also highly recommend that a version control system such as git is used in combination with package creation.
Below is a list of tools that are recommended for creating packages:

Mac Os Package Manager

Packages by Whitebox

A great GUI driven tool to create flat and distribution packages and provides an easy to learn GUI. It is still quite powerful and allows a great deal of control over how your packages are created. A build file is created which saves information on how the package should be created such as the payload, pre/post flight scripts, additional resources etc etc.

Cost: $0 – FREE

The Luggage

A completely text driven package building system perfect for use with version control systems such as Git. Files can easily be reviewed to see what will be in the package without any extra work.

The big benefit to using The Luggage is that because the packages are created with make files, these make files can easily be diff’d to see changes as well as talking other users through the creation process. No GUI panes to navigate.

Cost: $0 – FREE

Munki PKG

Munki PKG is a simple tool very similar to The Luggage which builds packages in a consistent, repeatable manner from source files and scripts in a project directory.

How To Install The MacOS Big Sur Public Beta MacRumors ...

Package.

Files, scripts and metadata are stored in a way that is easy to track and manage using a version control system like git.

Cost: $0 – FREE

Installation method

Your installer should not require any input from the end user.

Macos - Install Dmg Package On MAC OS From Terminal - Stack ...

DO NOT:

  • Assume that your package will be installed interactively via the GUI or to the currently booted volume. More often than not packages will be deployed to machines via management systems such as Munki or Casper. Because of this you should ensure that your package can be installed to machines that are unattended (at the login window without a console user logged in)

DO:

  • Ensure that your package can be installed via the command line and by any management framework with and without a user logged in.

Installation target

DO NOT:

  • Assume that your package will be installed to the currently booted volume. Your package might not necessarily be installed to the currently booted volume, so ensure that any scripts in your package use the correct variables passed to it from the installer application. For example, reference the target volume in your scripts by using the variable $3 (in bash) rather than using absolute file references.
  • Use tools such as sw_vers in order to get the Operating System version. These tools will only report the OS of the currently booted volume.

DO:

  • Check the SystemVersion.plist on the target volume ($3)
  • Check if the boot volume (/) is the same as the target volume ($3) if any of your scripts require it.

Unnecessary actions.

DO NOT:

  • Perform ‘helpful’ things like using osascript to open a Finder window showing your newly installed application. Similarly do not do things like opening a browser window to the installed software’s homepage.
  • The problem with these things is if you are installing the software in an unattended mode where the computer is at the LoginWindow, these types of things will simply cause errors in your installation process.
  • Require unnecessary reboots if you can accomplish the same thing by loading/unloading LaunchDaemons/LaunchAgents – If you go down this path, remember that it is even more important to check if you are installing to the boot volume or not.
  • Automatically add files to the Dock, Desktop or anywhere outside of /Applications or other required directories. If you wish to add Dock items, use another package/script/profile/tool to achieve that.
  • Ask for admin/elevated privileges if they are not needed for installation, i.e. installing into
    /Users/Shared
  • Create separate installers for different architectures/OS versions. If you have separate payloads for separate architectures/OS versions, perform your architecture/OS check on the target volume, not the currently booted operating system see rule 2.

DO:

  • Use a distribution meta-package to provide a single package that will correctly determine OS/Architecture of the destination volume and install the appropriate payload.

Licensing

Licensing should be managed by Systems Administrators. Wherever possible licensing files should be packaged separately to the application being deployed. This allows for a single application package to be deployed to multiple sites with different licensing files applied later depending upon the licence that is appropriate for that site.

Licensing information might be supplied via a global plist/config profile/KMS or other.

This also prevents unauthorised installation of software should your application package be obtained by a unauthorised third party.

DO NOT:

  • Place licensing and registration files in the user’s home directory wherever possible. Use a global location such as /Library
  • Building licensing/registration mechanisms into the installer GUI.

DO:

  • Allow a scriptable licensing interface to your software

Pre/Post install scripts

Use pre and post install scripts only when necessary, and follow all other rules with your scripts.

For example, it would be silly to use a package to install some files on disk and then use a post install script to set the permissions of those files. Instead correctly set the permissions of the files in the payload.

This also allows for reviewing of package contents via lsbom

DO NOT:

  • Use postinstall scripts to create or modify files – do this in the package payload.
  • If you must use post-install scripts, do not use osascript to move and copy files. Use CLI tools such as cp and mv in bash
  • Use any kind of GUI scripting, see Rule 1.
  • Use sudo in your scripts, your script is already running as root.

DO:

  • Exit your script with 0 on success, or non-zero on failure.
  • Trap error codes in your scripts
  • Use globbing in your scripts, because no one likes repetition and computers are built to do the work for us so let them.
  • Ensure your scripts handle paths with spaces in them.

Naming Conventions and Version Numbers

Naming conventions are necessary and helpful. For example VPN.pkg is NOT helpful.

Give your packages meaningful names and version numbers. Providing vendor and product name, along with important version numbers and vendor identification codes.

DO:

  • List your vendor and product name in your package name
  • Give packages meaningful names with version numbers. Remember 1.15 is greater than 1.2 in most situations.

Supporting Operating System Versions

If you are going to supporting running your application or payload on operating systems back to say version 10.8, then it should go without saying that you need to TEST your package on every version from 10.8 to the most current.

DO NOT:

  • Change the ownership and permissions of core Operating System folders and files

DO:

  • Keep your config data and cache data separate
  • Follow the directory structure mandated by the target platforms software deployment guidelines
  • Provide an uninstaller or uninstall script
  • Use the documented OS X .pkg format and not just a .pkg wrapper for a 3rd party solution that installs the software for you – obvious exception for Adobe software.

Be Descriptive

Even if you are not planning on having your package installed via the GUI you should still make it GUI-friendly.

DO:

  • Provide a welcome message, read-me, description of whats happening and whats being installed.
  • Comment your pre/post install scripts thoroughly.

Snapshotting and Re-Packaging

Try to avoid using Snapshot methods to create packages – a common tool used to create snapshot packages is JAMF’s composer.

Snapshotting is generally considered bad juju and the result of a lazy (not in a good way) sysadmin

Packages created from snapshots lack the nuances and intent of the original package. They can often miss critical files or modifications to the file system.

If you are unable to use a vendor package, consider the following:

DO:

  • Attempt to unpack and reverse engineer the package – Use tools such as Pacifist (https://www.charlessoft.com/) and pkgutil –expand to determine what the package is attempting to achieve.
  • Try to modify the existing vendor package using things like providing a custom Choices.XML to select certain packages in a meta/distribution package for installation.

Product Signing

Gatekeeper was introduced in 10.8 as a way to alert users to unsigned packages. For this reason, it is best practice to sign your installer packages with a developer ID certificate that lets your users know your packages can be trusted. It also allows packages to be installed in the GUI when Gatekeeper is configured to allow apps downloaded from the App Store and identified developers

Unsigned packages are not an issue when not using the GUI installer however.

DO:

  • Use productsign to sign your packages with an Apple Developer ID certificate