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” at http://go.microsoft.com/fwlink/?LinkId=69352 and “Client Access Server Role: Overview” at http://go.microsoft.com/fwlink/?LinkId=116230.

Note:

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: http://go.microsoft.com/fwlink/?LinkId=116231. A significant feature in MDM is protected client communications and end-point device security.

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: http://go.microsoft.com/fwlink/?LinkId=112415.

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 74.92.226.130, 74.92.226.131, 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: http://go.microsoft.com/fwlink/?LinkId=116232.

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 site: http://go.microsoft.com/fwlink/?LinkId=117651.

Note:

MDM 2008 SP1 introduces the ability to deploy multiple MDM instances per forest as described in Deploying MDM 2008 SP1 in a Global Enterprise Environment. It is important to note that each instance requires separate servers running MDM Gateway Server. Although organizations can deploy servers running MDM Gateway Server associated with specific MDM instances across sites, the name resolution and routing mechanisms used to support messaging should be common between MDM instances.

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 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.

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.

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.

Note:
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 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.

Note:
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

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: http://go.microsoft.com/fwlink/?LinkID=116398.

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.

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 with MDM
  

Name Resolution Requirements for MDM Enrollment

Name Resolution Requirements for MDM Management

Name Resolution Planning for Exchange ActiveSync Publishing with MDM

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:

1. Exchange ActiveSync on the mobile device is configured to synchronize mail items with mail.contoso.com in a non-MDM environment.
   

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.

1. 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.

2. 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: http://go.microsoft.com/fwlink/?LinkID=120343.
   
3. 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.
   
4. When the user accepts the notification that policies must be applied, the user is prompted to restart the device with the new policies applied.
   

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: http://go.microsoft.com/fwlink/?Link.

The following illustration shows and example of publishing Exchange ActiveSync with MDM.

The following numbers correspond with the numbers in the illustration:

1. Exchange ActiveSync on the mobile device is configured to synchronize mail items with mail.contoso.com
   
2. The Mobile VPN Client is configured to create an IPsec tunnel with mobilevpn.contoso.com
   

   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:

1. 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.
   
2. Deploy MDM and configure policies, applying them by using GPO.
   
3. Configure an Exchange 2007 SP1 mailbox policy to enable devices to be managed outside of Exchange.
   
4. Migrate specific user mailboxes to the Exchange 2007 SP1 mailbox server.
   
5. Apply the new Exchange ActiveSync mailbox policy to the migrated mailboxes.
   
6. Create a pre-enrollment record for the Windows Mobile 6.1 device for the users whose mailbox you migrated to Exchange Server 2007 SP1.
   
7. Instruct the user to enroll the device, or enroll the device on behalf of the user.
   
8. 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 synchronization.
   
9. Validate that the device is enrolled and synchronizes mail items with Exchange ActiveSync.
   
10. 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:

Example 1

Result:

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

Last synchronized:

<Date>

Last attempt:

Today <Time>

Example 2

Alert

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:

Info

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?

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.

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

MDM Introduced to an Unpublished Exchange Server Environment

Password reset enables a user who has forgotten his or her Windows Mobile device password to reset it. To reset the device password, the user enters a one-time recovery password on the device. You can configure the recovery password to be stored on and retrieved from Exchange Server or MDM 2008 SP1.

For more information, see Configure Password Reset in MDM.

Exchange Server Password Reset

MDM Password Reset

MDM 2008 SP1 introduces the ability to manage the recovery PIN process by using MDM rather than Exchange 2007. By using MDM, mobile devices can use the recovery PIN process without Exchange 2007 which makes the feature available to organizations who use messaging systems other than Exchange or Exchange versions previous to Exchange 2007. This feature is also referred to as MDM PIN reset.

You can configure Exchange or MDM 2008 SP1 to manage the recovery PIN process, but not both. The following steps are required to implement the feature in MDM 2008 SP1.

Enable Group Policy setting: The MDM 2008 SP1 Group Policy extensions for Active Directory are required to configure the Group Policy setting that enables MDM 2008 SP1 to manage the MDM PIN reset process. This mobile policy, User Reset of Password, is found in the Password Policies container under Windows Mobile Settings.

Select MDM in the User Reset of Password setting to enable the feature in MDM. If you select Exchange Server and configure Exchange to provide this capability, a user can instead reset his or her password by using a recovery password stored on Exchange Server.

If you disable this setting, the user cannot reset the device password. The user must do a full device reset to unlock the device if he or she has forgotten the device password.

If you do not configure this setting, existing device-specific policies that control password reset on the device apply.

Note:
The Wipe Device after failed attempts Group Policy setting controls the maximum number of failed password reset attempts before the device is wiped.

Install correct version of Windows Mobile: The managed mobile device must have Windows Mobile 6.1.1 or later installed.

Install Password Reset .cab file: An MDMPasswordResetClient.cab must be installed on the Windows Mobile device. The .cab file is available as a part of the MDM 2008 SP1 Resource Kit Tools. To download the .cab file, see MDM Password Reset Client on this MDM Resource Kit Tools page here: http://go.microsoft.com/fwlink/?LinkID=127030.

We recommend that organizations use the software distribution features of MDM 2008 SP1 to securely distribute and install the recovery PIN .cab file on devices with Windows Mobile 6.1.1 or greater.

Note:
Although the MDMPasswordResetClient.cab is installed on an MDM 2008 SP1 managed device, it has no affect on the recovery PIN process until the mobile policy is configured to enable password reset in MDM and the policy is applied to the device.

Retrieving the Recovery Password in MDM

Once the mobile policy has been applied to permit MDM to manage PIN reset, the recovery password can be retrieved by one of the three methods:

1. Displaying the recovery password while viewing Enrolled Device Details using the MDM SP1 Self Service Portal.
   
2. Viewing the the recovery password by clicking on ‘ ‘ in the Actions pane of the Mobile Device Manager.
   
3. Executing the Get-MDMDeviceRecoveryPassword command from the MDM Shell specifying the device ID to retrieve the device specific password.
   

Note:
The device is not required to be connected to MDM Device Management Server during the password reset operation. When the password reset operation is completed successfully on the device, a new recovery password is generated and sent to MDM Device Management Server in a device management session. The previous recovery password can be used until the device management session begins.

MDM Cmdlets for Password Reset

Remote device wipe is a feature that sets a Windows Mobile device to delete all data the next time that the device connects to a server - the Exchange server or MDM. 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 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: http://go.microsoft.com/fwlink/?LinkId=116233.

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>]

Or

New-WipeRequest -Owner <OwnerIdParameter> [-WhatIf] [-Confirm] [<CommonParameters>]

For more information, see New-WipeRequest.

In addition to the New-WipeRequest cmdlet, administrators can use four other wipe-related cmdlets to manage device wipe requests by using MDM. The cmdlets are listed in the following table. For more information, see the topic for each cmdlet.

Get-WipeRequest

The Get-WipeRequest cmdlet returns the unprocessed wipe requests for the specified managed device.

Remove-WipeRequest

The Remove-WipeRequest cmdlet removes a wipe request for the specified managed device if the wipe request is yet unprocessed.

Get-WipeConfig

The Get-WipeConfig cmdlet returns the current configuration of the wipe service.

Set-WipeConfig

The Set-WipeConfig cmdlet configures the properties of the wipe service.

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 by using 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.

Note:
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 wipe failed.
  
• 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, 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, the device must complete the enrollment process again to connect to MDM.

For more information about device wipe, see MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=112415.

Note:

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 the 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 Server Tools to remove records for to devices that were wiped outside of MDM. The tool 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 again.
  

To download MDM Device Enrollment Cleanup Tool, see MDM Server Tools at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=127030.

MDM offers various device security policies to enhance messaging security. The following policies are managed using the Group Policy Object Editor. For detailed information, see MDM Operations at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=112415.

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 policies are 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 timeout lets 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 remembered lets 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 expiration lets 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 length lets 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 attempts lets 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 frequency lets 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 word lets 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 device lets 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 Messaging determines 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 ActiveSync lets 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 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: http://go.microsoft.com/fwlink/?LinkId=116234.

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, including password reset (if you have configured the password reset feature for MDM). MDM Self-Service Portal also provides the software required to install, manage and configure a self-service portal for your company.

You can customizae the portal to tailor the solution for organizational branding and delegation. For more information about MDM Self-Service Portal, see MDM Self Service Portal Deployment and Customization.

MDM Self-Service Portal lets users perform a device wipe in addition to using the Exchange Management Shell or OWA device wipe. In the context of MDM and Exchange Server integration, MDM 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.

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.

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 MDM Gateway Server. 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: http://go.microsoft.com/fwlink/?LinkId=116235.

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: http://go.microsoft.com/fwlink/?LinkId=116242.

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.
  

The Active Directory Configuration Tool (ADConfig) is a configuration tool that you must use to configure Active Directory for MDM 2008 SP1. ADConfig lets you do the following:

• Create the Active Directory Universal Security Groups and containers for MDM 2008 SP1
  
• Add the service connection point (SCP) for MDM 2008 SP1
  
• Create the Mobile Device Templates in the enterprise certification authority
  

For more information about ADConfig, see Configure Active Directory for MDM.

The following MDM administrative tools are further described in Operations for Mobile Device Manager.

MDM Console

Group Policy Extensions

MDM Software Distribution Management Console

MDM Shell

Event Viewer

MDM Logging

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.

Note:
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)

Exchange Logging

Services Snap-In

MDM Console

MDM Command Shell

ADSIEDIT

Report Viewer

Logman

The MDM 2008 SP1 Resource Kit Tools are available to download and include the MDM Server Tools. To download the tools, see MDM Server Tools at the following Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=127030.

MDM Server Tools includes a number of tools, such as the following:

• MDM Bulk Pre-Enrollment Tool
  
• MDM Application Hash Code Tool
  
• MDM Cleanup Tool
  
• MDM Device Enrollment Cleanup Tool
  
• MDM Certificate Tool
  

MDM Bulk Pre-Enrollment Tool

MDM Application Hash Code Tool

MDM Cleanup Tool

MDM Device Enrollment Cleanup Tool

MDM Certificate Tool

MDM Best Practice Analyzer (BPA) Tool 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.

To download BPA Tool, see MDM Best Practices Analyzer Tool at the following Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=127030.

The MDM 2008 SP1 Resource Kit Tools are available to download and include the MDM Client Tools. To download the tools, see MDM Client Tools at the following Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=127030..

The following tools are included in MDM Client Tools, along with MDM Managed Device Status Viewer.

MDM Connect Now Tool

MDM VPN Diagnostics Tool