The Microsoft System Center Mobile Device Manager (MDM) 2008 (MDM 2008) and Exchange Server Integration Guide helps you address the decisions and activities that are critical to successfully integrate MDM and Microsoft Exchange Server with the goal of providing mobile messaging to Windows Mobile 6.1 devices. This document is written for information technology (IT) specialists, generalists, consultants, value-added resellers, or anyone who seeks technical information to plan, deploy, and support the infrastructure required to integrate Exchange with MDM. It describes how MDM increases your ability to manage Windows Mobile devices using methods already familiar to those who work with other Microsoft technologies.
The document includes the following:
- Brief discussion of how MDM integrates with typical Exchange
- Ways that organizations can use MDM to manage Windows Mobile
devices in various Exchange scenarios
- Discussion of common areas of interest such as authentication,
reporting, operational practices, and troubleshooting.
This document does not provide step-by-step examples of how to deploy or operate an MDM infrastructure. This document refers to supplemental material throughout, and the Supporting Documents for MDM section provides a generous list of supporting references you may find helpful, including a listing documentation that ships with the product.
The MDM Architecture Guide is considered required reading. You
can view it at this Microsoft Web site:
This document contains the following sections:
MDM and Exchange Topologies
Combinations of Exchange, MDM, and
Recommendations for MDM in an
Existing Exchange Environment
New Ways to Manage Exchange Policies
Mobile Device PIN Recovery
Configuring the Server Source
for Mobile ActiveSync
Validating Exchange and MDM
MDM and Exchange Topologies
The scenarios discussed in this document focus on mobile MDM integration scenarios for both Exchange 2003 Service Pack 2, Exchange Server 2007 RTM, and Exchange 2007 Service Pack 1. Although the information is comprehensive, not every possible enterprise Exchange scenario is discussed. This document discusses the following topology scenarios:
- Decentralized with branch offices
|You must properly plan and deploy Exchange Server prior to
deploying MDM. See the following guidance: Exchange 2007
Recommended Deployments (Applies to Exchange Server 2007, Exchange
Server 2007 SP1) is at this Microsoft Web site:
Centralized Exchange Topology
In the centralized topology, the implementation for an
enterprise consists of multiple domains where Exchange is deployed
in a single site. This topology is preferred by organizations that
want to minimize the IT technical footprint and rely on relatively
few groups in the organization to manage and monitor the messaging
environment. We recommend that you follow existing Exchange
guidance by establishing protected communications from the client
endpoint to a front-end, back-end messaging architecture. For a
more detailed description of the Exchange front-end, back-end
architecture, refer to “Front-End and Back-End Server Topology
Guide for Microsoft Exchange Server 2003 and Exchange 2000 Server”
|You must use an Exchange Client Access Server to support Exchange ActiveSync communications between mobile devices and the Exchange Server environment. To synchronize mail items, Mobile devices must be able to communicate with the Microsoft-Server-ActiveSync virtual directory in Internet Information Server (IIS) on an Exchange Server. The following virtual directories are installed by default on any Exchange 2003 installation: \Exchange, \Exchweb, \Public, \OMA, and \Microsoft-Server-ActiveSync. Exchange 2007 installation provides only the Microsoft-Server-ActiveSync virtual directory on Exchange Client Access Servers. This directory appears on Exchange Server 2007 or Exchange Server 2007 SP1 servers only if the Exchange Client Access Server role is installed. Exchange ActiveSync communications cannot just be directed to an Exchange Server 2007 Mailbox Server for Exchange ActiveSync communications.|
The following illustration shows a typical centralized deployment topology with a basic MDM deployment.
MDM supports the client data access recommendations set
forth in the section titled “Client Access Server data paths” at
this Microsoft Web site:
Making client communications more secure is typically achieved by establishing a Secure Socket Layer (SSL) session transported within an IPsec session between the Windows Mobile 6.1 device and the MDM Gateway Server, encapsulating SSL packets within an Internet Protocol Security (IPsec) tunnel mode Virtual Private Network (VPN) connection. With the VPN connection, traffic is directed from the mobile device, over wireless or the operator network, to the centralized perimeter network, and then to the Exchange Client Access Server servers where the usual Exchange mechanisms proxy the traffic to the appropriate internal servers (such as mailbox, and so forth.)
MDM administrators can implement mobile policies to
ensure that the mobile VPN cannot be disabled by users. You must
carefully plan which policies to apply to the device to ensure that
users cannot circumvent security mechanisms intended for mobile
devices. Refer to the section title “Configuring Managed Devices
with Group Policy” in MDM Operations at this Microsoft Web site:
We recommended that enterprises deploy multiple MDM Gateway Servers in the perimeter network to provide redundancy in the event one or more of the servers fail or require scheduled maintenance. Typically, in this scenario, each server is issued a static IP address and then the IP addresses are bound to one fully qualified domain name (FQDN). For example, mobvpn.contoso.com is bound to IP addresses 126.96.36.199, 188.8.131.52, which are the IP addresses of servers GW1 and GW2. Each gateway server is configured with a pool of virtual IP addresses which are used by devices in the VPN session.
Network latency is a primary consideration for a
centralized topology because all traffic must traverse a network
path that may have multiple jumps, particularly when roaming to
geographies that are distant from the central site. A stable and
consistent network route is required for optimal performance, so
the VPN connection should persist unless network coverage is
unavailable. Fortunately Windows Mobile 6.1 provides a fast
reconnect feature to rapidly re-establish the VPN connection in the
event of network loss. Additional details on the fast reconnect
feature are discussed in the MDM 2008 Product Reference Guide at
this Microsoft Web site:
Decentralized Exchange Topology
The decentralized topology supports larger enterprises with multiple domains and multiple locations that have a decentralized management of Exchange services. This topology differs from an MDM infrastructure designed for a central messaging topology in that the design places emphasis on establishing the shortest, and hopefully quickest, route to the Exchange Client Access Servers. Under most scenarios, we recommend that you direct traffic to the nearest external-facing or Client Access Server allowing the default proxy mechanisms to operate as designed. If the messaging infrastructure is dispersed between geographic sites, you should provide mobile devices a local network route to the nearest well-connected perimeter network for your company.
For detailed information about Client Access Server
proxy features and redirection in Exchange Server 2007, see
“Understanding Proxying and Redirection” at this Microsoft Web
The following illustration shows the decentralized topology scenario.
Similar to the centralized messaging scenario, the network route is a primary consideration for planning and deploying MDM. The Mobile VPN client maintains a list of possible network addresses for MDM Gateway Servers in volatile memory. These network addresses correspond to the gateways configured within MDM. The Mobile VPN client receives these addresses as a result of a DNS query. If the MDM client cannot connect to the addresses held in memory or if the mobile device is powered off resulting in volatile memory being cleared, the MDM client queries DNS for a revised list of network address for the MDM Gateway Servers.
Access to messaging Client Access Servers would typically route through locally deployed hosts which then proxy traffic to the appropriate mailbox servers. When roaming, if a mobile device finds a route that is closer to the central site, the traffic is routed to the central site perimeter network. It is directed through the MDM Gateway Servers to the central site Client Access Server which then proxies the traffic to the appropriate mailbox servers regardless of whether the mailbox is in the central or secondary site.
MDM 2008 supports centralized device management with only MDM Gateway Servers deployed beyond the central site. You manage all policy related actions that occur between MDM and mobile devices by using the MDM Device Management Servers deployed on the central site.
As with any distributed application architecture, it is better to place all server roles physically and logically close to each other for the best possible performance. We recommend that you place MDM Gateway Servers as close to the Client Access Servers as possible. Carefully consider total latency of communications from MDM Client, through MDM Gateway Servers to exchange Client Access Servers and the appropriate Exchange Mailbox Servers, and then back through the original network route. All traffic to and from the MDM Clients must traverse the originating route. Network traffic that is returning from the hosts on the company network to the MDM Client must return through the original network route because the IPsec tunnel prevents any other means of contacting the MDM Client. MDM Gateway Server checks network packets to make sure that packets that come in on one network interface will route back through the same network interface. For security reasons, MDM Gateway Server will drop the packets if the two interfaces do not match.
Decentralized Exchange Topology with Branch Offices
The decentralized with branch office scenario is similar to the decentralized scenario but requires support for remote locations. The branch office scenario supports a small office or retail site that has less than 100 workstations and little or no server infrastructure. Typically, branch offices do not have messaging components or MDM server roles deployed locally. Therefore, the branch office scenario is similar to the decentralized topology where mobile devices use the operator network to establish the shortest path to an MDM Gateway Server and are proxied to the nearest Exchange Client Access Server.
Combinations of Exchange, MDM, and Windows Mobile
Windows Mobile 6.1 introduces a significant number of native enhancements over previous Microsoft Mobile technologies with regards to device management, security features, and device usability. MDM can provide a management framework to configure all the new device management features built into Windows Mobile 6.1 regardless of messaging infrastructure. MDM does not have a dependency on Exchange Server.
When MDM manages Windows Mobile 6.1 devices, Exchange Server recognizes the mobile device as fully compliant and it does not apply Exchange Server policies to the device. The Exchange environment assumes that the device has met whatever policies are defined on the messaging platform. This is true whether the user mailbox resides on Exchange Server 2003 SP2, Exchange 2007, or Exchange 2007 SP1.
The greatest benefits for mobile messaging users are realized by integrating MDM 2008, Exchange 2007 SP1, and Windows Mobile 6.1. The following sections describe the differences between the policies available when deploying MDM with Exchange 2003 SP2 and Exchange 2007 SP1, and the differences in deployment strategies and coexistence.
Integrating Exchange 2007 SP1 with MDM
MDM 2008 deployed with Exchange 2007 SP1 and Windows Mobile 6.1 currently offers the highest degree of control over the Windows Mobile platform. This combination of technologies delivers a robust story, in large part because of new capabilities built into the Read Only Memory (ROM) of Windows Mobile 6.1.
Exchange Server 2007 SP1 introduces a new mailbox policy that enables MDM to manage Windows Mobile 6.1 devices.
|Exchange 2007 and Exchange 2003 do not support this policy.|
By default, when Exchange Server 2007 SP1 installs, if devices are managed by management software other than Exchange, Exchange Server prohibits devices from accessing Exchange ActiveSync. When a Windows Mobile 6.1 device contacts an Mobile Device Manager (MDM) Gateway Server, the traffic is routed to a Client Access Server which then directs ActiveSync traffic to a mailbox virtual server resource that hosts the target mailbox. The Exchange ActiveSync policies on user mailboxes are configured to allow MDM to manage the mobile device rather than relying on Exchange Server policies.
|Only devices with Windows Mobile 6.1 are supported by this MDM configuration. Earlier devices continue to receive policies from Exchange. This allows Windows Mobile 6.1 and previous versions to route traffic through common Client Access Server pools.|
This feature in Exchange Server 2007 SP1 allows administrators to decide which user mailboxes are externally managed by MDM. As an example, by applying policy, you can have Exchange hand off the management of executives’ mobile devices to MDM.
To enable a mailbox policy that configures ActiveSync to discard the native Exchange policies and permit MDM to manage the device policies, you must run the following command from Exchange Management Shell:
Set-ActiveSyncMailboxPolicy -Identity MyPolicy -AllowExternalDeviceManagement $True
MDM and Exchange 2007 SP1 Policies
Many mobile related policies were introduced with Exchange 2003 SP2, and the list of policies was expanded in Exchange 2007 and Exchange 2007 SP1. Many of the new device policies rely on the functionality built into Windows Mobile 6.1 ROM. These MDM features are not supported on earlier Windows Mobile versions.
Exchange 2007 SP1 and MDM can both apply these policies to Windows Mobile 6.1 devices, but differ in the way they are managed. MDM extensions to the Group Policy Management Console (GPMC) and Group Policy Object (GPO) Editor enable network administrators to control managed devices in a familiar environment and in a manner consistent with how they manage their networked desktop and portable computers. Extensions support existing GPMC functionality such as scripting, GPO backup, planning mode, and logging mode. These extensions are not supported for the Resultant Set of Policies (RSoP) snap-in.
The User Group Policy Settings address configuring ActiveSync and Messaging SMIME policies. The Device Group Policy Settings focus on the following policies: Password, Platform Lockdown, Application Disable, File Encryption, Device Management, Mobile VPN Settings, Software Distribution, and additional Security policies. Network and Certificate Management Settings help with configuring new network connections, editing or deleting existing network connections, and managing certificate stores on the managed devices. These options are provided through custom extensions to the GPO Editor.
Organizations need to carefully map how devices relate to Organization Units (OUs) to which the Group Policy will be applied. You can target a GPO using one or more predefined security groups. Policy settings associated with the GPO apply to managed devices in OUs that are linked to the GPO only if those managed devices are members of the specified security groups. For more details about using Group Policy to apply Windows Mobile policies and software distribution, see the following documents:
- Deploying MDM in a Global Enterprise Environment:
- MDM Operations at this Microsoft Web site:
The targeting mechanism for Exchange Server is mailbox
policy; however, policy availability depends on both the versions
of the Windows Mobile device and Exchange Server where the user
mailbox resides. MDM can manage the many policies for the Windows
Mobile 6.1 platform, whereas Exchange Server can only manage on an
Exchange Server release level basis. These policies are listed
below. For a description of each of the policies, see the MDM
Product Reference at this Microsoft Web site:
Exchange 2003 SP2 can enforce the following policies for Windows Mobile 5.0, Windows Mobile 6, and Windows Mobile 6.1 devices:
- Global Policies
- PIN Enforcement
- PIN Complexity
- Local Wipe
- Remote Wipe
Exchange 2007 can enforce the following policies for the Windows Mobile 6 and Windows Mobile 6.1 devices in addition to the mobile device policies available in Exchange Server 2003:
- SD Card Encryption
- Allow/disallow attachments
- OTA PIN reset (applies to Windows Mobile 6 or greater)
- Block by User ID
- Block by Device ID
Exchange 2007 SP1 can enforce the following policies for Windows Mobile 6.1 devices in addition to the mobile device policies available in Exchange Server 2003 and Exchange Server 2007:
- Disable Storage Card
- Disable Camera
- Enable Full Device Encryption
- Disable Unsigned Application
- Disable Unsigned CABs
- Disable Wi-Fi
- Disable SMS and MMS text messaging
- Disable POP/IMAP E-mail
- Disable Bluetooth
- Disable IrDA
- Disable/Enable HTML mail
- Disable/Enable OffPeak Sync Frequency
- Set E-mail Age Filter
- Set E-mail Body Truncation Size
- Set Calendar Age Filter
- Set Peak Days for Sync
- Set Sync Frequency
- Set Peak Start Time
- Set Peak End Time
- Disable Sync when Roaming
- Disable Desktop ActiveSync Sync
- Disable OTA Email Sync
- Disable OTA Calendar Sync
- Disable OTA Contact Sync
Recommendations for MDM in an Existing Exchange Environment
MDM provides a more secure means of exposing Exchange ActiveSync to mobile devices than traditional Internet Security and Acceleration (ISA) Server publishing. Publishing Exchange ActiveSync with MDM also provides an avenue to manage ActiveSync mobile policies, whereas publishing Exchange ActiveSync with ISA Server only provides a reverse-proxy mechanism to direct ActiveSync network traffic to the Client Access Servers. You must still use Exchange Server ActiveSync policies to manage mobile device management policies. MDM provides many additional mobile policies that are not available when managing mobile devices with Exchange Server.
Publishing ActiveSync with MDM differs from other methods because the mobile VPN provides a termination point for all inbound traffic destined for the company network. From a network perspective, ActiveSync communications between the mobile device and server are no different than any other application on the company network.
The DNS requirements for enrolling and resolving MDM Gateway Server addresses remain common across all applications accessed by MDM clients. Mobile devices use internal DNS to locate the desired application on the company network.
Firewall Rules and Support for MDM
If the perimeter network has both externally and
internally facing firewalls, you must add firewall rules to ensure
the required ports are available for mobile device communications.
Refer to the MDM Server Ports section of the Planning Guide for MDM
2008 at this Microsoft Web site:
Traditional ISA Server 2006 publishing of Exchange ActiveSync for mobile devices requires that firewall rules permit HTTPS (TCP Port 443) on the external facing firewall to the ISA Server in the perimeter network. To allow the bridged SSL traffic to route from the perimeter network to the Exchange Client Access Servers, the internal facing firewall must also have rules to permit HTTPS (TCP port 443).
MDM requires bidirectional IPsec VPN traffic (ports UDP 500, UDP 4500, and IP 50) to allow incoming traffic from the mobile device to be directed to the MDM Gateway Servers in the perimeter network. The internally facing firewall must have firewall rules to provide HTTPS (TCP port 443) network connectivity for communications between the mobile VPN clients and the MDM Device Management Servers. The SSL traffic is encapsulated within the IPsec tunnel to the MDM Gateway Server.
If the MDM deployment does not include an external facing firewall, we assume that IPsec traffic terminates at the MDM Gateway Server and there is a requirement to provide HTTPS (TCP port 443) on the internal facing firewall.
Name Resolution Requirements
This section provides requirements for name resolution:
- Name Resolution Requirements for MDM Enrollment
- Name Resolution Requirements for MDM Management
- Name Resolution Planning for Exchange ActiveSync Publishing
Name Resolution Requirements for MDM Enrollment
You must configure public name resolution to support internet-facing names, such as, mobileenroll.contoso.com, for enrollment. This name resolution provides the mobile device a means to locate an entering point to the published enrollment server.
Name Resolution Requirements for MDM Management
You must configure public name resolution to route traffic to the MDM Gateway Servers after the mobile devices are enrolled. This is the only destination address that the mobile VPN client needs in order to route traffic to the company network.
In addition to the public reference to the MDM Gateway Servers, the Mobile VPN client must also be able to resolve names to IP addresses for the MDM Device Management Servers using internal DNS. This allows mobile devices to connect to the MobileDeviceManager virtual directory in IIS over SSL. This also supports communications required for device management operations, such as collecting hardware inventory, software inventory, and updating mobile policies on devices.
Name Resolution Planning for Exchange ActiveSync Publishing with MDM
Name resolution in the perimeter and company network must be such that devices can route Exchange ActiveSync traffic directly to the Client Access Servers from the device. Public name resolution is only required if mobile devices will connect directly over the internet.
Publishing Exchange ActiveSync with Internet Security and Acceleration Server
The following illustration shows a typical Exchange ActiveSync publishing scenario using ISA Server 2006.
The following number corresponds to the number in the diagram:
- Exchange ActiveSync on the mobile device is configured to
synchronize mail items with mail.contoso.com in a non-MDM
In a traditional ISA Server Exchange ActiveSync publishing scenario, to configure an unmanaged Windows Mobile device, you must specify the Exchange Client Access Server name, the user email address, user domain, user alias, user password, and select the data to synchronize (such as Contacts, Calendar, E-Mail, and Tasks). You can configure the device by tethering it to a workstation or portable computer and then use desktop ActiveSync or Windows Mobile Device Center.
The following steps describe a typical ActiveSync publishing scenario using ISA Server 2006 without MDM. In this example, mail.contoso.com is the Exchange Client Access Common Name.
- After ActiveSync starts the synchronization process, unmanaged
devices resolve mail.contoso.net to a public facing ISA Server
which reverse-proxies Exchange ActiveSync traffic to the Exchange
Client Access Servers.
Note: Make sure that the certificate has a common name consistent with the FQDN of the namespace that Internet clients will use to route traffic to the entry point in the perimeter network. For more information about how to publish Exchange ActiveSync for mobile devices, see this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=87060.
- ISA is usually deployed with SSL Bridging over TCP port 443
between the mobile device and the Exchange Client Access Servers.
ISA Server uses the same Web server certificate as the default Web
site on the Client Access Servers, which allows it to inspect
incoming traffic as its being forwarded to the Client Access
Servers. This requires that a Web Listener and an Exchange
ActiveSync Publishing Rule be configured on the ISA Server. For a
information about how to publish Exchange ActiveSync to mobile
devices, see this Microsoft Web site:
- After a partnership is created between the mobile device and
Exchange Server ActiveSync, the device receives its policies from
Exchange Server as configured by the Exchange Administrators.
- When the user accepts the notification that policies must be
applied, the user is prompted to restart the device with the new
Publishing Exchange ActiveSync with MDM
Publishing Exchange ActiveSync with MDM uses the VPN connection on the mobile device to route network traffic to the Exchange Client Access Servers through the MDM Gateway Servers. To apply ActiveSync policies with MDM instead of Exchange Server, you must make additional configuration changes in the Exchange Server environment.
For information about how to plan and deploy an MDM
infrastructure, see the MDM Planning and Operations guides at this
Microsoft Web site:
The following illustration shows and example of publishing Exchange ActiveSync with MDM.
The following numbers correspond with the numbers in the illustration:
- Exchange ActiveSync on the mobile device is configured to
synchronize mail items with mail.contoso.com
- The Mobile VPN Client is configured to create an IPsec tunnel
Note: Typically, the user will not see the namespace for the MDM Gateway Servers, such as mobilevpn.contoso.com. You configure this namespace during MDM Deployment, and if should be transparent to the users. For information about configuring the MDM Gateway Server namespace, see “Setting the Gateway URI for MDM Managed Devices” in the MDM Deployment Guide at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=108951.
The following steps describe one way to integrate MDM into an existing Exchange Server environment:
- Create the OUs in Active Directory for the mobile device
objects. These OUs are in addition to the SCMDM2008 Managed Devices
OU created when MDM is installed.
- Deploy MDM and configure policies, applying them by using GPO.
- Configure an Exchange 2007 SP1 mailbox policy to enable devices
to be managed outside of Exchange.
- Migrate specific user mailboxes to the Exchange 2007 SP1
- Apply the new Exchange ActiveSync mailbox policy to the
- Create a pre-enrollment record for the Windows Mobile 6.1
device for the users whose mailbox you migrated to Exchange Server
- Instruct the user to enroll the device, or enroll the device on
behalf of the user.
- Configure the device to synchronize with the user mailbox. You
can use MDM policy to set the Exchange Server source, but user
credentials will need to be entered to initiate Exchange ActiveSync
- Validate that the device is enrolled and synchronizes mail
items with Exchange ActiveSync.
- Review the device details in the MDM Console to verify proper
application of policy.
You can configure Windows Mobile device synchronization either before or after enrollment. A mobile device that is already synchronizing with Exchange must conduct a complete synchronization with the Exchange Server. Existing synchronized data will be lost.
The following examples show the notification sequence during synchronization:
There has been a change made on your server that requires you to resynchronize all items on your device. Please perform a manual sync.
Support code: 0x80883001
There has been a change made on your server that requires you to re-synchronize all items on your device. All changes made since your last successful sync will be lost.
Do you wish to continue?
After resynchronization, the user is prompted to optionally configure Always Up to Date Synchronization as follows:
Your device can synchronize automatically every time an item like an e-mail arrives or changes on your Exchange server. Would you like ActiveSync to adjust your sync schedule to keep you always up to date?
Co-Existence with Earlier Devices
There will be many cases when MDM and Windows Mobile 6.1 devices must co-exist with earlier version devices, synchronizing with Exchange Server. Earlier devices are those that run Windows Mobile 2003, Windows Mobile 5.0, and Windows Mobile 6. The primary difference between earlier versions is how mobile devices are routed to the namespace defined for Exchange Server Client Access.
The following illustration shows earlier Windows Mobile devices synchronizing with Exchange 2003 SP2, Exchange Server 2007, or Exchange Server 2007 SP1. It also shows Windows Mobile 6.1 devices enrolled in MDM:
If mobile device policy permits disconnecting from the VPN and the public namespace resolves to the same reverse-proxy mechanism used by legacy devices, which are devices with earlier versions, Windows Mobile 6.1 devices enrolled in MDM can disable the Mobile VPN and still synchronize with the Exchange server.
Recommendations for Integrating MDM with Exchange
There are many variations of scenarios where MDM can be introduced to provide more secure connectivity and robust device management functionality for mobile devices. This section describes typical scenarios.
MDM Co-exists with Earlier Devices
In this scenario, MDM Co-exists with earlier devices, and synchronize mail items with Exchange Server 2003 SP2, Exchange Server 2007 RTM, or Exchange Server 2007 SP1
We recommend that you support both Windows Mobile 6.1 and earlier Windows Mobile versions. To do this, make sure a reverse-proxy mechanism, such as ISA Server 2006, is available for earlier versions to facilitate Exchange ActiveSync communications from the public network, through the perimeter network, then to the company network over SSL by using TCP port 443.
You must also establish a process to enroll Windows Mobile 6.1 devices in MDM and properly route Exchange ActiveSync communications. ActiveSync communications should route through the MDM Gateway Servers over IPSEC (UDP 500, UDP 4500, and IP 50), to the Microsoft-Server ActiveSync virtual directories on the Exchange Client Access Servers on the company network over SSL (using HTTPS and TCP port 443).
You may want to consider configuring specific mailbox policies for the devices that MDM will manage. This may also include consolidating MDM managed mailboxes on dedicated Exchange Server mailbox servers.
MDM Introduced to an Unpublished Exchange Server Environment
If MDM is the first solution to provide Exchange ActiveSync synchronization, you may need to augment the existing Exchange Server infrastructure to introduce the Exchange Client Access Server role. To provide connectivity between the mobile device and the Exchange Server infrastructure, you must use the Microsoft-Server-ActiveSync virtual directory:
- If Exchange Server 2003 SP2 is deployed, you can use the
Microsoft-Server-ActiveSync virtual directory that is installed by
- If Exchange Server 2007 or Exchange Sever 2007 SP1 are the only
versions of Exchange Server deployed, then you must deploy the
Exchange Server Client Access role to make the
Microsoft-Server-ActiveSync virtual directory available to mobile
- If the Exchange environment is in a transition period from
Exchange Server 2003 SP2 to either Exchange Server 2007 RTM or
Exchange Server 2007 SP1, then you should follow the upgrade
guidance from the following Microsoft websites:
You can configure mobile devices for Exchange ActiveSync synchronization either before or after enrolling in MDM.
New Ways to Manage Exchange Policies with MDM
The following describe ways to manage Exchange polices with MDM:
- Device wipe
- Security policies
- Delegation of Administration
- User Self-Service
Remote device wipe is a feature that enables the Exchange Server to set a Windows Mobile device to delete all data the next time that the device connects to the Exchange server. When the device retrieves the wipe request, it reformats the external storage card and restores the factory default settings on the device. This can be useful when a device is lost, stolen, or otherwise compromised, or when a device has to be reassigned from one user to another.
You can also implement Exchange ActiveSync policies that specify a maximum number of password attempts. When that maximum is exceeded, the device performs a local device wipe.
Device wipe was available beginning with Exchange
Server 2003 SP2 and Windows Mobile 5.0. Exchange Server 2003 SP2
allowed administrators to invoke remote device wipes by using the
Exchange Management Console. Exchange 2007 added device wipe
options to the Outlook Web Access (OWA) Options page for users to
wipe their device without having to coordinate with administrators,
and also provided a PowerShell script for administrators. For more
information about wiping a device, see “How to Perform a Remote
Wipe on a Device” at this Microsoft Web site:
MDM offers new methods of initiating a device wipe for both administrators and users. Administrators can use the MDM Console to locate managed devices and then initiate the wipe. Administrators can also use the MDM Shell to invoke a device wipe with the following New-WipeRequest commands:
New-WipeRequest [-DeviceId] <DeviceIdParameter> [-WhatIf] [-Confirm] [<CommonParameters>]
New-WipeRequest -Owner <OwnerIdParameter> [-WhatIf] [-Confirm] [<CommonParameters>]
In addition to the New-WipeRequest cmdlet, administrators can use four other wipe related cmdlets to manage device wipe requests from the MDM servers:
- Get-WipeRequest - This cmdlet returns the unprocessed wipe
requests for the specified managed device.
- Remove-WipeRequest - This cmdlet removes a wipe request for the
specified managed device if the wipe request is yet unprocessed.
- Get-WipeConfig - This cmdlet returns the current configuration
of the wipe service.
- Set-WipeConfig - This cmdlet configures the properties of the
In addition to existing methods of performing device wipes, such as by using OWA or Exchange Management Shell, users and administrators can initiate a device wipe through the MDM Self Service Portal if it is deployed. In this scenario, Windows authentication ensures users logging onto the portal can only initiate wipes against devices they are permitted to manage.
The device wipe is performed by delivering a Configuration Service Provider to a targeted device. Exchange or MDM can issue the Configuration Service Provider independent of each other.
MDM stores information about the wipe request in a database and immediately sends a message to the managed device. The message signals the device to start a session with MDM Device Management Server. If the managed device is unreachable, the wipe request remains active until the managed device retrieves it or the wipe request fails or expires.
|The device must receive the wipe request or it will not be wiped unless a local wipe is performed.|
When the device retrieves the wipe request, it formats the external storage card and restores the factory default settings on the device. After the wipe, the device can no longer connect to the network through MDM Gateway Server, is no longer enrolled in MDM, and MDM no longer manages the device. When a wipe is successful, the device’s object ID is deleted from Active Directory but you must still delete the synchronization partnership in Exchange.
The status of remote device wipes is tracked with the following status states:
- Expired - The wipe request has expired because the managed
device did not connect in a pre-determined time.
- Failed - The managed device reports that the wipe try has
failed. That is, the request was sent to the managed device but the
- Pending - The request started but the managed device has not
reported success or failure, and the request has not expired.
- Retrying - The request resends after the managed device reports
that the previous wipe request failed.
- Succeeded - The device was successfully wiped.
By default, the Wipe Service revokes the device enrollment if the wipe fails after several retries, or if the wipe request expires. To change the default behavior you use the Set-WipeConfig cmdlet in MDM Shell to configure the DisenrollUnsuccessful setting to $False. You can cancel a device wipe request if the wipe request status is Pending or Retrying. This is the default behavior. If you set DisenrollUnsuccessful to $False, you can cancel a wipe request with a status of Failed or Expired. MDM tries to cancel a wipe request by removing the request from the database before it is sent to the managed device. You cannot cancel a wipe request that has been sent to a managed device, and you cannot restore a wiped device. After a device is wiped, to connect to MDM, the device must complete the enrollment process again.
For more information about device wipe, see MDM
Operations at this Microsoft Web site:
|Some users may have the ActiveSync mailbox policy applied to their mailbox, which allows MDM to manage their mobile devices instead of Exchange Server. In this scenario, device wipe from within OWA and the Exchange Server environment is still viable. MDM provides means to wipe a device in addition to the well-known methods within Exchange Server. Devices can also be wiped outside of MDM. If a user initiates a wipe by using OWA, exceeding the configured number for incorrect password attempts, or local hard reset, the device will still appear as a managed device in the MDM Console.|
You can use the MDM Device Enrollment Cleanup Tool from the MDM 2008 Resource Kit to remove records for to devices that were wiped outside of MDM. The Resource Kit provides the following script that you can use to remove records:
- RemoveDevice.ps1 moves devices from the Managed Devices list to
the Blocked Devices list.
- CleanBlockedDevices.ps1 removes devices that you wiped using
MDM but that are still included in the Blocked Devices list. This
is useful if devices are wiped and you want to use the device name
The MDM 2008 Resource kit is available for download at
this Microsoft Web site:
Security Policies in MDM
MDM offers various device security policies to enhance
messaging security. The following policies are managed using the
Group Policy Object Editor and are further described in MDM
Operations at this Microsoft Web site:
Password Policies include configuration options for managing password and PIN unlock configuration on Windows Mobile 6.1 devices. You use the Group Policy Object Editor to manage these options. The policies appear under Computer Configuration\Administrative Templates\Windows Mobile Settings.
If Password Policiesare enabled you can specify that passwords must be alphanumeric (Strong), a numeric PIN (PIN), or either type (PIN or Strong). The default setting is Not Configured.
Password timeoutlets you specify whether to have the device lock after the idle time that you configure. The Require password policy must also be enabled for this policy setting to take effect. If this setting is Enabled, you set the idle time to the number of minutes after which the device automatically locks. The user must then enter the password to use most device functionality. The default setting is Not Configured.
Number of passwords rememberedlets you prevent users from resetting their password to one of their previously set passwords. If this setting is Enabled, you can set the number of passwords that the device maintains. The user cannot create a new password that matches any of these previous passwords. The default setting is Not Configured.
Password expirationlets you configure the device lock expiration period. After the password expires, the user must enter a new password. If this setting is Enabled, you can specify the number of days after which the device password expires. After expiration, the user is prompted to renew the password. The default setting is Not Configured.
Minimum password lengthlets you to require that the device password is a minimum password length. The Require password policy must also be enabled for this policy setting to take effect. If this setting is Enabled, you can set the required minimum password length. After this policy is set on the device, the user is asked to create a new password if the current password does not meet the length requirement. You can set the minimum length to any integer between 1 and 40. The default for Simple PIN is four digits, and for Strong Alphanumeric, it is seven characters. If this setting is Not Configured, existing password-related settings on the device are in effect. The default setting is Not Configured.
Wipe device after failed attemptslets you configure the number of incorrect password tries to accept before the device wipes all its mounted storage volumes. If this setting is Enabled, you can set the number of incorrect tries to allow. The user is warned after every incorrect try and then displays the number of remaining tries. Before the last try, the user receives a warning that the device will be wiped. The default setting is Not Configured.
Code word frequencylets you specify how many times a user may enter an incorrect device lock password before the user is required to enter a code word. This policy can prevent a local device wipe caused by an accidental password entry. If this setting is Enabled, you can set the Code word frequency value to specify the number of incorrect password tries that the user can make before a code word is required. We recommend that you set this value to a number less than the number of incorrect password tries that cause the device to be wiped. The default setting is Not Configured.
Code wordlets you configure the code word that the user must enter after several incorrect device lock passwords have been tried. The threshold number of password tries that triggers the code word is specified in the Code word frequency policy. This policy can prevent a local device wipe caused by an accidental password entry. If this setting is Enabled, you can specify the code word that the user is asked to enter. The default setting is Not Configured.
Block user reset of authentication on the devicelets you block the user from resetting the device lock authentication (PIN or password) by using the capability that Microsoft Exchange Server 2007 provides. If this setting is Enabled, the user cannot reset the device lock authentication (PIN or password). The only way to unlock the device is by doing a full reset of the device. The default setting is Not Configured.
Turn off POP and IMAP Messagingdetermines if the user can use IMAP4 and POP3 e-mail accounts. If this setting is Enabled or Not Configured, the user can use IMAP4 or POP3 e-mail accounts. If this setting is Disabled, e-mail accounts that use IMAP4 or POP3 protocols are turned off. The user cannot synchronize existing IMAP4 or POP3 e-mail accounts that have the corresponding e-mail servers, and cannot set up a new IMAP4 or POP3 e-mail account. The user may be able to view e-mail messages for IMAP4 or POP3 e-mail accounts that were downloaded to the device before the policy setting was changed. You can still provision a new IMAP4 or POP3 e-mail account by using the Email2 Configuration Service Provider. However, if the new account was created after this policy is disabled, the user cannot synchronize that account with its e-mail server. This policy affects only the Microsoft e-mail application. ActiveSync
Block Remote API access to ActiveSynclets you restrict remote applications that are using Remote API (RAPI) to implement ActiveSync operations on Windows Mobile powered devices. If this setting is Enabled, desktop ActiveSync service is blocked and the user cannot synchronize e-mail, files, or applications from the desktop or change any settings. If this setting is Disabled, desktop applications that use ActiveSync Remote API (RAPI) to access the device can perform only operations on the device that the user has permissions to perform. If this setting is Not Configured, existing device-specific policies that manage access to the device by desktop applications by using ActiveSync RAPI operations are in effect. The default setting is Not Configured.
Delegation of Administration
Delegation of administration with MDM refers to the
need to assign privileges to administrators based on an Active
Directory delegation scheme. Organizational units (OUs) should be
established to create discrete containers for mobile device
accounts where delegation of group policy delegation can be
applied. For additional information about establishing OU
structures in Active Directory to support delegation, see
“Designing an OU Structure that Supports Group Policy” at this
Microsoft Web site:
The MDM Self-Service Portal provides a web-based means
for users to perform device pre-enrollment for their Windows Mobile
powered devices, view their managed devices, and perform a limited
set of actions on them. The MDM Self-Service Portal also provides
the software required to install, manage, and configure a
self-service portal for their company. You may need to
customization the portal to tailor the solution for organizational
branding and delegation. For more information about the MDM
Self-Service Portal, refer to “Self Service Portal Deployment Guide
for MDM 2008” at this Microsoft Web site:
The MDM Self-Service Portal provides a means of performing a device wipe in addition to using the Exchange Management Shell or OWA device wipe. In the context of MDM and Exchange Server integration, the Self-Service Portal provides the interface to initiate the device wipe. Deploying the Self-Service Portal also permits users to re-enroll a device in the event their device is wiped and needs to re-establish a connection to the company network in a more secure manner.
Mobile Device PIN Recovery
The PIN Recovery feature of Exchange 2007 allows a user to unlock the mobile device if the device PIN is forgotten. The password used to reset the device PIN, called the RecoveryPassword, is generated when a mobile device establishes a partnership during the first synchronization with Exchange Server. To use the RecoveryPassword, the user selects Menufrom the Unlock screen, then Reset Password. The mobile user is prompted to type a new password and subsequently prompted to type the Recovery Password. If the Recovery Password is correct, the new PIN is applied to the device and a new Recovery Password is generated in Exchange Server.
The user can retrieve the RecoveryPassword value by using OWA. Exchange Administrators can retrieve it using either the Exchange Management Console or the following PowerShell script:
Get-ActiveSyncDeviceStatistics -Mailbox:"alias" -ShowRecoveryPassword:$true
This script lists mobile device details, including the RecoveryPassword value, for all devices associated with the user’s mailbox that have synchronized with Exchange.
|You must use group policy to disable the mobile policy Block user reset of authentication on the device, and then reset the device PIN after the device enrolls with MDM. A new RecoveryPassword is generated each time the PIN is reset on the mobile device. The new RecoveryPassword value is created after the mobile device establishes an Exchange ActiveSync partnership and the device PIN is changed. The Recovery Password may also be generated prior to enrollment if the device is synchronized with Exchange Server.|
The PIN Recovery process remains the same after a mobile device is enrolled in MDM, provided it has a RecoveryPassword value to be retrieved from Exchange. If the MDM policy Block user reset of authentication on the deviceis enabled, Reset Passwordis not available on the device. If the MDM policy Wipe device after failed attemptsis applied to the mobile device, users must use the PIN Recovery process before failing the maximum number of times.
This section discusses the following authentication methods:
- Default authentication
- Certificate-based authentication
Although machine certificates provide the IPsec authentication mechanism for device-to-gateway communications, the default user mechanism is typically basic authentication. To better protect your infrastructure, we recommend that you encapsulate SSL traffic in IPsec packets which terminate at the MDM Gateway Servers. SSL should still be used to protect the communications from the MDM Gateway Servers to the Exchange Client Access Servers. The MDM Gateway Servers do not provide pre-authentication mechanisms for resources residing on the company network. MDM Gateway Servers are supported in workgroup mode which reduces the likelihood that an attacker will have access to the domain or to Active Directory. In addition, attacks against the domain have no impact on MDM Gateway Servers.
Traditional Exchange ActiveSync traffic is encapsulated in the VPN packets, terminated at the gateway, and then routed onto the Exchange Client Access Servers over SSL.
Certificate Based Authentication
Client authentication using certificates and user
mapping is another authentication mechanism that can be deployed
along with MDM. This authentication mechanism involves only the
Exchange Server components and the MDM Gateway Servers. Make sure
that you do not use client certificates as a pre-authentication
mechanism. For more information about Certificate based
authentication, see “Deploying Exchange ActiveSync
Certificate-Based Authentication” at this Microsoft Web site:
You can also use client certificate authentication on a
network publishing mechanism such as ISA Server 2006 if placed
in-line between the MDM Gateway Servers and the Exchange Client
Access Servers. For more information, see “Overview of Deploying
Exchange ActiveSync Certificate-Based Authentication” at this
Microsoft Web site:
The following are the two recommended ways to install user certificates to Windows Mobile 6.1 devices:
- Use Microsoft Windows Mobile Device Center 6.1 (Windows Mobile
tethered to Vista
- Request an offline certificate and importing it to the mobile
device by using a .pfx file.
Configuring the Server Source for Mobile ActiveSync
To simplify Exchange ActiveSync setup for mobile users, you can use group policy to preconfigure the Exchange Server Source values. To do so, configure the following User Configuration items in the Windows Mobile Settings Administrative Template:
- Peak and Off-peak Settings
- Peak days
- Peak start time
- Peak end time
- Synchronization frequency during peak times
- Synchronization frequency during off-peak times
- Set message format (HTML or Plain Text)
- Maximum Email age filer allowed
- Set maximum size limit for plain text email
- Set maximum size limit for HTML email
- Set age limit for calendar items
- Set maximum attachment size allowed
- Block synchronization when roaming
- Turn off Desktop PIM Sync
- Server name
You must link these group policies to containers in Active Directory associated with the User objects instead of mobile devices. Make sure that you configure the appropriate permissions to allow the users to read the group policy.
If user certificate authentication is not implemented, users must provide their credentials on the mobile device to complete Mobile ActiveSync configuration.
Validating Exchange and MDM Functionality
Exchange functionality can be verified after a mobile device enrolls, establishes a VPN connection to an MDM Gateway Server, and ActiveSync communications are routed to the Exchange infrastructure on the company network. The Windows Mobile device should experience no discernable difference between communicating through the MDM Gateway Servers from any other Exchange ActiveSync reverse-proxied scenarios. After the network route from the device to the company network is established, the device relies on the ActiveSync Server configuration to determine the Exchange Server’s canonical name or CNAME (such as mail.contoso.net), the username (<domain>\<username>), and password.
Other methods of client authentication for Exchange Server are available. ActiveSync traffic can be directed through a reverse-proxy mechanism to provide pre-authentication, or network communications can be directed to the Exchange Client Access Servers where additional authentication mechanisms can be integrated.
You must investigate and resolve any errors displayed during synchronization by using ActiveSync troubleshooting techniques. If OWA is available in addition to Exchange ActiveSync, you can verify that network routing is properly configured to support mobile devices by using Internet Explorer Mobile to access OWA. OWA provides a quick means to verify that communications are successfully routing between the mobile device and Exchange Client Access Servers. Under most circumstances OWA communications are protected with SSL, similar to ActiveSync communications.
For more information about troubleshooting Mobile VPN
client connectivity issues, see to the Troubleshooting section of
this document. For more information about troubleshooting
ActiveSync, see to “How to Troubleshoot Server ActiveSync” at this
Microsoft Web site:
The following deployment tools are further described in the MDM Deployment Guide which provides prescriptive deployment guidance.
The ADConfig tool, ADConfig.exe, is a configuration tool that you must use to configure Active Directory for MDM. ADConfig lets you do the following:
- Create the Active Directory Universal Security Groups and
containers for MDM
- Add the service connection points (SCP) for MDM
- Create the Mobile Device Templates in the enterprise
For more information about ADConfig, see this Microsoft
MDM Administrator Tools
The following MDM administrator tools are further described in the MDM Architecture Guide and in MDM Operations.
MDM Console is the core MDM management MMC snap-in tool that is included with MDM Shell. This console lets you perform the following:
- Start pre-enrollment requests
- Manage all Windows Mobile powered devices attached to the
- Configure the MDM system infrastructure
- Configure MDM Gateway Server
- Perform tasks, such as a device wipe
For more information, see “Overview of MDM Management
Console” in MDM Operations at this Microsoft Web site:
Group Policy Extensions
With the GPMC, you can push MDM group policies to
Windows Mobile devices and enforce these policies. 64-bit software,
except for the Windows Vista operating system, does not support
GPMC. For more information, see “Configuring Managed Devices with
Group Policy” in MDM Operations at this Microsoft Web site:
MDM Software Distribution Management Console
The MDM Software Distribution Console is a custom MDM
WSUS console that provides software distribution capabilities and
the ability to push software .cab files to a Windows Mobile powered
device. For more information, see “Overview of MDM Software
Distribution” in MDM Operations at this Microsoft Web site:
The MDM Shell offers over 40 cmdlets you can use to
automate of administrative tasks for MDM servers. For more
information, see Supporting Documents for MDM in this document, and
“MDM Shell Cmdlets” in MDM Operations at this Microsoft Web site:
MDM Reporting Services provides a reporting and data access service across all feature areas of MDM. MDM Reporting Services is based on and integrated with SQL Server Reporting Services 2005 (SSRS).
You can download the MDM Reporting Services from this
Microsoft Web site:
The Device Asset Report is a useful report to use with Exchange Server integration. This report provides a history of each managed device, including the system identifier (ID) that the managed device has been assigned based upon the hardware ID — that is, the IMEI, MEID, or ESN number. The report also lists the people to whom the managed device has been assigned, based on their system ID and the device hardware ID.
The Group Policy Objects Report describes MDM Group Policy information for groups of items, such as the number of managed devices to which a specific Group Policy setting has been applied. The report also lists the success and failure of specific Group Policy actions that MDM Group Policy has attempted to apply to each managed device. The report rolls up Group Policy information based upon the following aspects:
- The number of devices affected by a specific Group Policy
- The success rate of Group Policy objects
- The failure rate of Group Policy objects
For each line in the report, you can drill down to view the details for each managed device.
You can use the following parameters to filter the results of the report:
- Device Domain
- Device OU
- Policy Name
The Group Policy Settings Report describes MDM Group Policy information for groups of items, such as the number of managed devices to which a specific Group Policy has been applied. You can also list the success and failure rates of specific Group Policy settings performed on each managed device. This report rolls up Group Policy information based upon the following aspects:
- The number of devices affected by a specific Group Policy
- The success rate of Group Policy settings
- The percentage failure rate of Group Policy settings
For each line of the report, users can drill down through report details to view the details of each device.
You can use the following parameters to filter the results of the report:
- Device Domain
- Device OU
- Device Name
To create custom reports, you can use the SQL Server Report Builder tool together with the report models provided with MDM Reporting Services. Report Builder has a report layout template that contains predefined data regions. You can select a predefined report model, which contains report items such as data fields; then drag-and-drop the report items onto the data regions in the template. You can apply filters to the report to refine the data to be displayed. The MDM report model contains all of the information required for Report Builder to automatically generate a query to retrieve the requested data.
You can find online documentation to help troubleshoot
MDM at this Microsoft Web site:
This documentation provides the following to help you address troubleshooting issues:
- Overview of MDM Troubleshooting MDM Setup
- MDM Gateway Server Issues
- MDM Enrollment Issues
- MDM Device Management Issues
- MDM Software Distribution Issues
- MDM Group Policy Issues.
In addition, the following logs and utilities are commonly used to troubleshoot MDM related issues.
- Event viewer
- MDM logging
- Windows software trace preprocessor (WPP)
- Exchange logging
- Services snap-in
- MDM Shell
- MDM Shell ADSIEDIT
MDM populates Application, System, and Security events in the Event Log. Use Event Viewer to obtain information and details when a specific issue occurs.
The SCMDMsetup.log file, located in the default Temp directory, contains information that is collected from MDM component .msi installation logs. However, it does not contain verbose installer data, and does not report return values for custom actions. You can get more comprehensive information, including return values, from the .msi logs for each MDM component installation.
|If you run Setup at a command prompt, logging is only performed if you use the /L or /L*v parameters. You can specify the log name by adding /L and a log file name to the command line.|
The Verbose Windows Installer Logging (WILogUtl.exe) produces a verbose log file that you can use to find the source of an error.
An MDM Event Viewer node is created when MDM system components install. This provides information on application and installation errors.
The VPNGateway.log file is created in the Temp directory during the MDM Gateway Server Setup process.
Windows software trace preprocessor (WPP)
Creating logs by using MDM Shell cmdlets to enable WPP produces log files that you can analyze for debugging and troubleshooting issues.
You can use the Exchange Management Shell and the
Registry Editor to change the diagnostic logging level for Exchange
Server processes to help with troubleshoot issues that may occur in
an Microsoft Exchange Server 2007 or Microsoft Exchange Server 2007
SP1 environment. To manage the Exchange Server process logging
levels, the account you use must be have membership in the local
Administrator group. For more information about managing Exchange
Server logging levels, see this Microsoft Web site:
You can set up the following logging levels:
- 0 (Lowest). This is the default
- 1 (Low)
- 3 (Medium)
- 5 (High)
- 7 (Expert).
You should always return the logging level to the default setting of 0 (lowest) after completing your troubleshooting activities.
You can use the Exchange Management Shell cmdlets to view current logging levels and set the logging levels of Exchange Server processes:
- Use the Get-EventLogLevel cmdlet to display a list of
categories and their logging level for a specified Microsoft
Get-eventloglevel [-Identity <ECIdParameter>] [-DomainController <Fqdn>]
- Use the Set-EventLogLevel cmdlet to set the event logging level
registry value for the specified category.
Set-eventloglevel -Identity <ECIdParameter> -Level <Lowest | Low | Medium | High | Expert> [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
For a complete list of processes with configurable
event logging levels, see this Microsoft Web site:
To get information about diagnosing server-side
ActiveSync, you can parse the Exchange Server IIS logs for Exchange
ActiveSync specific data. For details about how to install and
configure the log parser, see
Use the Services MMC snap-in to start, stop, and verify that certain services are running.
Use the MDM Shell for device status information or package installations.
MDM Command Shell
Use MDM Shell to run cmdlets that retrieve data or set configurations.
Use ADSIEdit.msc to view and change Active Directory. This tool is a low-level editor for Active Directory that provides a graphical user interface (GUI). You can use this tool to add, delete, and move objects in a directory service.
Use the Report Viewer tool to collect data from Active Directory and the MDM databases. MDM Reporting Services uploads data to a reporting database for comprehensive and detailed reporting capabilities.
Use Logman.exe when Windows Event Logs are insufficient for troubleshooting a problem. You can start WPP tracing for the VPN server to obtain detailed trace logs.
The MDM 2008 Resource Kit provides server tools and client tools.
MDM 2008 Resource Kit - Server Tools
The MDM 2008 Resource Kit – Server Tools is available
as a download at
MDM Bulk Pre-Enrollment Tool
This command line tool enables administrators to pre-enroll in MDM groups of Windows Mobile devices in an organization. Bulk pre-enrollment can be simpler and more efficient than pre-enrolling a large number of devices individually. As part of pre-enrollment, the tool generates passwords that administrators can share with users so users can enroll their devices.
MDM Application Hash Code Tool
This tool allows administrators to create an XML file that includes an SHA-1/MD5 hash code file. An administrator can use the file together with a GPO to allow or prevent an application from running on managed devices.
MDM Cleanup Tool
This command-line tool enables administrators to completely uninstall MDM from servers. This tool is helpful when other removal options, such as the MDM un-installation wizard and Add/Remove Programs, have not fully removed MDM components and settings.
MDM Device Enrollment Cleanup Tool
This PowerShell script–based tool helps administrators remove older or no-longer-needed managed devices from the MDM system. The tool removes entries for the devices that still exist in Active Directory and the MDM databases.
MDM Certificate Tool
This command line tool helps administrators request certificates for MDM components. Administrators can also set Access Control Lists (ACLs) on certificates, place requested certificates in a specific folder, and invalidate Global Certification Manager (GCM) certificates.
MDM 2008 Resource Kit - Best Practices Analyzer
The Best Practice Analyzer (BPA) helps you to analyze the prerequisites for MDM setup and deployment. Because each MDM server component has different prerequisites, the tool helps you to plan and build a successful deployment environment by assessing each server's readiness for MDM before you run MDM Setup.
In addition to analyzing the readiness of each server, BPA Tool helps you to verify the firewall configuration that MDM requires between servers running MDM Device Management Server and servers running MDM Gateway Server. After you deploy MDM, you can then run a post-deployment scan to help make sure your installation works properly and follows MDM best practices.
You can download the BPA tool at this Microsoft Web
MDM 2008 Resource Kit - Client Tools
You can download the MDM Resource Kit Client Tools at
this Microsoft Web site:
MDM Connect Now Tool
This tool enables users of Windows Mobile 6.1 managed devices to download new software updates queued since the managed device last synchronized with MDM. The tool initiates a session between MDM Device Management Server and a managed device. Once the tool establishes a connection, new software updates are downloaded to the managed device.
VPN Diagnostics Tool
This tool helps users diagnose VPN issues between the MDM and the devices it manages. The tool allows users to see the VPN configuration and status on the managed device and to diagnose any VPN-related problems. The tool also allows the user to collect device logs from their device and send them to a diagnostics team for further analysis.
The following supporting documents are available for MDM.
Getting Started with MDM- provides information to help you
understand MDM and the available tools and resources. The Getting
Started for MDM can be viewed online at this Microsoft Web site:
MDM Architecture Guide– describes the standards-based
solution for integrating mobile and handheld devices as trusted and
fully managed members of the enterprise with minimal affect on
existing infrastructure. Architecture for MDM can be viewed online
at this Microsoft Web site:
MDM Planning Guide- helps administrators design and plan an
MDM 2008 deployment in an Enterprise environment. It provides
detailed information and recommendations to help you make accurate
design decisions while planning your organization's deployment. The
Planning for MDM can be viewed online at this Microsoft Web site:
MDM Deployment Guide– describes the steps to deploy the MDM
system. Deployment for MDM can be viewed online at this Microsoft
MDM Operations– provides information on how to manage MDM
devices, distribute software to managed devices, manage MDM
Servers, and configure MDM Services. The Operations for MDM can be
viewed online at this Microsoft Web site:
Security and Protection for MDM– provides prescriptive guidance for configuring security-related features in MDM. It also provides guidance for reducing the attack surface of the MDM infrastructure security features such as:
- Encrypted access to e-mail and line-of-business (LOB)
applications from the Internet
- Certificate based authentication for virtual private network
- Device Inventory and Health inspection
- Application approval and blocking
- Remote device wipe to remove sensitive data from lost, stolen,
or compromised devices
- Security policies to help protect devices
Follow the guidelines provided here to help protect company data and communications when you implement MDM in your organization.
Security and Protection for MDM is available for
download and can be viewed online at this Microsoft Web site: