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.

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.

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

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/?LinkID=109297.

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

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

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

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

The MDM 2008 Resource kit is available for download at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=116086.

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

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

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.

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

ADConfig

The following MDM administrator tools are further described in the MDM Architecture Guide and in MDM Operations.

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 Resource Kit – Server Tools is available as a download at http://go.microsoft.com/fwlink/?LinkID=116086. It includes the following:

MDM Bulk Pre-Enrollment Tool

MDM Application Hash Code Tool

MDM Cleanup Tool

MDM Device Enrollment Cleanup Tool

MDM Certificate Tool

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

You can download the MDM Resource Kit Client Tools at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116254.

MDM Connect Now Tool

VPN Diagnostics Tool