Products

IT Management Suite

Issue/Introduction

This is a call-ready checklist for validating a macOS MDM setup before starting enrollments. Run it before a new macOS MDM rollout, or when troubleshooting a stalled or failing enrollment. It walks through the key items to confirm that everything is set up, reachable, and working. Use it during case notes, Teams calls, or any troubleshooting session to confirm all requirements are in place before proceeding.

This checklist covers macOS MDM only. Windows MDM in ITMS is agentless and uses a different setup process; see Setting up MDM for Windows.

Environment

ITMS 8.6 and later

Resolution

Symantec MDM for macOS – Setup Validation Checklist

How it works

The macOS MDM server is a Linux host (Red Hat, Ubuntu, or Oracle Linux, depending on release; see the Platform Support Matrix) that channels communication between the ITMS SMP (Symantec Management Platform or Notification Server (NS)) Server and Apple's APNS service, and between MDM-managed devices and the SMP Server. It can sit in your DMZ with a direct public FQDN, or behind your firewall, in which case an Internet Gateway relays traffic between devices and the MDM server.

Three certificates secure this path, and each does a different job:

☐ APNS certificate: lets the MDM server talk to Apple's push service. CSR generated in the SMP console, signed by Broadcom Support, then submitted to Apple.

☐ Server (SSL) certificate: lets managed devices trust the MDM server itself. Issued by a public CA to the server's own FQDN; self-signed is not accepted.

☐ Code Signing certificate: optional, but recommended. Signs the profiles pushed to devices so they show Verified instead of Unsigned in System Preferences. Issued by a CA trusted by Apple; Broadcom is not involved in signing this one.

Enrollment itself is pull-based, not push-based. An admin copies an enrollment URL from MDM - macOS > Servers and shares it with users, who click it and accept the profile. There is no separate targeted “enrollment policy” step in the documented workflow. Targeting applies to policies distributed after enrollment, such as profiles and app installs, not to enrollment itself.

Use this checklist to validate each component of the macOS MDM setup. Enrollment should not proceed until all items pass.
NOTE: This checklist is provided as a simple reference and not a definitive in-deep checklist.

Each item includes a How step: where it's grounded in TechDocs, that's noted; where it relies on standard OpenSSL, shell, or SMP Console practice rather than a published Broadcom procedure, that's noted too, so nothing here reads as more official than it is.

To get to the main MDM - macOS configuration pages, on the SMP Console, go to Home > Apple Modern Device Management

Apple Requirements Validation

APNS Certificate

☐ Verify APNS certificate is present in ITMS

How: MDM - macOS > Certificates in the SMP console. Look for an entry with category APNS.

☐ Confirm certificate is not expired

How: Check the expiry date shown in that same Certificates list.

☐ Confirm certificate was created with the correct Apple ID

How: ITMS doesn't display which Apple ID was used. Confirm with whoever ran the CSR and Apple upload, or check the Apple ID used to log into the Apple Push Certificates Portal below.

☐ Confirm Apple Push Certificates Portal shows the same certificate expiry date

How: Log in to identity.apple.com/pushcert with that Apple ID and compare its expiry date to the one shown in ITMS.

Obtain an Apple APNS Certificate (broadcom.com)

Code Signing & MDM Certificate Validation

MDM Code Signing Certificate

☐ Confirm private/public key pair exists (OpenSSL or your chosen CA's process)

How: Via OpenSSL: confirm the .key file used to generate the CSR still exists, and that openssl x509 -noout -modulus -in cert.pem | openssl md5 matches openssl rsa -noout -modulus -in key.pem | openssl md5. Via a CA's own tooling, check the CA's portal for the matching key record.

☐ Confirm CSR was generated properly

How: openssl req -text -noout -verify -in yourfile.csr shows the CN and confirms the CSR isn't corrupted.

☐ Confirm a CA trusted by Apple returned a valid signing certificate

This certificate is issued by a CA trusted by Apple, not by Broadcom or an internal CA. Broadcom signs only the APNS certificate's CSR; it isn't part of the Code Signing certificate chain.

How: openssl x509 -text -noout -in cert.pem, check the Issuer and validity dates.

☐ Confirm signing certificate imports without errors

How: MDM - macOS > Certificates > Add New, select Intermediate as the category, browse to the file, click OK. Any import error surfaces in the SMP console at that point.

☐ Confirm code-signing certificate appears as valid in ITMS

How: Check the status shown for that certificate in the Certificates list after import.

MDM Server SSL Certificate

☐ Verify certificate CN/SAN matches the MDM FQDN

How: openssl x509 -in cert.pem -noout -text, check the Subject and Subject Alternative Name against the MDM server's own FQDN.

☐ Confirm certificate chain includes intermediates

How: openssl verify -CAfile fullchain.pem cert.pem, or open the PEM file directly and confirm more than one certificate block is present.

☐ Confirm certificate + private key imported successfully on Linux MDM server

How: Not published in TechDocs. Confirm with whoever configured the server, or check the server's status in MDM - macOS > Servers, which reflects import status in the SMP console.

☐ Validate “full chain” format is correct (PEM order)

How: openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout lists the certificates in the file in order. The server certificate should come first, then intermediates, then root.

Certificate Chain Consistency

☐ Validate SMP, Linux MDM server, and IGW all present the same trust chain

How: openssl s_client -connect <host>:443 -showcerts against each of the three, and compare the chains returned.

☐ Confirm no old/duplicate certificates exist (KB Failed to import MDM Server certificate “The certificate with thumbprint <cert thumbprint> already exists” scenario)

How: MDM - macOS > Certificates, scan for duplicate thumbprints. See KB 256647 if you hit the specific “already exists” error.

Failed to import MDM Server certificate – thumbprint already exists (KB256647)

Obtaining a Signing Certificate – see Step 4 (broadcom.com)

Obtain a Server Certificate for the MDM Server (broadcom.com)

Linux MDM Server Validation

Service & Configuration

☐ Confirm Linux OS version is supported for this ITMS release

How: cat /etc/os-release on the server, compare against the Platform Support Matrix below.

IT Management Suite Platform Support Matrix (broadcom.com)

☐ Verify all MDM services start successfully

☐ Check systemctl status for Broadcom MDM services

How: The exact service name isn't published in TechDocs. Confirm it with whoever installed the server, or list candidates with systemctl list-units | grep -i mdm.

☐ Confirm certificate directories/permissions correct

☐ Validate server connectivity to SMP (ping/FQDN resolution)

How: ping <SMP FQDN> and getent hosts <SMP FQDN> (or nslookup) from the MDM server.

Network & Connectivity

☐ Validate Linux MDM server can resolve:

- SMP internal FQDN
- IGW external FQDN (if used)

How: getent hosts <FQDN> or nslookup <FQDN> from the MDM server, for each name.

☐ Test HTTPS access to the MDM endpoints

How: curl -vI https://<endpoint> from the MDM server. Look for a completed TLS handshake, not necessarily a 200 response.

☐ Confirm outbound traffic to APNS on TCP/443 is allowed

This port is fixed for MDM traffic specifically and is not configurable, unlike the general Internet Gateway port. Corporate firewalls often allow 443 broadly but block Apple's specific IP ranges. See Apple's current APNS IP blocks below.

How: nc -zv gateway.push.apple.com 443 or openssl s_client -connect gateway.push.apple.com:443 from the MDM server.

Apple KB HT203609 – APNS IP address ranges

☐ Validate no SSL interception by proxies

How: Compare the Issuer shown by openssl s_client -connect <host>:443 -showcerts against the real CA. If it shows your own company's CA instead, a proxy is intercepting the connection.

Setting up and Configuring the MDM Server (broadcom.com)

Internet Gateway (If used)

IGW Configuration

☐ Confirm IGW installed and running

How: The Internet Gateway runs on Windows. Check the Symantec Management Platform Internet Gateway service in services.msc, or Get-Service in PowerShell.

☐ Confirm IGW external FQDN matches the certificate

How: openssl s_client -connect <IGW-FQDN>:443 -servername <IGW-FQDN>, check the Subject and SAN against the FQDN.

☐ Validate certificates installed correctly on IGW

How: Symantec Management Platform Internet Gateway Manager > Servers tab. Confirm the certificate is listed against the MDM server entry.

☐ Confirm IGW can reach SMP and Linux MDM server

How: From the IGW host: Test-NetConnection <FQDN> -Port 443 in PowerShell, against both the SMP and the MDM server.

☐ Validate external reachability via https://<FQDN>/mdm

How: Open that URL from outside the network, either in a browser or with curl -vI. Expect a TLS handshake and a response from the MDM endpoint; a timeout usually means the Gateway or an upstream firewall isn't forwarding traffic correctly.

Configuring the Internet Gateway with macOS (broadcom.com)

SMP (Symantec Management Platform) Validation

Modern Device Management Settings

☐ Verify ITMS version supports MDM

How: Help > About in the Symantec Management Console, or check the Platform Support Matrix.

☐ Confirm MDM server configured and showing “healthy”

How: MDM - macOS > Servers, check the status column for that server.

☐ Check that the MDM code signing certificate is recognized

How: MDM - macOS > Certificates, confirm the signing certificate shows as valid.

Enrollment Policy Setup

☐ Confirm the enrollment URL is correct (copied from MDM - macOS > Servers)

How: MDM - macOS > Servers, open the ellipsis menu on the server entry, select Copy Enrollment URL.

☐ Confirm the enrollment URL has been shared with the intended users

☐ Confirm enrollment URL is accessible externally & internally

How: Open the URL yourself from both inside and outside the network before sending it to users.

Distributing MDM Enrollment Policy (broadcom.com)

macOS Device Validation (Pre-enrollment)

Device State

☐ macOS version supported for this ITMS release (macOS 11–14 as of the current Platform Support Matrix)

How: Apple menu > About This Mac on the device.

IT Management Suite Platform Support Matrix (broadcom.com)

☐ Device time/date correct

How: System Settings > General > Date & Time. Confirm “Set automatically” is on, or the clock is otherwise correct; a device clock that's significantly off can cause certificate validation failures during enrollment.

☐ Device not enrolled in another MDM

How: System Settings > Profiles, look for an existing management profile. Or in Terminal: profiles status -type enrollment.

☐ Keychain trust store does not contain conflicting certificates

How: Open Keychain Access and search for the MDM/APNS-related certificate names, checking for duplicates or expired entries. Or in Terminal: security find-certificate -a.

Connectivity Tests

☐ Device can reach:

- https://<FQDN>
- https://<FQDN>/mdm
- Apple APNS servers

How: Open each URL in Safari, or curl -vI <url> from Terminal, for each of the three.

☐ No firewall or Wi-Fi filtering blocking enrollment

How: If enrollment only fails on the corporate network, test from a different network (a personal hotspot, for example) to isolate whether local filtering is the cause.

Profile Installation Readiness

☐ Confirm the user has administrator rights

How: System Settings > Users & Groups, confirm the account type is Administrator.

☐ Confirm System Settings → Profiles can install unsigned/signed profiles normally

How: Install any benign .mobileconfig profile as a smoke test before attempting the real enrollment profile.

Functional Tests (Performed During the Call)

Test 1 — Enrollment Profile Download

☐ Validate the enrollment URL prompts profile download

How: Open the enrollment URL in Safari on the test Mac.

☐ Confirm profile shows signed status

How: System Settings > Profiles, select the profile, check the verification line.

☐ If it shows “unsigned”, check:

- Code signing certificate
- Certificate chain
- SMP/IGW FQDN mismatch
- Each of these is covered under sections 2 and 4 above.

Test 2 — Enrollment Completion

☐ Install profile and confirm:

- Device appears in ITMS
  How: MDM - macOS > Devices in the SMP console, after allowing time for the device to check in.
- MDM GUID stable
- No GUID resets (ref. KB 271514, “Agents continually resetting GUIDs”)
  How: In Terminal on the device: profiles show -type enrollment shows the device's enrollment ID; compare it across repeated checks. Repeated re-enrollment or a resource merging with another device's GUID in ITMS is the pattern KB 271514 addresses.
  
  Note: KB 271514's specific remediation (deleting the OMADM MDMDeviceID registry key) is Windows-specific. Its GUID-conflict diagnosis, shared GUIDs across machines and blacklisting duplicates, is the relevant part for a macOS case.

Agents continually resetting GUIDs (KB271514)

Test 3 — Basic MDM Commands

☐ Lock device test (if allowed)

How: MDM - macOS > Devices, select the device, use the Lock action from the Actions menu.

☐ Profile push test

How: Create or assign a policy targeting the test device, then confirm it appears under System Settings > Profiles on the Mac.

☐ Application push test (optional)

How: Same mechanism as the profile push, targeting an imported application package instead.

Test 4 — Log Validation

☐ Collect macOS profiles debug output

How: In Terminal on the device: sudo profiles show -type enrollment -verbose. For live output while reproducing an issue: log stream --predicate 'subsystem == "com.apple.ManagedClient"'.

☐ Check Linux MDM logs for enrollment events

How: The MDM service's own log path isn't published in TechDocs. The general Symantec Management Agent log on Linux lives under /opt/altiris/notification/nsagent/var/ (per KB156111); confirm with Dev whether the MDM service itself logs elsewhere.

ITMS location of log files (KB156111)

☐ Confirm no TLS or certificate chain errors

How: Search whatever log source the previous step points to for TLS, handshake, or certificate errors.