SharePoint Server 2007 provides mobile support for Windows Mobile powered devices. Administrators define standard views of lists or libraries to be mobile enabled. Additionally, mobile information workers can view individual list items in a mobile form. Every Web list and Web library in SharePoint Server 2007 can be displayed in a mobile view.

MDM can enable internal SharePoint Server portals or Internet Information Services (IIS) Web sites for mobile device users. This document refers to IIS Web site and SharePoint Server 2007 server components collectively as a Web server farm. SharePoint Server components include SharePoint Server 2007 Front End Web Servers, SQL services, Enterprise Search services, and so forth.

Mobile Experience versus Desktop Experience

Using Internet Explorer Mobile to Access SharePoint Web Sites

stsadm -o activatefeature -name MobilityRedirect -URL http://yourSiteURL 

Advantages of MDM for Company Web Site and SharePoint Server Web Application Access

The scenarios discussed in this document focus on mobile integration for Web sites and SharePoint Server 2007 Web portals. Although the information is comprehensive, not every possible enterprise Web site or SharePoint Server scenario is discussed. This document discusses the following topology scenarios:

• Centralized
  
• Decentralized
  
• Decentralized with branch offices
  

The following sections describe each scenario.

Centralized Web Farm Topology

In the centralized topology, the implementation for an enterprise can consist of multiple domains where a central site hosts all Web server farm services. Users access services across local or wide area networks from local or regional company sites. This topology is preferred by organizations that want to minimize the IT technical footprint. They want to rely on relatively few groups in the organization to manage and monitor the Web or portal environment. For a more detailed description of the centralized SharePoint Server 2007 topology, see “Supported Global Solutions for Office SharePoint Server” at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=117925.

Enterprise organizations can use MDM Mobile VPN to publish Web server farms to mobile information workers over their cellular data network. MDM uses an IPsec virtual private network (VPN) tunnel to connect a domain-joined mobile device to the company perimeter network from the Internet. After a device is connected to the MDM VPN, the MDM Gateway Server role provides a predefined VPN IP address pool for mobile devices. These addresses let mobile users connect to Web server farms that are hosted within the company network at the central site.

The following illustration shows MDM client traffic flow relative to accessing a Web company resource using Internet Explorer Mobile.

The following steps match the numbers within this illustration:

1. Enrolled devices, called managed devices, mutually authenticate and then connect to MDM Gateway Servers using IPsec and DNS name resolution.
   
2. MDM Gateway Servers route HTTP or HTTPS traffic to the internal firewall that has rules set for HTTP or HTTPS traffic inbound. The internal firewall then routes Web traffic to Web server farms.
   
3. Web applications are routed back through the internal firewall to managed devices.
   

Considerations for Network Routing and Firewall Ports

You may need to set firewall rules to ensure that Mobile device to Web site communication appropriately traverses network boundaries and locations. Consider network routing and creating firewall rules for mobile device Internet Protocol (IP) traffic flow between the MDM Gateway Server and the company network. Depending on the how the network is engineered, you may need to introduce static routes on the MDM Gateway Server and internal firewalls. For most Web applications, mobile users use HTTP (port 80) or HTTPS (port 443) to access Web server farms. The use of these ports largely depends on the type of LOB applications in your company.

The following illustration shows an example of a centralized Web server farm topology with a basic MDM deployment.

In this scenario, you must open TCP port 80 and TCP port 443 inbound on the internal firewall. This enables mobile Web site access from the perimeter network to the company network.

Decentralized Web Farm Topology

The decentralized topology supports larger enterprises with multiple domains, multiple locations, that have decentralized management of Web server farms. This topology differs from an MDM infrastructure designed for a centralized topology in that the decentralized infrastructure design places emphasis on establishing the shortest, and hopefully quickest, route to the Web server farms. Under most scenarios, we recommend that you direct traffic to the nearest Web server farm allowing the default proxy mechanisms to operate as designed. If the messaging infrastructure is dispersed between geographic sites, you must provide a localized network route to the nearest well-connected perimeter network for your company.

The following illustration shows an example of a decentralized topology with a basic MDM deployment that spans multiple sites. To integrate MDM in this scenario, you must open TCP port 80 or TCP port 443 inbound on the appropriate internal firewalls to enable mobile Web site access from the perimeter network.

Similar to the centralized Web server farm scenario, the network route is a primary consideration for planning and deployment. Users of enrolled devices that are homed to the secondary site should connect to MDM Gateway servers in the secondary site perimeter network. Access to Web server farms would typically route through locally deployed hosts, which then proxy traffic to the appropriate Web servers.

Considerations for Network Routing and Firewall Ports

Similar to the centralized topology, you may need to set firewall rules to ensure that Mobile device to Web site communication appropriately traverses network boundaries and locations. Consider network routing and creating firewall rules for IP traffic flow between the MDM Gateway Servers and the company network. For most Web applications, mobile users use HTTP (port 80) or HTTPS (port 443) to access Web server farms. The use of these ports largely depends on the type of Internet applications in your company.

Decentralized Web Farm Topology with Branch Offices

The decentralized Web farm topology with branch offices is similar to the decentralized topology but requires support for remote locations. The branch office topology 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 Web server components or MDM server roles deployed locally. Therefore, the branch office topology 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 then proxied to the nearest Web server farm.

Some companies choose to route all traffic through a perimeter boundary Web proxy server. In this scenario, all traffic is directed from the MDM Gateway Server to a Web proxy for inspection. The Web proxy also sends Web content on behalf of mobile users that are connected through the MDM VPN.

The following illustration shows an example of the boundary Web proxy scenario.

The Web proxy in this scenario is configured with three network interfaces:

• An externally facing network interface connects to the external firewall. This is the network route for all external mobile Web traffic. The MDM Enrollment Web service can use this route for all external to internal MDM enrollment requests.
  
• An internally facing network interface connects directly to the internal network or internal firewall. This is the network route for all device management and enrollment MDM traffic. This network route includes all inbound Web server farm traffic.
  
• A perimeter interface connects to the internal network interface of the MDM Gateway Server. The MDM Gateway Server is configured to route all traffic to the Web proxy for internal or external traffic.
  

You must configure name resolution such that mobile users that are connected to the MDM VPN can resolve domain name system (DNS) server queries. For name resolution queries to work, your infrastructure must have the following:

• Appropriate IP routes must exist to DNS servers. A DNS server in the perimeter network may resolve Web site queries, or queries may be routed through the internal firewall to a DNS server in your company network.
  
• Correct access control lists (ACLs) must be established on network devices between the MDM Gateway Server and DNS server for mobile devices to correctly resolve name resolution queries.
  
• If mobile devices resolve DNS queries to the internal company network, you must open UDP port 53 on the internal firewall.
  
• If mobile devices resolve server name queries using Windows Internet Name servers (WINS) to the internal company network, open the following ports on the inner firewall:
  
  • WINS Name Services UDP Port 137
    
  • WINS Datagram Services UDP Port 138/UDP
    
  • Session Services TCP Port 139
    

Some companies choose to configure DNS resolution to use WINS when DNS queries are not resolvable. In MDM with Internet Explorer Mobile, a short name such as http://contoso is sent to the DNS server with a null domain namespace, and then sent to WINS for name resolution. When WINS and DNS are used together as in this scenario, you may need to apply a custom policy to mobile users so that they can access company sites using short names.

You can also configure Web server farms to redirect users to Virtual Directories, such as http://internalsite/pages/default.aspx. In this case, Internet Explorer Mobile may generate errors because Windows Mobile interprets the redirected site as a traversal of device security zones. For example, Internet Explorer Mobile interprets Internet domain sites using the fully qualified domain name (FQDN), and interprets Work domain sites using the NetBIOS name. To rectify this issue, you can uses mobile policies to change the client name resolution ordering behavior and add a default DNS suffix list for mobile devices. This approach enables WINS short name queries to return unresolved name queries back to the DNS servers.

The following example shows a custom administrative group policy template file (.ADM). You can modify company specific fields with your own and use this example to help overcome the name resolution issues. For information about creating custom administrative templates for group policy, see “Using Administrative Template Files with Registry-Based Group Policy” at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=117914.

Note:
Incorrectly modifying the mobile device registry may produce unwanted results. You should validate the registry settings on a small number of test devices first. Use the following registry settings at your own risk.

CLASS MACHINE
CATEGORY "Windows Mobile Settings"
      CATEGORY "Contoso DNS Settings"
           POLICY "Name Resolution Ordering"
                 KEYNAME "SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\AFD"
                         VALUENAME "NameResolutionordering"
                         VALUEON NUMERIC 4
                         VALUEOFF NUMERIC 1
           END POLICY 
           POLICY "DNS suffix"
                 KEYNAME "SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\MSEC\IPSECVPNNIC1"
                 PART "Enter the dns suffix required" EDITTEXT REQUIRED 
                        VALUENAME "Domain"
                        DEFAULT "dns.corp.contoso.com"
                        MAXLEN 32
                 END PART            
            END POLICY
      END CATEGORY 
END CATEGORY

Considerations for Using IPsec Require Mode and WINS

Some companies have IPsec Require mode between servers for enhanced security. Windows Mobile does not currently support this feature. Instead, the MDM Gateway Server role and Windows Mobile 6.1 clients provide IPsec tunnel mode VPN capability.

MDM IPsec is not the same technology as server-based IPsec Require mode. If IPsec is enabled between MDM servers, you may need to configure a group policy for mobile internet access. In this scenario, you can send resources that require IPsec authentication to a proxy that has an IT boundary exception. A boundary exception from IT ensures that that name resolution requests to company resources that are IPsec REQUIRE are sent to a proxy that does not require IPsec. The requested names can be resolved by WINS or can be FQDN expanded.

To configure a mobile group policy for Internet access, do the following:

1. Launch the Group Policy Object Editor.
   
2. Select and edit the Network Connections group policy object to apply to mobile users.
   
3. In the Configure Internet/Work Domains page, remove the asterisk (*) wildcard from the Work Domains group, and add an asterisk (*) in the Internet Domains group.
   The following illustration shows an example of these settings.
   

SharePoint Server Alternate Access Mapping

Single sign on with SharePoint enables mobile users to authenticate in the following ways:

• Using the same Active Directory user credentials on multiple SharePoint sites. This method uses basic authentication,and NTLM.
  
• Authenticating on one SharePoint server, and then authenticating with a different user account to access a company application, such as SAP.
  

In single sign on, the identity of a user who has logged on to a SharePoint portal site is mapped with another identity for the same user in the SharePoint application. For example, imagine a user named Bob has two user accounts:

A Windows account in Active Directory that he uses to log on to the local network and authenticate against the SharePoint server.

An account with different credentials that he uses to access the SAP application in the company network.

With single sign on, there is no credentials management issue. After Bob used his primary Active Directory account to log on to the SharePoint portal site, the server-side code runs on behalf of Bob using his secondary account to access the SAP system. To accomplish this, SharePoint uses SharePoint Business Data Catalog with single sign on to connect to a data source on the company network, Single sign on stores Bob’s SAP user name and password in an encrypted format in the data source.

Single sign on also supports custom Web Parts and other SharePoint 2007 services, such as Excel Services and Forms Services. Single sign on retrieves user credentials that are required when accessing various systems in your company infrastructure.

Note:
User passwords must be in a language that the Windows Mobile powered device supports. Otherwise, the user cannot access any Active Directory restricted resources.

SharePoint Server 2007 Mobile Active Directory Groups

To control access to specific resources on your SharePoint portals or Web sites, We recommend that you create one or more mobile user groups in Active Directory. This approach lets you control specific user access to sites and subsites.

Note:
Typically, SharePoint groups that you create for MDM are not the same Active Directory groups you use to manage your SharePoint site.

For more information, see “SharePoint Groups, Permissions, Site Security, and Depreciated Site Groups” at this blog: http://go.microsoft.com/fwlink/?LinkId=118339.

This section contains recommendations for introducing MDM to a Web Server Farm in the following areas:

• MDM Firewall Rules and Support
  
• Name Resolution Requirements for Enrollment
  
• Name Resolution Requirements for Management
  
• Name Resolution Planning for Web Server Farms
  
• Publishing Web Server Farms with ISA Server
  
• Publishing Web Server Farms
  
• Coexistence with Legacy Devices
  

MDM Firewall Rules and Support

Name Resolution Planning for Web Server Farms

Publishing Web Server Farms with ISA Server

The following illustrates a typical Web Server Farm publishing scenario using ISA Server 2006.

The following steps describe a typical Web server farm publishing scenario using ISA Server 2006 without MDM. Sharepoint.contoso.net/teamsite/m is used as the Web server farm uniform resource locator (URL) in the following example.

1. In a traditional ISA Server Web publishing scenario, you use Internet Explorer Mobile on an unmanaged Windows Mobile device to type the URL of the Web server farm that is located in the company network.
   
2. Unmanaged devices resolve sharepoint.contoso.net to a public facing ISA Server (or servers) which reverse-proxies Web traffic to the Web server farms located in the company network.
   
3. If HTTPS is used on the internal Web server farm, ISA typically bridges HTTPS traffic over IP port 443 between the mobile device and the Web server farms. ISA Server uses the same Web server certificate as the default Web site on the Web server farms. This lets ISA Server inspect incoming traffic as its being forwarded to the internal Web server farms. This requires that you configure a Web Listener and a Web Publishing Rule on the ISA Server.
   
4. After an HTTP or HTTPS session is created between the mobile device and Web site, the user receives data from the Web server farm.
   

Publishing Web Server Farms

The following section illustrates a typical Web Server Farm publishing scenario using MDM.

In MDM, managed devices use name resolution and IP routing to route Web traffic to applicable Web server farms through the MDM Gateway Server to the company network. The following steps show an example of the MDM scenario when a mobile user types a fully qualified site name, such as http://sharepoint.contoso.net/teamsite/m within Internet Explorer Mobile:

1. During the enrollment process, MDM configures the device to direct all MDM VPN traffic to the publicly available name resolution for mobilevpn.contoso.net.
   
2. MDM locates the MDM Gateway Server in the perimeter network using name resolution.
   
3. The MDM Gateway Server routes the name resolution queries for http://sharepoint to DNS.
   
4. The DNS server is configured to use WINS for NetBIOS name resolution and responds to the managed device with the IP address of the internal Web server farm.
   
5. The managed device connects through the firewall to the Web server farm located within the company network.
   

Coexistence with Legacy Devices

There will be many cases when MDM and Windows Mobile 6.1 devices must co-exist with devices with earlier versions. Examples of legacy devices are those that run Windows Mobile 2003, Windows Mobile 5.0, and Windows Mobile 6.

The following illustration shows legacy clients accessing Web server farms using traditional ISA server Web publishing as well as Windows Mobile 6.1 devices enrolled in MDM accessing Web server farms. In traditional ISA Server Web publishing scenarios, unmanaged devices use a public facing ISA Server and MDM managed devices use the MDM Gateway Server over IPsec.

Microsoft Office 2007 supports running InfoPath® 2007 forms in a mobile Web browser. This feature supports a broad range of mobile user scenarios.

MDM integration recommendations are the same as previously discussed. However, there are distinct differences in how InfoPath 2007 forms display on desktop computers and how they display in Internet Explorer Mobile:

The following shows how Internet Explorer Mobile handles various Web elements:

• Ignores formatting and layout
  
• Shows the date picker as a text box
  
• Does not support controls such as the rich text box, option button, section, and repeating table
  

Still, the effort required to change existing form templates to display on a mobile device is minimal.

For more information about designing InfoPath forms for mobile Web browsers, see “Designing InfoPath 2007 Forms for Mobile Web Browsers” located at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=117911.

Integrating with Data Connections

You can use the Client Access Server role in Exchange Server 2007 to publish sites by using SharePoint Server 2003 or SharePoint Server 2007. In Outlook Mobile, users can open a link to a document that is in SharePoint or can open a universal naming UNC link in an email. Instead of opening the link in Internet Explorer, the URL request goes to the Exchange Server, locates the document, and then uses ActiveSync to download it to the device. For example, if a user clicks on a link such as http://sharepoint/teamsite/document/windowsmobile.doc, a document opens in Word Mobile.

This solution is independent of MDM and works well for mobile devices in the enterprise that are not based on Windows Mobile 6.1. For Windows Mobile 6.1, MDM offers the best mobile user experience when integrated with SharePoint Server and IIS Web sites.

After a mobile device enrolls and establishes a VPN connection to MDM Gateway Server, the user can verify the SharePoint Server, Web site and MDM functionality from their mobile device. The user should be able to open a company Web site from their device. There should be no discernable difference between communicating through the MDM Gateway Servers and from any other Internet browsing scenarios. The managed device relies on the DNS servers to determine the route to take to the company network.

You should use network troubleshooting techniques to investigate and resolve any errors displayed when connecting to company Web sites. A common technique for troubleshooting Web site access issues is to validate that network routing is properly configured to support mobile devices and that they can access Web sites internally. Also, be aware that lack of cellular coverage is inherent in all mobile devices.

The following tools are described in the MDM Deployment Guide which provides prescriptive deployment guidance.

ADConfig

The following tools are further described in MDM Operations.

MDM Console

Group Policy Extensions

MDM Software Distribution Management Console

MDM Shell

We recommended that you monitor the health of the MDM infrastructure and services by deploying System Center Operations Manager (SCOM) along with the MDM 2008 management pack. For additional information about planning and deploying SCOM, see this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116245.

The SCOM management pack for MDM monitors the health of the following server roles and activities:

• MDM Setup
  
• Device Management Server Health
  
• MDM Device Management Server Health
  
• VPN Gateway Server Health
  
• MDM Self Service Portal Health
  

After the SCOM agent is installed, registry values identify the various MDM server roles and automatically deploy the appropriate role-oriented rules to MDM hosts. The first release of the MDM management pack interrogates the Windows event logs to distinguish between successful and unsuccessful health states as well as the results of key operations such as MDM setup.

The MDM management pack evaluates the following actions:

• MDM Device Management Server Setup, Uninstall, and Cleanup
  
• MDM Gateway Server Setup, Uninstall, and Cleanup
  
• MDM Administrator Tools Setup, Uninstall, and Cleanup
  
• MDM Device Management Server Setup, Uninstall, and Cleanup
  

The MDM management pack evaluates the health of the following MDM Device Management Server services:

• Device Management Engine
  
• AD/GP Driver
  
• Wipe Driver
  
• Software Distribution Driver
  
• Alerter Service
  
• Gateway Central Management Service
  
• Admin Service Core
  

The MDM management pack evaluates the health of the following MDM Enrollment Server services:

• Enrollment System Service
  
• Enrollment Web Service
  
• Enrollment Administration Services
  

The MDM management evaluates the health of the following VPN Gateway Server services:

• MDM Mobile VPN Driver
  
• MDM Mobile VPN Policy Engine
  
• VPN Agent
  
• Timeout Detection
  
• Alerter Agent
  

The MDM Self Service Portal is monitored for the following areas relative to configuration and capacity:

• MDM Self Service Portal Web site configuration properly loaded
  
• Disk free space for MDM Self Service Portal log files
  
• Proper permissions applied to App_Data folder
  
• Corrupt MDM Self Service Portal log files
  
• MDM Self Service Portal log file size
  

  Note:
  MDM Gateway Servers are deployed in workgroup mode. Therefore, communications between the MDM Gateway Servers in the perimeter network and the SCOM infrastructure requires mutual authentication. For more information, see “About Gateway Server in Operations Manager 2007” at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116246.

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: http://go.microsoft.com/fwlink/?LinkID=116247. The MDM Reporting Services User Guide, included in the download, provides information to help you understand and run MDM reports. For more information about MDM Reporting Services, see Reporting Services User's Guide for MDM 2008.

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
  
• Status
  

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 the 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
  
• Category
  
• Policy
  
• Status
  

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 assist with troubleshooting MDM at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116248.

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

WPP

Microsoft MDM 2008 Resource Kit - Server Tools

Microsoft MDM 2008 Resource Kit - Best Practices Analyzer

Microsoft MDM 2008 Resource Kit - Client Tools

Getting Started with MDM - provides information to help you understand MDM and the available tools and resources. You can view Getting Started with MDM at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=108949.

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. You can view the MDM Architecture Guide at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=116397.

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. You can view the MDM Planning Guide at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=116398.

MDM Deployment Guide – describes the steps to deploy the MDM system. You can view the MDM Deployment Guide at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=108951.

Operations for MDM – provides information about how to manage MDM devices, distribute software to managed devices, manage MDM Servers, and configure MDM Services. You can view the Operations for MDM at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=112415.

Security and Protection for MDM – provides prescriptive guidance for configuring security-related features in MDM. It also provides guidance about reducing the attack surface of MDM infrastructure security features such as:

• Encrypted access to e-mail and LoB applications from the Internet
  
• Certificate based authentication for VPN
  
• 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 Mobile Device Manager is available for download and can be viewed online at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=116255.