Policy Mapping Architecture

Technical deep dive into converting Apple mobileconfig payloads to Microsoft Intune Settings Catalog format.

The Challenge

Organizations migrating from Apple Configurator/Profile Manager to Microsoft Intune face a significant challenge: hundreds of existing mobileconfig policies need manual recreation in Intune's Settings Catalog.

Each policy requires understanding both Apple's plist format and Intune's JSON structure, then manually mapping individual settings. This hackathon project demonstrates automated conversion between these formats.

Dual Conversion Strategy

🤖 Data-Driven Conversion

Leverages Apple's official YAML specifications

Source: Apple's device-management repository
Coverage: ~15 standardized payload types
Benefits: Deprecation detection, type validation
Limitation: Only officially documented payloads

📋 Legacy Pattern Conversion

Handles undocumented and custom payloads

Method: Pattern-based key transformation
Coverage: Any mobileconfig payload
Benefits: Broad compatibility, extensible
Limitation: No deprecation awareness

Hybrid Approach: The system runs both converters and merges results, providing maximum coverage while detecting deprecated Apple settings.

Apple YAML Specification Processing

Repository Structure Analysis

github.com/apple/device-management/

└── mdm/profiles/

├── com.apple.applicationaccess.yaml

├── com.apple.mobiledevice.passwordpolicy.yaml

└── com.apple.screensharing.yaml

Each payload type has a dedicated YAML specification file
Specifications include key definitions, types, constraints, and deprecation info
Repository is cached locally for performance and offline capability
Automated updates sync latest Apple policy changes

Deprecation Detection Engine

Example: allowPhotoStream

supportedOS:
  iOS:
    deprecated: "17.0"
    removed: "18.0"
payloadKeys:
  allowPhotoStream:
    type: boolean
    deprecatedIn: "17.0"

Parses supportedOS sections for platform deprecation info
Tracks individual key deprecation from payloadKeys definitions
Provides visual warnings for settings unlikely to work in modern iOS/macOS
Enables filtering deprecated settings from exported policies

Custom Conversion Logic

TCC (Transparency, Consent, and Control) Converter

Privacy payloads require specialized handling due to complex service-app combinations:

Input Structure:

<key>Services</key>
<dict>
  <key>Camera</key>
  <array>
    <dict>
      <key>BundleID</key>
      <string>com.apple.camera</string>
      <key>Allowed</key>
      <true/>
    </dict>
  </array>
</dict>

Conversion Logic:

Flatten service → app combinations into individual settings
Generate setting IDs: tcc_{service}_{bundleId}
Map permission values to Intune choice instances
Handle both allow/deny policies and per-app granularity

Array Processing Pipeline

Simple Arrays

Example: blacklistedAppBundleIDs

→ Converted to SimpleCollection with individual StringSettingValue entries

Complex Arrays

Example: Font definitions, WiFi configurations

→ Converted to GroupSettingCollectionInstance with nested property structures

Intune Settings Catalog Structure

JSON Architecture

Policy Container

{
  "id": "uuid-generated",
  "name": "Converted: {original-policy-name}",
  "platforms": "iOS",
  "technologies": "mdm",
  "settings": [...]
}

Setting Instance Types

choiceSettingInstance - Boolean values, enums
simpleSettingInstance - Strings, integers
groupSettingCollectionInstance - Complex objects
simpleSettingCollectionInstance - Arrays

Setting ID Generation

Algorithm

settingDefinitionId = payloadType + "_" + keyName

Apple mobileconfig

PayloadType:

com.apple.mobiledevice.passwordpolicy

Key: allowSimple

Intune Setting ID

com.apple.mobiledevice.passwordpolicy_allowSimple

Note: These IDs are placeholders for demonstration. Production implementation would map to actual Intune Settings Catalog definition IDs.

Conversion Coverage

~85%

Successfully Converted

Standard policy settings

~10%

Deprecated

iOS 15+ deprecated keys

~5%

Unsupported

Complex structures

Key Findings

✅ What Works Well

Apple's YAML specifications provide excellent automation foundation
Most boolean and simple value settings convert cleanly
Deprecation data enables proactive policy modernization
Pattern-based fallback handles edge cases gracefully

⚠️ Challenges Discovered

Complex nested structures require manual handling
Some payload types lack Apple YAML documentation
Intune Settings Catalog IDs are not publicly documented
Array-to-collection mapping needs refinement

🚀 Production Viability

80%+ automation rate significantly reduces migration effort
Deprecation warnings prevent deploying obsolete settings
Clear reporting enables focused manual review
Architecture supports integration with Graph API