How Windows Mobile 6.5 Processed Active Directory GPOs

Windows Mobile 6.5 did not process standard desktop Group Policy Objects (GPOs) natively through direct Active Directory domain membership; instead, it relied on intermediate management systems to translate Active Directory policies into mobile-compatible instructions. By utilizing either System Center Mobile Device Manager (SCMDM) 2008 or Exchange ActiveSync, enterprise policies defined within Active Directory were converted into Open Mobile Alliance Device Management (OMA-DM) XML or ActiveSync commands, which the mobile operating system's internal Configuration Service Providers (CSPs) then applied directly to the device.

The Architectural Limitation of Windows Mobile 6.5

Standard Windows desktop platforms run a Group Policy engine that authenticates against domain controllers via Kerberos or NTLM and queries policy containers via LDAP and SMB. Windows Mobile 6.5 lacked the native domain-join subsystem, the Winlogon infrastructure, and the desktop Group Policy client service. Consequently, it could not communicate directly with an Active Directory Domain Services (AD DS) controller to read or process Group Policy files from the SYSVOL directory.

Processing via System Center Mobile Device Manager (SCMDM)

To enforce true Active Directory GPOs on Windows Mobile 6.5, Microsoft introduced System Center Mobile Device Manager (SCMDM) 2008. SCMDM served as the architectural bridge between Active Directory and the mobile platform:

  1. Domain Object Registration: When a Windows Mobile 6.5 device enrolled through SCMDM, it established a trust relationship using public key infrastructure (PKI) certificates. SCMDM registered the device in Active Directory as a specialized mobile device account (similar to a computer object), placing it into a designated Organizational Unit (OU).
  2. GPO Authoring and Association: Administrators used the standard Group Policy Management Console (GPMC) with custom mobile administrative templates (ADMX) to define settings such as password requirements, device encryption, Wi-Fi profiles, and hardware restrictions (e.g., disabling the camera or Bluetooth).
  3. Policy Translation: The SCMDM Device Management Server (DMS) queried Active Directory for the GPOs linked to the device’s OU. The DMS intercepted these standard Windows Group Policy rules and translated them into SyncML, an XML-based format defined by the OMA-DM standard.
  4. Transport over Mobile VPN: The translated policies were pushed to the device across a secure, persistent IPsec Mobile VPN tunnel maintained between the device and the SCMDM Gateway Server.

Execution via Configuration Service Providers (CSPs)

Once the device received the OMA-DM payload, the local processing execution took place through the Windows Mobile Configuration Manager:

  • The OMA-DM Client: A built-in service in Windows Mobile 6.5 received the XML package, verified the digital signature using local certificates, and parsed the commands.
  • Targeting CSPs: The client routed specific settings to designated Configuration Service Providers (CSPs). CSPs were operating system interfaces responsible for reading and writing specific configuration interfaces.
    • SecurityPolicy CSP: Managed lock states, PIN complexity, and application execution privileges.
    • Registry CSP: Modified system and user keys directly under HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER.
    • Certificate CSP: Installed root and user certificates into the mobile certificate store.
    • Metabase CSP: Handled communications and network configurations.
  • Status Feedback: After the CSPs altered the registry or triggered system changes, the OMA-DM client sent a status response back through the VPN to the SCMDM server, which updated the compliance status within Active Directory reporting tools.

Alternative Lightweight Processing: Exchange ActiveSync (EAS)

For organizations without SCMDM infrastructure, policy distribution from Active Directory was handled via Exchange ActiveSync. Administrators configured mobile device mailbox policies within Microsoft Exchange, which stored those attributes in the Active Directory schema associated with user objects.

When the Windows Mobile 6.5 device synchronized over HTTPS:

  1. The Exchange server read the policy attributes assigned to the user in Active Directory.
  2. Exchange converted these attributes into WBXML (WAP Binary XML) over the AirSync protocol.
  3. The native messaging client on Windows Mobile 6.5 interpreted the provisioning commands.
  4. The client dispatched the parameters to the local CSPs to enforce baseline policies, such as remote wipe, storage card encryption, and alphanumeric PIN enforcement, refusing mailbox synchronization if the device failed to satisfy the requirements.