Windows Mobile 6.5 GAL Search Over Mobile Networks
Windows Mobile 6.5 relied on the Exchange ActiveSync (EAS) protocol to perform remote Global Address List (GAL) lookups over mobile data networks. Rather than synchronizing the entire corporate directory locally—which would overwhelm mobile bandwidth and the device's limited internal storage—the operating system sent targeted, on-demand search queries directly to an enterprise Microsoft Exchange Server. This article explains the technical workflow, protocols, network mechanisms, and data handling Windows Mobile 6.5 utilized to search the GAL over cellular connections.
The Exchange ActiveSync (EAS) Search Command
The foundation of GAL lookups in Windows Mobile 6.5 was the Exchange
ActiveSync Search command. Introduced and refined across
EAS versions (notably EAS 12.0 and 12.1 associated with Exchange Server
2007 and 2010), this command allowed mobile clients to query the
server-side directory dynamically.
When a user typed a query into the contact search field or the "To" line of a new email and selected "Search Company Directory," the device did not reference the local contact database. Instead, it triggered an outgoing request over the active cellular data connection (GPRS, EDGE, HSDPA, or 3G).
The Step-by-Step Lookup Process
- User Initiation: A user initiated a search in the Windows Mobile Contacts application or the Messaging (Outlook Mobile) application by entering characters (typically a minimum of three) representing a name, alias, or email address.
- Payload Packaging: The Windows Mobile client
constructed an XML-formatted payload containing the
Searchcommand, specifying theGALstore as the target (<Store><Name>GAL</Name>), alongside search criteria like<Query>and maximum result limits. - Transmission: The device transmitted this request
via an HTTPS
POSTrequest to the Exchange Server's/Microsoft-Server-ActiveSyncvirtual directory. - Server Resolution: Upon receipt, Microsoft Exchange
queried Active Directory on the corporate network using Name Service
Provider Interface (NSPI) or LDAP calls to match the search string
against attributes such as
displayName,givenName,sn, andmail. - Response Delivery: Exchange compiled the matching results into an XML payload and returned an HTTP 200 OK response to the mobile device.
- Parsing and Display: Windows Mobile parsed the XML response and displayed the matched records (including display names, email addresses, phone numbers, and office locations) on the screen.
Bandwidth and Performance Optimizations
Mobile network connections during the Windows Mobile 6.5 era often suffered from high latency and variable speeds. To maintain responsiveness, the OS implemented several data-saving techniques:
- Result Capping: Lookups enforced server- and client-side limits, typically returning a maximum of 20 to 50 matching entries at a time to keep payloads small (usually only a few kilobytes).
- Truncated Attributes: Initial search results pulled only essential identity attributes. Full contact cards were only generated if a user selected an individual record for a detailed view.
- Stateless Lookups: Unlike standard folder synchronization, GAL searches were non-persistent transactions. The results remained in temporary memory for immediate use and were discarded once the user navigated away, unless the user explicitly chose to "Save to Contacts."
Network and Security Architecture
GAL queries operated over standard cellular data connections (APNs) without requiring a full corporate Virtual Private Network (VPN) tunnel. Security and data integrity were handled at the transport layer:
- SSL/TLS Encryption: All EAS communications, including search queries and results, were routed over HTTPS via TCP port 443, securing organizational data over public cellular networks.
- Authentication: The request payload was authenticated using the user's domain credentials via Basic Authentication (over SSL) or Client Certificate-Based Authentication, validating access to Active Directory before any directory information was exposed.