Deploying MDM 2008 SP1 in a Global Enterprise Environment

2/9/2009

This guide provides you with the structure for addressing the decisions and activities that are critical to successfully integrating Microsoft System Center Mobile Device Manager (MDM) 2008 Service Pack 1 into a large, complex, or geographically dispersed enterprise environment.

This content is written for information technology (IT) specialists, generalists, consultants, partners, or anyone who requires information to plan, deploy, and support the infrastructure required to integrate MDM into a global enterprise. It presents common issues faced in deploying a product with numerous infrastructure dependencies into the global enterprise.

The document includes information about the following:

• Correctly locating and adequately sizing the MDM implementation
• Network considerations
• Roaming users
• Organizational Unit (OU) design
• Active Directory delegation
• Application distribution
• Business continuity

To better explain these areas, this document uses two case studies that are large, geographically distributed global enterprises. This lets us elaborate upon how to implement MDM in the most effective fashion.

The document contains the following sections:

• Enterprise Customer Scenarios
• MDM Multiple Instance Topologies
• MDM Server Roles
• Global Mobile Device Roaming Scenarios
• Centralized and Delegated Management
• Public Key Infrastructure Considerations
• SQL Infrastructure Considerations
• Active Directory
• Global Software Distribution Considerations
• Line of Business Application Deployment
• Business Continuity Strategies
• Supporting Documents

Note

This content does not provide step-by-step examples of deploying or operating an MDM infrastructure. It refers to supplemental material throughout, and the Supporting Documents for MDM section provides a generous list of supporting references that you may find helpful.

Enterprise Customer Scenarios

This document uses the following examples of global enterprise companies:

• Enterprise 1: WoodGrove Bank, SA
• Enterprise 2: Adventure Works, PTY

Because these examples are global deployments, they are assumed to be distributed implementations with MDM Gateways located close to the user communities.

The primary difference between the two examples is in their support and implementation models. This document addresses these differences directly on a case-by-case basis.

Enterprise 1 Centralized MDM Implementation

Woodgrove Bank, SA is a multinational company, headquartered in Luxembourg with subsidiaries in over 80 countries/regions. Their Active Directory management and administration is fully centralized in Luxembourg. They have more than 100,000 users, and have sized their predicted MDM infrastructure to support up to 40,000 concurrent Windows Mobile users over the next three years. They will carry out most MDM administration from Luxembourg, but must also be able to delegate management to local IT support personnel in certain countries/regions. Users access the Woodgrove Bank network by using an entry points located in Luxembourg, Singapore, Sao Paolo, Johannesburg or Atlanta.

They must have a very high level of availability because of the time-critical nature of their business and the fact that MDM clients (Windows Mobile 6.1 devices) run business-critical line-of-business (LOB) applications.

The following illustration shows the MDM distributed implementation for Woodgrove Bank.

Enterprise 2 Regionalized Global Implementation

Adventure Works, PTY is located in Sydney, Australia and, like Woodgrove Bank, they have subsidiaries all over the world. Their management and IT administrative model is regionalized into the following zones:

• Asia-Pacific (APAC)
• Americas (North, South, Latin Americas and the Caribbean)
• EMEA (Europe, Middle East & Africa).

They have more than 100,000 users and they have sized their MDM infrastructure to support 70,000 concurrent Windows Mobile users within the next two years.

They will manage and support MDM in three sites: Sydney, Puerto Rico and Prague. These sites are also the primary entry points to their enterprise environment.

Because of specific business requirements, users from within certain countries/regions use MDM to gain access to company resources. The primary entry points are used as backup entry points.

The following illustration shows the MDM centralized global implementation for Adventure Works.

The following table shows the number of mobile device users in each region and the timeline for deploying MDM.

Region	Number of Mobile Device Users	MDM Deployment Timeline
Americas	20,000	0 – 6 months
EMEA	20,000	6 – 24 months
APAC	30,000	0 – 6 months

Enterprise 1 and Enterprise 2 Similarities and Contrasts

Woodgrove Bank and Adventure Works have similar needs for delegating administrative authority within their enterprises. They also have country/region and job-specific requirements with regards to applying Group Policy, which they may need to delegate to IT support personnel on a case-by-case basis.

The following table shows key details for these global enterprise companies:

Woodgrove Bank	Adventure Works
Centralized Administration Model. Helpdesk is located in one central site.	Distributed Administration Model. Helpdesks are located in three regional data centers.
Expects to support 40,000 MDM clients in three years	Expects to support 70,000 MDM clients in three years
One forest, multiple domains	One forest, multiple domains
Five Internet entry points	Three Internet entry points
Needs very high availability	Needs very high availability
WSUS pushes applications to devices on an as-needed basis	Uses typical Windows Mobile 6.1 device with all applications pre-installed.

MDM Multiple Instance Topologies

In MDM 2008 SP1, an instance specifies a separate, independent installation of MDM in a forest, in a domain, or both. MDM 2008 SP1 can support multiple instances, which provides flexibility and increased manageability for companies that deploy MDM in an enterprise-wide topology. This architecture provides a security-enhanced boundary between each MDM instance; therefore, managed devices will not have access to other instances. In addition, MDM administrators in one MDM instance cannot access or administer other instances.

For more information about MDM instances, see MDM Multiple Instance Topologies in the MDM Planning Guide at this Microsoft Web page: https://go.microsoft.com/fwlink/?LinkID=130854.

MDM Server Roles

This section addresses scalability and network characteristics in the context of a complex or global deployment. For more information about MDM Server Roles, see the MDM Architecture and Planning Guides at these Microsoft Web sites: https://go.microsoft.com/fwlink/?LinkID=116397 and https://go.microsoft.com/fwlink/?LinkID=130854.

MDM Device Management Server Role

You should scale MDM Device Management Server according to the expected traffic load. This section describes the MDM Device Management Server scalability and network characteristics.

Scalability

In MDM 2008 SP1, multiple instances of an MDM Device Management Server may exist as Service Connection Points in Active Directory. Each MDM Device Management Server belongs to an MDM instance that specifies a separate, independent installation of MDM 2008 SP1. MDM 2008 SP1 enables organizations to scale deployments to 60,000 mobile users per MDM instance and each MDM Device Management Server can support up to 15,000 devices. To scale to 60,000 concurrent users, a distributed MDM deployment topoplogy is recommended with a minimum of four servers running MDM Device Management Server load-balanced in an array with a dedicated appliance behind one DNS namespace. This is the only way that you can increase the number of concurrent users to the MDM maximum of 60,000.

Because the nature of the traffic to and from the MDM Device Management Server is stateful, you must configure network affinity on the hardware load-balancing appliance. You can load balance the MDM Device Management Server array by using a dedicated load-balancing appliance, or you can use load balancing software, such as Windows Network Load Balancing.

To improve scalability and failover, we recommend that an N+1 approach be used as the sizing guidance, where N is the number of servers running MDM Device Management Server required to support the incoming device connections. The additional sizing factor is included for redundancy, so one of the servers running MDM Device Management Server can be taken offline without impacting the managed device users. For more information on MDM Device Management Server sizing guidelines, see the MDM Planning Guide at this Microsoft Web page: https://go.microsoft.com/fwlink/?LinkID=130854.

In the following examples, we recommend that MDM Device Management Server, the Active Directory Global Catalog, the SQL database for MDM, and the issuing Enterprise Certification Authority all be located in the same Active Directory site. This recommendation helps the enrollment process complete successfully. The MDM device enrollment process takes place inline when the user starts enrolling from the device. MDM Enrollment Server creates the device account in Active Directory, and then requests a certificate from the Certificate Authority. If the Certificate Authority is in a different Active Directory site, MDM device enrollment will not complete successfully. The enrollment process is designed to retry creating the Active Directory machine account, but if replication takes longer than five minutes, the enrollment process cannot complete successfully.

Woodgrove Bank MDM Device Management Server Implementation

IT operations in Woodgrove Bank are centralized in Luxembourg. The MDM Device Management Server is implemented in an array with capacity to support the 40,000 concurrent users. Any one MDM Device Management Server can be taken offline without impacting system availability. All MDM components reside in the dedicated 10.10.3.0/224 Active Directory subnet, and Woodgrove Bank has chosen to implement a single instance of MDM to meet their business and technical requirements.

The following illustration shows the Woodgrove MDM Device Management Server implementation.

Adventure Works MDM Device Management Server Implementation

High availability and IT administrative autonomy are critical for Adventure Works, therefore they have used the new multiple instance feature in MDM 2008 SP1 and deployed three separate instances of MDM within the organization. Typically, two MDM instances would be sufficient for a deployment with 70,000 mobile device users. However, Adventure Works PTY has included a third MDM instance because the EMEA location is anticipated to grow its mobile work force and LOB application user base over the planned deployment timeline of 6 to 24 months.

The MDM Device Management Server architecture in the Sydney APAC region has been designed to accommodate the projected 30,000 concurrent users. Hardware load balancing for the servers running MDM Device Management Server is effectively utilized in this scenario by using a dedicated Active Directory subnet of 172.27.11.0/224. A third server running MDM Device Management Server has been added to the Sydney APAC MDM instance for high availability and redundancy, and the MDM infrastructure components are also co-located in this site.

The following illustration shows this implementation.

Network Characteristics

In most cases, the MDM Device Management Servers are located in the primary IT location. The location of the servers is determined by the administrative and support model, and also by the location of its SQL databases.

There is limited connectivity between the MDM Device Management Server and the MDM Gateway Server. However, there is significant two-way communication between the MDM Device Management Server and the pool of virtual private network (VPN) addresses that are hosted on the MDM Gateway Servers. Therefore, we assume that internal connectivity will support this two way communication.

The following table shows the traffic in both directions.

From	To	Purpose
MDM Device Management Server	VPN Pool	Group Policy management and application distribution
MDM Device Management Server	MDM Gateway Server	Initial configuration and on-going server management
VPN Pool	MDM Device Management Server	Contacting DM on schedule for Group Policy updates.

MDM Enrollment Server Role

You should scale MDM Enrollment Server according to the expected traffic load and protect, or add, a proxy. This section describes the MDM Enrollment Server scalability and network characteristics.

Scalability

The MDM Enrollment Server can be deployed in multiple instances and multiple locations within the enterprise. We make no recommendations regarding the maximum number of MDM Enrollment Servers that you can deploy. In most companies, one MDM Enrollment Server is sufficient for each deployed instance of MDM, or as part of a two servers or greater Web farm for redundancy or failover purposes.

You can have up to four servers that are running MDM Enrollment Server as part of an MDM instance. One server that is running MDM Enrollment Server can support all the users in an MDM instance because MDM Enrollment Server actively supports devices only during the enrollment process. One MDM Enrollment Server can support up to 25 concurrent enrollment processes.

The following table shows design questions to help you determine MDM Enrollment Server allocation and placement.

Design questions	Ramifications
What degree of availability is required?	You can achieve high availability and redundancy by implementing the MDM Enrollment Server as part of a Web farm. Load balance incoming enrollment requests between two or more MDM Enrollment Servers. Unless there is a compelling reason such as that outlined below, one MDM Enrollment Server for each deployed MDM instance is adequate in most companies to service all incoming enrollment requests.
Are you expecting to enroll a very high number of clients?	If your company expects to enroll more than 5,000 enrollments per hour, you may need to regionalize the locations of the MDM Enrollment Server within each MDM instance. Few MDM implementers will need to consider this option.
Is it a constraining factor that the MDM Enrollment Server defaults to only one OU for placing new Active Directory Computer objects?	MDM Active Directory objects are automatically created in only one administrator-configured OU in the MDM Enrollment Server. Consequently, you may need to create multiple MDM Enrollment Servers to populate region-specific or role-specific OUs. For example, you could create one instance per region, or even one instance per role. Otherwise, an administrator would need to manually relocate Active Directory objects from the default OU after enrollment.
Does your Active Directory design preclude the preferred MDM Enrollment Server being located in the same site as a Global Catalog and issuing Enterprise Certification Authority?	The MDM Enrollment Server must reside in the same Active Directory site as the following: The Global Catalog where new computer objects are created The Enterprise Certification Authority that issues the MDM Device Certificates. During enrollment, MDM Enrollment Server creates the computer object for the new device in the administrator-defined OU, and then immediately requests a machine certificate on the behalf of the device. Having a Global Catalog in the same Active Directory site means the catalog services all requests. This eliminates the risk of information being written to another Global Catalog, which creates a dependency upon Active Directory replication having completed. The Enterprise Certification Authority validates a certificate creation request against Active Directory before it issues the machine certificate. If the Active Directory object is not present, or the device is not a member of the list certificate, the Certification Authority does not issue a certificate. The Enterprise Certificate Authority is using Active Directory as designed. If Active Directory replication did not complete before the Enterprise Certification Authority starts the validation of authority and verification of list, membership enrollment fails. For enterprises with multiple domains and only one instance of MDM deployed in the domain, if MDM device objects are located in other domains, you must locate a Global Catalog from each domain in this site.

Network Characteristics

The MDM Enrollment Server, whether used in an Integrated or Distributed installation, must be in the same Active Directory site as the Global Catalog and Enterprise Certification Authority that satisfy enrollment requests. If either of these conditions is not met, enrollment fails. In a multiple domain environment where computer objects created and managed by MDM are located in other domains, a Global Catalog from each domain must also be present in the site.

MDM Gateway Server Role

You should scale MDM Gateway Server according to the expected traffic load and protect, or add, a proxy. This section describes the MDM Gateway Server scalability and network characteristics.

Scalability

There is no known limit on the number of servers running MDM Gateway Server that you can deploy in your infrastructure. For scalability and failover purposes, we recommend that you use N+1 as the sizing guidance, where N is the number of servers running MDM Gateway Server required to support the incoming device IPsec sessions, and then increase that number by one for redundancy purposes. This allows any one MDM Gateway Server to be taken offline without impacting the ability to service your users. If an MDM Gateway Server is taken offline or fails, the device does not instantaneously failover to another MDM Gateway Server. However, it should failover to another MDM Gateway Server within seven minutes maximum.

MDM requires a standard load balancer, with the ability to enable affinity, also known as persistence. MDM requires no specific characteristics beyond a standard load balancer.

Note

MDM does not support load balancing the MDM Gateway Server by using the Network Load Balancing (NLB) service. NLB does not work properly with MDM, which uses a DNS scheme for load balancing the MDM Gateway Servers.

Each MDM Gateway Server must have two interfaces: an external interface to which the device connects, and an internal interface that connects to your company network. Typically, the external interface faces the Internet and the associated DNS name is published in the public DNS servers for your company.

When you use multiple MDM Gateway Servers for redundancy or load balancing, you must associate the external interface for each MDM Gateway Server to the same DNS name. DNS servers associate the IP address of each external interface to the DNS name that is provisioned in the devices as MDM Gateway Server within an MDM instance.

The following illustration shows a regionalized global implementation of MDM Gateway Server arrays. Multiple servers running MDM Gateway Server are deployed and each region maintains a separate instance of MDM.

Each MDM Gateway Server can support up to 15,000 active mobile VPN sessions. Use this number when determining the number of MDM Gateway Servers to deploy within the enterprise, and also when you deploy on a regional or geographic basis.

You can manage up to 15,000 devices on each server that is running MDM Gateway Server if your MDM system meets the following conditions:

• One hundred percent of the managed devices can have an active VPN connection.
• Up to 60 percent of the devices can have active network sessions through VPN.
• Each MDM Gateway Server can support traffic volumes up to 100 megabits per second (Mb/s).
• There may be up to 16 servers running MDM Gateway Server in an MDM instance.

Applying N+1 means that a company that needs to support 8,000 users can do so by deploying one or more MDM Gateway Servers. However, we recommend that you add a second to permit failover. This is addressed in greater detail in the Business Continuity Strategies section of this document.

In the interests of redundancy and higher availability, we recommend that a single point of failure should never knowingly be introduced into an MDM implementation. The VPN client contains load balancing and failover capability. You can install three or more MDM Gateway Servers if the environment and traffic demands merit doing so.

The following list shows how MDM load balancing and failover works:

1. Typically, you issue static IP addresses to several MDM Gateway Servers, which are then bound to a single fully qualified domain name (FQDN). For example, gateway.contoso.com is bound to IP addresses 74.92.226.130 and 74.92.226.131, which are the IP addresses of servers Gateway1 and Gateway2.
2. You configure each MDM Gateway Server with a pool of virtual IP addresses, which are assigned to the devices to use in the Mobile VPN sessions.
3. The device gets the two IP addresses from DNS and connects to one at random. If the connection fails, the device tries the next IP address and gets the next server.
4. If the client has a previously issued an IP address from the pool and contacts the Gateway Server with that IP address pool, then the client continues to try to use that IP address. If it connects to a different Gateway Server, then it receives a new virtual IP address.

You can use Group Policy to direct managed devices to use the MDM Gateway Server array in the region where they are located, such as Americas, EMEA or APAC.

There are two primary approaches to addressing scalability:

• Use Group Policy to direct devices to the closest MDM Gateway Server.
• Use one namespace with content delivery platform to locate the nearest MDM Gateway Server

Using Group Policy to Direct Devices to the Closest MDM Gateway Server

You can use Group Policies to direct mobile devices to the MDM Gateway Server closest to them. Three MDM Gateway Servers are the optimal distribution for the Adventure Works scenario. The following illustration shows this approach. Although not shown, each site is implemented according to our recommendation to implement MDM Gateway Servers in pairs.

To work in an optimal fashion, one FQDN for the MDM Gateway Server for each MDM instance is configured at the time of enrollment. All devices are configured with the same FQDN for the MDM Gateway Server at the time of enrollment. You cannot define more than one FQDN in the enrollment server for the MDM Gateway Server. After enrollment, the device connects to the MDM Gateway Server, or one of MDM Gateway Servers in an array of MDM Gateway Servers.

Once connected, Group Policy can configure the FQDN for the MDM Gateway Server in an MDM instance so that all future connections use the MDM Gateway Server that supports the region in which the device usually operates. This is determined by the device Active Directory Computer Object being located in an OU against which this particular Group Policy is applied.

For example, since Adventure Works Pty wants to have three MDM instances in its MDM deployment, new device objects will be created in the respective location of the MDM deployment. If a mobile user enrolls her device in the Americas MDM instance, the device object will be created in the SCMDMManagedDevices(Americas) OU by default where Active Directory Group Policies will be applied. The process would be similar for the EMEA and APAC locations.

Adventure Works uses the following DNS entries for their three MDM Gateway Servers:

• APAC-VPN.Adventureworks.com which resolves to the MDM Gateway Server array in Sydney.
• EMEA-VPN.Adventureworks.com resolves to the MDM Gateway Server array in Prague.
• Americas-VPN.Adventureworks.com resolves to the MDM Gateway Server array in Puerto Rico.

The process described here connects client sessions more directly to the locations where LOB hosts for the region are located, which minimizes network latency. This implementation builds on how MDM is designed to work, and is the recommended approach.

Using Content Delivery Platform to locate the Nearest MDM Gateway Server

You can use one namespace combined with content delivery platform to locate the nearest MDM Gateway Server. Content delivery platform is the mechanism by which a third party hosting service maintains tables of IP addresses to further extend DNS capabilities. For example, a DNS lookup on a host will not return the IP address of the first <A> record in the DNS being interrogated, but instead returns the IP address of the closest host geographically.

You can implement content delivery platform in a way that extends this concept beyond the geographical and maintains complex connectivity tables. In this case, the IP address returned to the interrogating device is one that connects the fastest rather than the closest physically.

This document provides a high level view of how this complex and involved capability could work if applied to an MDM implementation.

Woodgrove Bank uses content delivery platform for all managed devices. Their enterprise has five primary entry points. They use a third-party content delivery platform to redirect incoming MDM VPN sessions to MobileVPN.woodgrovebank.com to instead go the nearest MDM Gateway Server.

The following illustration shows the five Woodgrove Bank MDM Gateway Server arrays that share the same namespace, MobileVPN.woodgrovebank.com. In reality, a device is only directed to the MDM Gateway Server that is the closest geographically.

If you use the content delivery capability, it must be primarily supported by the third party content delivery platform service provider. We will support the MDM implementation from the MDM Gateway Server onward.

As an example of this method, a newly enrolled device is configured to seek MobileVPN.woodgrovebank.com as its target MDM Gateway Server. Instead of a Group Policy redirecting the device to a closer MDM Gateway Server, the content delivery platform makes this decision for the device.

Network Characteristics

The greatest latency exists on the operator network between the mobile device and the MDM Gateway Server. We presume that connectivity from the MDM Gateway Server to internal resources, such as the target LOB hosts, is better connected and that the primary network performance constraints will exist outside the enterprise. For this reason, we recommend that you locate MDM Gateway Servers as close to the user communities as possible.

Global Mobile Device Roaming Scenarios

MDM allows users to access their critical LOB applications when traveling. There are certain constraints to consider for international travelers.

How MDM Addresses Roaming

Windows Mobile 6.1 and later devices have the intelligence to detect and alert the user when roaming. Roaming only takes place when the user has chosen to connect. Additionally, MDM manages a roaming device in a different manner than a non-roaming device.

You can define apply a Group Policy to define the MDM behavior for a roaming device. The following table describes this policy. For more information about the policy, see MDM Operations at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=112415.

Group Policy

Description

Configure device management when roaming

Lets you specify whether to enable device management or software downloads and Windows Update when the device is roaming. If this setting is Enabled, you can specify the following: Allow software download and Windows Update settings: If selected, managed downloads that automatically start when a device is in roaming mode continue as they would when it is not roaming. Additionally, the device checks for new updates on Windows Update servers, as when it is not roaming. If cleared, the device does not check for new updates when roaming. Change device management schedule when roaming: If selected, the device checks for updates when roaming based on the value of Check frequency multiplier. If cleared, the device uses the default schedule to check for device management tasks while roaming. Check frequency multiplier If you select Change device management schedule when roaming, this value specifies the time between server checks. You can select an integer from 0 to 10. The device multiplies the default server connection frequency by this value. For example, if the default server connection frequency is eight hours and this value is 4, the device checks for updates every 32 hours. If you set this value to zero, the device does not check for updates when roaming. If you do not select Change device management schedule when roaming this value is ignored. If this setting is Disabled, the device checks for device management tasks while roaming, but does not accept managed downloads from MDM Device Management Server or updates from WSUS. If this setting is Not Configured, the default device settings for roaming will apply. The default setting is Not Configured.

By default, mobile devices check with MDM Device Management Server every eight hours. Using the frequency multiplier as detailed above, a value of 10 (the maximum) means that the device skips 10 eight-hour checks, so the maximum duration between checks is 80 hours. If the default schedule is changed to another value, this is what will be used by the frequency multiplier.

Windows Mobile 6.1 devices have a built-in Background Intelligent Transfer Service (BITS) client, which means that a failed push is restarted from where the failure occurred rather than having to retransmit the entire package. This applies even when the user is roaming. For example, an error could occur is the push is taking place as the user boards a plane. Roaming charges would apply in this instance, but the intelligence of the device will help keep costs down through not forcing the push to start over from the beginning.

If policy permits the user to turn off Mobile VPN, this may be the preferred choice for the roaming user. However, if it is turned off, Wipe Now will be disabled in addition to the Group Policy update capability being disabled.

Normal Roaming

The default roaming behavior is that users who travel outside their normal coverage area are subject to service availability as determined by their Mobile Operator and any operator partner agreements. For example, a Mobile Operator may have a partner agreement that roaming devices automatically connect to another operator's network when out of range from its own. In other situations, the user may need to address connectivity themselves, either directly with their Mobile Operator before leaving on their trip, or with the local operator upon arrival.

Consider service and roaming costs if the user attains connectivity to a Mobile Operator in another country or region. This is not within the scope of this guide. Such costs could be quite high. We strongly recommended that you fully research and understand the costs and impact of roaming before the user attempts to connect to MDM through another Mobile Operator service.

By default, the roaming user connects to their normal operator data service and they connect to the Internet as if they were still within their normal service area. For example, when in traveling in Europe, a user in the Americas domain connects through the partner network and their own Mobile Operator to the MDM Gateway Server in the Americas instead of through an operator in EMEA. Because of the IP address assigned to the device, a Content delivery platform-serviced infrastructure detects the user as being within their own normal area of operation, and therefore directs them to the nearest MDM Gateway Server. This may not be desirable behavior.

After the device is connected to MDM, the user can access MDM -hosted LOB hosts by connecting directly to their normally configured MDM Gateway Server.

The following illustration shows this behavior.

When designing global MDM solutions, consider the following questions within the context of CDP and global mobile roaming scenarios:

• What percentage of mobile device users will roam to other corporate regions?
• Will mobile device users from Region A need access to all mobile LOB applications while roaming in Region B?

If your MDM implementation includes regional MDM instances, you might—depending on the answers to these two questions—decide to place additional MDM Gateway Servers in each region to help ensure that MDM Gateway Server connectivity is resilient for global mobile roaming scenarios.

Adventure Works has a number of mobile device users who travel to other corporate regions. Access to mobile LOB applications is very important for their business regardless of the location from which mobile device users are connecting to MDM. To support roaming mobile device users, Adventure Works will deploy additional MDM Gateway Servers in each region to accommodate their roaming users, and, later, with their CDP implementation.

The MDM Gateway Servers are deployed in such a way that the Americas region will have additional EMEA and APAC gateways and the EMEA region will have additional Americas and APAC gateways. Additionally, the APAC region will include additional EMEA and Americas gateways. CDP will enable mobile device users to connect to the MDM Gateway Server that is closest to them in any region.

While the infrastructure requirements are substantially larger with this design, deploying additional MDM Gateway Servers enables Adventure Works to meet their coporate requirements for roaming scenarios and global LOB access.

The following illustrates the MDM Gateway Servers deployment for Adventure Works.

Cost Effective Roaming

Recognizing that international roaming charges may be unacceptably high, many travelers get a locally-sourced Windows Mobile phone or purchase a SIM card from a local Mobile Operator that has a data plan for use in their existing phone.

If the user gets a phone locally that runs Windows Mobile 6.1, they must go through your company enrollment processes before they can access LOB applications made available through MDM.

A user who obtained a local SIM card can connect to the local Mobile Operator to gain access to the Internet. MDM does not use the information on the SIM for anything other than inventory purposes. Therefore, an enrolled device will continue to be accepted as valid and authorized even though the SIM has changed. However, the user should be aware that changing the SIM also means that their phone number will change.

Unless the default MDM Gateway Server for that device is modified by Group Policy, or if CDP is in use, the user will automatically connect through the Internet back to their normal MDM Gateway Server which is matched to their respective MDM instance. This may introduce an unacceptably high degree of latency and produce a negative user experience.

The following illustration shows how the CDP interprets an IP addressed sourced from the user’s normal Mobile Operator, and so redirects it to the MDM Gateway Server in their home region.

The following illustration shows the behavior if this same user were to obtain a SIM card locally. The Content delivery platform works as intended and directs them to the EMEA MDM Gateway Server that is optimal given their location.

Regardless of which entry point is used, the user connects to LOB hosts through your company network. For example, the user may connect to their Exchange mailbox in the United States by using an EMEA MDM Gateway Server. The traffic travels across the ocean using the internal wide area network. You need to decide whether this is acceptable for your company.

You must decide what an acceptable approach will be to meeting the needs of the traveling and roaming user. We make no recommendations, other than raising awareness that latency on any connection will always be greatest between the device and the MDM Gateway Server. Therefore, the optimal approach is to make sure that you minimize the distance and routing overhead of any such connection.

Concerning the issue of locating the LOB hosts within you enterprise infrastructure, relocating an Exchange mailbox does not make sense for a short trip. However, it may be viable as an option for an extended stay. The same is true for other critical LOB applications. The nearest host should be the target for the roaming user, if possible.

Centralized and Delegated Management

MDM builds upon Active Directory to permit your company to delegate administrative responsibility on an as-needed basis. The methods to do this are the same as you would use with the Active Directory Users and Computers MMC snap-in. For more information about this concept, see the MDM Planning Guide at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=130854.

Our sample scenarios of Woodgrove Bank and Adventure Works have different administrative models and they implement MDM administration differently in order to achieve the degree of management granularity that their businesses need.

Woodgrove Bank uses the centralized topology and has deployed a single instance of MDM: WoodGrove1. Therefore all MDM tasks are carried out by individuals in the Luxembourg headquarters. They use MDM Infrastructure and Security groups to give administrators and Helpdesk personnel the permissions they need to carry out their assigned tasks.

Woodgrove Bank uses the following groups, and populates them according to the capabilities given by membership of each group, depending upon the tasks and responsibilities of the administrator:

• SCMDMServerAdmins(WoodGrove1)
• SCMDMDeviceAdmins(WoodGrove1)
• SCMDMDeviceSupport(WoodGrove1)
• SCMDMHelpDeskOperators(WoodGrove1)

The MDM Planning Guide discusses the capabilities and permissions granted to the members of each list. The MDM Planning Guide is at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=130854.

Adventure Works has a different support model. Administration and Helpdesk tasks are carried out from three regional data centers. To best use daylight hours, they move global enterprise support to different regional sites during the course of the business day.

Since separate MDM instances have been deployed for each regional Active Directory domain, each of the three domains populates their own MDM groups to permit their administrators to carry out all their assigned duties and support the MDM infrastructure, devices and users as needed.

Public Key Infrastructure Considerations

This section discusses the following concepts:

• Integrating MDM into an existing PKI
• Placing Certification Authorities in MDM
• Renewing certificates
• Checking the Certificate Revocation List for your global OU model

Integrating MDM into an Existing PKI

The Enterprise Certificate Authority required by MDM functions as the subordinate of an existing Public Key Infrastructure, whether a Microsoft PKI or that of a third party.

To implement the Enterprise Certification Authority as a subordinate, we recommend that you refer to the following documents:

• Public Key Infrastructure for Windows Server 2003, at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=120227.
• Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003, at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=120228.

For third party PKIs, you must work with the PKI owners to determine the requirements that need to be met to implement the Microsoft Enterprise Certification Authority as a subordinate. Each PKI may contain subtle differences and it is not within the scope of this guide to cover every possibility.

The following list shows some known issues but is not intended to be exhaustive:

Subject Name. Some Certification Authorities use different attribute names or add components such as serial number. For example, they could change the requested name by adding data such as a serial number and change e-mail addresses to E=.

Certificate Policies. A provider may insist on adding their policies. Adding policies later at a lower level is a violation of Certificate Policies hierarchy and leads to an Invalid Certificate Policies error.

Subject Alternative Name: The parent Certification Authority can add any type of name. For example, an e-mail address.

Accessibility of Content delivery platform and AIA URLs. If the provider uses their URL on the Internet, your company servers might have difficulty validating the CRL. This is because it is accepted practice that there be no Internet access for servers and no proxy configured in the server context. You can ask the provider if you can obtain their CRL from a server accessible from your company network, and instead embed this URL in your certificates. MDM does not currently use CRLs, so this issue may not arise.

Renewal and Content delivery platform and AIA URLs. Some PKIs do not implement key indices in Certificate Distribution Point URLs, so you cannot apply the Microsoft PKI lifetime nesting practices. Therefore, you can only renew these Certification Authorities manually, immediately before they expire.

Windows Mobile 6.1.4. When you use a third party root Certification Authority with a Microsoft Enterprise Issuing Certification Authority, Windows Mobile 6.1.4 is required. This version of the Windows Mobile operating system contains fixes for third party Certification Authority scenarios.

Issuing Certification Authority location. When you deploy mulitple global instances of MDM, we recommend that a Microsoft issuing Certification Authority be located within the same site for each MDM instance so that new device enrollments will complete successfully.

The items in this list are examples only. The list is not comprehensive. Because of the complexity of PKI, you may need to resolve other issues to achieve the objective of the Microsoft Enterprise Certificate Authority acting as a subordinate Certification Authority.

Placing Certification Authorities in MDM

The Enterprise Certificate Authority used to issue MDM Device certificates must be located in the same Active Directory site as the MDM Enrollment Server. The Global Catalog against which the enrollment process creates new Active Directory computer objects must also be in this same Active Directory site.

Although the Certification Authority that contains the MDM Certificate templates must be located in the same site, it can be in a different domain in the forest.

If these conditions are not met, enrollment will fail. Active Directory replication must be done before the enrollment process can continue. MDM handles an enrollment request immediately.

If you locate multiple MDM Enrollment Servers in the same Active Directory site, they may not depend on multiple supporting Enterprise Certification Authorities. If you cannot put them in the same site, then each MDM Enrollment Server requires an issuing Certification Authority in addition to having domain-specific Global Catalogs.

Renewing Certificates

The Enterprise Edition Certification Authority permits automatic renewal of certificates prior to expiry.

In MDM this capability is enabled for Managed devices only. For the MDM infrastructure to function normally, you must manually renew all other MDM components before they expire. If an administrator does not renew the MDM infrastructure certificates in a timely basis, it may impact the MDM service and result in avoidable support calls.

The MDM Deployment Guide provides instructions for manual renewal, or you can use MDM Certificate Tool that is available in the MDM Resource Kit Server Tools.

To view the MDM Deployment Guide, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=108951.

To download MDM Certificate Tool,see the MDM 2008 SP1 Resource Kit Server Tools at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=108953.

The following table shows how and when the certificates need to be renewed.

Component	Type	Lifetime	Renewal Status
MDM Device Management Server	MDM Web server	2 Years	Manual
MDM Enrollment Server	MDM Web server	2 Years	Manual
MDM Gateway Server	MDM Web server	2 Years	Manual
Gateway Central Management (GCM). This is located on the Device Management Server.	MDM GCM	2 Years	Manual
Enrolled Devices	Windows Mobile 6.1 Managed device	1 Year	Automatic

Checking the Certificate Revocation List (CRL)

The MDM Device Management Server and MDM Enrollment Server both use CRL checking. However, because it is built upon Microsoft PKI, it is hidden from the administrator and requires no intervention.

The MDM Gateway Server does not use CRL checking. This is because we determined that it would not meet enterprise needs for denying device access in the context of the way in which MDM is designed to be used.

Active Directory-based CRL is updated on default or administrator defined intervals. Updates can also be based on deltas, where only changes to the CRL are updated rather than the entire CRL.

In MDM, if an administrator denies access to a device, the denial must take effect immediately. It is not acceptable to wait until the CRL updates because there is a delay between the time the certificate is revoked and the CRL is updated. During the delay, the device could connect normally, which is contrary to the desired objective.

Revoking the device’s certificate also makes all forms of device wipe ineffective because the device is prohibited from connecting to the MDM Gateway Server.

A certificate that has been revoked cannot then be un-revoked. The only way that the device could join the domain again is for you to reset it to factory defaults (by using Clear Storage), and then enroll again.

To immediately block a device, administrators can implement a Device Block List on the MDM Console. There is a negligible delay between the device being blocked and the MDM Gateway Server being updated.

When a device is blocked, the MDM Gateway Server is notified that a device is on the blocked list and should not be permitted to connect.

An example of when blocking a device is appropriate is when a user loses their phone but believes they left it in a hotel. An administrator-initiated device wipe may be too drastic in this instance. Instead, you can protect the enterprise from the potentially lost device by blocking it so that it cannot connect to the MDM Gateway Server. This allows time for the device to be found and returned to the user. If it has not been returned within a certain period of time, you can then initiate the device wipe.

A lost device left powered on has very limited lifetime during which you can perform a wipe. Therefore, unless the user is quite sure of the location of the device, the most prudent course of action is to initiate a device wipe.

The following steps show how to block a device.

1. In the MDM Console, the administrator locates the device under All Managed Devices.
2. When the device is located, the administrator can select Block Device Connections or issue Wipe Now.
3. The administrator selects Block Device Connections, and at the ensuing prompt selects Yes. A message displays that states that you cannot connect to the Gateway Server if you block the device.
4. To confirm that the device is blocked, you can go to the Blocked Devices screen. If the device does not display immediately, you may need to refresh the screen.
5. The device is now blocked from connecting to the MDM Gateway Server. The MDM Gateway Server rejects any attempts at establishing a VPN connection.

The administrator can unblock the device at any time. Once unblocked, the user can use the device normally, or the administrator can initiate device wipe.

SQL Infrastructure Considerations

MDM databases are created as part of the installation process. MDM uses three SQL databases: the AdminServices database, the MobileEnrollment database, and the Device Management (TEEDB) database. The MobileEnrollment database is created during MDM Enrollment Server installation. The TEEDB database is created during MDM Device Management Server installation. The AdminServices database is created during the first installation of either MDM Device Management Server or MDM Enrollment Server.

To achieve optimal scalability of MDM, Microsoft recommends that each MDM instance be deployed with its own dedicated SQL server. The need for additional SQL servers increases the infrastructure requirements but enables MDM to function autonomously from other global MDM instances deployed throughout an enterprise.

Additional SQL Server high availability and redundancy may be achieved by leveraging SQL Server 2005 clustering. For more information on using clusters with SQL Server 2005, see the SQL Server 2005 product documentation on TechNet.

Active Directory

This section describes the following concepts:

• Designing MDM for your Active Directory OU Model
• Implementing MDM Self Service Portal
• Placing Domain Controllers
• Multiple domain scenarios
• Using Administration Delegation and Delegation of Authorities
• Using Group Policy in a Granular Way

Designing MDM for your Active Directory OU Model

By default MDM uses the SCMDMManagedDevices(InstanceName) OU created for each MDM instance during installation and stores all newly created computer objects in it. This would limit how Group Policy and WSUS pushes are accomplished except that the Active Directory computer objects can be located anywhere you choose. For convenience, MDM puts all computer objects into one location. This may not be optimal for all companies.

Rather than to leave all computer objects in the default OU, to best use the power of Active Directory and Group Policy, you can create OUs in a way that best suits your operational and support model.

After computer objects are created, you can move them between OUs at any time without the risk of impacting the MDM deployment. The actions applied to the Active Directory object that is moved depends on the Group Policy that was applied against it.

The existing OU design is in place for managing domain members such as servers, desktops and laptops. We recommend that you use the OU design for managing other domains as-is, or that you replicate it to help manage device enrollment in MDM.

Alternatively, you may want to design an OU structure that reflects your support model on a country-by-country, or region-by-region, basis. For example, Woodgrove Bank would create an OU per country/region in each domain, and within that OU would create an OU per site. The following illustration shows this concept, using the Canadian subsidiary as an example.

Adventure Works manages their mobile devices based on the role and job function of the device owner. The following illustration shows how their OU structure in the Americas domain reflects this. The EMEA and APAC domains use similar OU structures.

Active Directory, OUs and Group Policies are intentionally very flexible so that they can be used optimally by every organization.

Implementing MDM Self Service Portal

MDM Self Service Portal allows users to enroll their Windows Mobile devices, monitor enrollment status, and wipe managed devices that they no longer want or that are no longer in their possession.

MDM Self Service Portal, which is included as part of MDM 2008 SP1, is designed to be customized and configured according to the best fit of the enterprise. For example, by default an enrollment places the new Active Directory Computer Object in the SCMDMManagedDevices OU for each instance of MDM. However, you can choose any other OU, or you could implement a drop-down list to allow the user to select a geography or role.

The following list shows what MDM Self Service Portal provides:

• A Web-based means for users to begin device pre-enrollment for their Windows Mobile powered devices
• A Web-based means to view their managed Windows Mobile devices and to perform a limited set of actions on them
• Software that administrators can install, manage and configure as a self-service portal for their company
• A solution starter that administrators can use as an example for custom self-service sites

MDM Self-Service Portal is a Web-based application that lets authenticated users access company resources and services from inside the company network, or through a virtual private network (VPN).

Note

Although it is possible, we recommend that you do not install MDM Self Service Portal on the same server as either MDM Enrollment Server or MDM Device Management Server.

You can install MDM Self Service Portals for each MDM instance in the global deployment as needed, assuming the portals meet your security requirements for granting users permission to enroll and manage devices themselves. There are considerable administrative advantages in doing this, because installing MDM Self Service Portal eliminates the need of creating pre-enrollment requests. It gives the control of this process to the end user. This behavior may not be acceptable in some scenarios.

By default, similar to the MDM Enrollment Server, MDM Self Service Portal stores the newly created Active Directory Computer Objects in a single OU. However, MDM Self Service Portal is a solution starter and you can customize it.

Both Woodgrove Bank and Adventure Works have implemented MDM Self Service Portal.

Woodgrove Bank and MDM Self Service Portal

Woodgrove Bank implemented three MDM Self Service Portals in their enterprise—one for each region. Recognizing that the portal is designed as a solution-starter, Woodgrove Bank modified each portal to permit the user to select their work location from a drop-down list. MDM Self Service Portal stores the Active Directory Computer object in the corresponding OU.

As part of the enrollment policy, Woodgrove Bank provides users with the URL of the MDM Self Service Portal that supports the region they are located in (EMEA, Americas or APAC).

Adventure Works and MDM Self Service Portal

Adventure Works has multiple MDM Self Service Portals that are each used with a different MDM instance. Each portal will store the newly created Active Directory Computer Objects in the default SCMDMManagedDevices(InstanceName) OU for each MDM instance.

Adventure Works created an automated script to detect when a change occurs to this OU. The script also uses Active Directory information about the device owner (by using the “Managed By” attribute) to determine the OU to move the object into for Group Policy to be correctly applied.

The following illustration shows an object being selected from the SCMDMManagedDevicesOU(WoodGrove1) OU for Woodgrove Bank and moved to one of the target OUs. An Active Directory computer object can exist in only one OU at a time. Once moved, the Active Directory computer object is subject to the Group Policy Object that is applied to the target OU.

Placing Domain Controllers

The most important Domain Controller (Global Catalog) is the one used during the enrollment process. You must put this Domain Controller in the same Active Directory site as MDM Enrollment Server. This Active Directory site must also include the issuing Certification Authority that will create and distribute the machine certificates that the Enrollment Server requests.

The device will never contact the Domain Controller. However, because some LOB applications may need to authenticate user credentials, we recommend that you minimize the distance between the incoming MDM Gateway Server and the Domain Controller. For security reasons, we recommend that you do not create a route through the internal firewall for VPN Pool addresses to contact the Domain Controller directly. Instead, we recommend that you introduce a layer of defense by having ISA Server 2006 proxy the authentication request on the behalf of the MDM client.

Multiple Domain Scenarios in One Forest

MDM supports multiple-domains in one forest. Multiple forests would require that you implement MDM in each forest where devices are to be managed. Each forest would be separate from the other, with no interoperability or sharing of databases. Therefore, you would need to manage each MDM implementation separately.

To be located in the same Active Directory site as itself, each MDM Enrollment Server requires a Global Catalog and Enterprise Certification Authority.

Additionally, if you have one instance of MDM and will locate Active Directory computer objects created and managed by MDM in other domains, then a Global Catalog from each domain must also be located in the same Active Directory site as MDM Enrollment Server. If this criteria is not met, enrollments may fail because of Active Directory replication not completing fast enough.

Using Administration Delegation and Delegation of Authority

We recommend that you use your company’s existing support and delegation model for on-going support of MDM devices. The MDM Planning Guide details a number of different lists with different permissions and authorities for this purpose.

You should also use Active Directory delegation of authority and granting or denial of authority against the OUs. These may need to be managed and administered by other entities. For more information about this part of Active Directory capability, see the MDM Planning Guide at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=130854.

In our customer scenarios, both Woodgrove Bank and Aventure Works have regionalized support models and therefore use Active Directory delegation of authority to permit the support teams in their primary sites to carry out their duties

Using Group Policy in a Granular Way

You can use Group Policy natively within the MDM deployment in the following ways:

• Design OUs to reflect how you want Group Policy applied. For example of role-based, a Marketing OU would receive a group policy specific to its user community. Similarly, the Sales OU would receive a Group Policy, because those users may require different applications.
  Another approach would be on a site-basis, where all users located in a specific field office are subject to the same Group Policy.
• Extend the base OU by using Security Groups. This would greatly increase the granularity by which you can apply Group Policy. For example, if you use the default SCMDMManagedMobileDevices OU, you can create a Security Group that you can use to permit or deny the application of any Group Policy to members of the group. The following section provides an example of this.
• Create a Windows Management Instrumentation (WMI) script and use a WMI filter. For more information, see “Applying Group Policies to Devices through WMI Filtering” in MDM Operations at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=112415.

Global Software Distribution Considerations

In a global enterprise environment, you must consider where to deploy LOB applications and how you will deploy them.

The WSUS delivery mechanism of MDM lets you strategically distribute applications by using Group Policy, combined with WMI Filters, if needed.

One example of how you could distribute applications with MDM is to implement MDM to put all Managed devices in the default SCMDMManagedDevices(InstanceName) OU. Both Woodgrove Bank and Adventure Works are examples of accomplishing this.

You should optimize application deployment. This document gives many examples where applications are distributed on an OU basis. Although this may be appropriate for some companies, there are instances that are driven by licensing costs where it would be wasteful and costly to distribute an application to someone who doesn’t need it.

Do not assume that the MDM Administrator is also the application owner. The responsibility for determining the application distribution is often managed elsewhere within the company.

Both sample organizations have similar functional roles. For example, they have Sales departments, and the department is made up of individuals in multiple roles with differing application requirements. For the purpose of instruction, the roles are:

• Customer-facing Sales.
• Pre-Sales Support.
• Sales Support and Administration.

Using this example, the following table shows these roles and the role-specific applications that the employees need to carry out their assigned tasks:

Role	CRM Application	Ordering Application	Product Information	Expenses	Time
Customer Facing	X	X	X	X	X
Pre-Sales Support			X	X	X
Sales Administration				X	X

If you used role-based OUs, pre-sales and sales administration personnel would be issued with unneeded applications, and the company could incur unnecessary licensing expense.

Woodgrove Bank needs to be able to push an application to users as needed. Adventure Works differs in that they use standard images. and the Adventure Works scenario is described at the end of this section.

The following steps describe how Woodgrove Bank could push an application to users as needed:

1. Create a security group for each application.
2. Assign ownership of each security group to the appropriate support entity.
3. Add MDM -managed devices to each security group on an as-needed basis.
4. GPO is created by the Active Directory or MDM administrator.
5. Remove Authenticated Users from the new GPO.
6. Add the application-specific security group to the GPO.
7. GPO is applied by the administrator to the SCMDMManagedDevices OU.
8. Managed devices that are a member of the application security group will receive the package on next scheduled connection. Devices that are not members of the security group will not receive the package.

Results:

• The application owner determines who is a member of the security group, and thus will receive the GPO.
• Users only receive the applications they require for their roles.
• Only Active Directory, or the MDM administrator, implements GPO.

In the Adventure Works scenario, all mobile devices have standard images, so all applications are pre-installed. Adventure Works uses application Permit/Deny to control whether the application can run. You could use the same process as used by Woodgrove Bank such that the following is true:

• The policy that allows an application to run applies to devices in the appropriate security group.
• The policy that denies an application to run applies to all devices not in the security group.

The issue of how to address application distribution to roaming users is detailed in the Global Mobile Device Roaming Scenarios section of this guide.

Line of Business Application Deployment

For successful implementation of LOB deployments, you must address the potential issue of latency between the client and the target host. MDM minimizes the distance, and thus latency, between users and the entry to the company network.

Business Continuity Strategies

With MDM, there should be no single point of failure. This section does not address other areas, such as electrical capacity, wide area connections, Internet connections, routers or switches. It also does not address other components that help mobile devices connect to MDM, and thus the target LOB applications and MDM management capabilities.

An under-sized MDM implementation is undesirable because it could introduce single points of failure owing to the capacity not existing to permit MDM infrastructure servers to be taken offline for maintenance purposes, or in the event of failure. In all instances, we recommend that you use the N+1 guidance used earlier in this guide.

You should implement MDM Gateway Servers in arrays of 2 or more. When you implement this together with the N+1 approach, this allows you to support up to 30,000 concurrent devices, and you could take one MDM Gateway Server offline without impacting your users.

With the MDM Device Management Server, you should also apply the N+1 guidance. A load-balanced array of two MDM Device Management Servers can support up to 30,000 concurrent devices, and allows you to take one server offline without impacting users.

Ideally, you should install the MDM Enrollment Server for business continuity. We recommend that you apply N+1, and that you implement two or more MDM Enrollment Servers in a Web farm. Because of the nature of the traffic and infrequency that any one user will enroll a device, most enterprises should install only one instance of MDM Enrollment Server, in the form of a Web farm.

Supporting Documents

The following Microsoft Web sites and technical articles provide background information that may be useful for planning and deploying MDM 2008 SP1.

Designing a Group Policy Infrastructure—provides an overview of Group Policy, describes how you can plan and design your Group Policy model, and how to deploy and maintain Group Policies. To view Designing a Group Policy Infrastructure, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=75201.

Best Practices for Active Directory Delegation—describes how delegation works in Active Directory, and provides best practices. To view Best Practices for Active Directory Delegation, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=120179.

Getting Started with MDM—provides information to help you understand MDM and the available tools and resources. To view Getting Started for MDM, see this Microsoft Web site: https://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. To view Architecture for MDM, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=11639.

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. To view Planning for MDM, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=130854.

MDM Deployment Guide—describes the steps to deploy the MDM system. To view Deployment for MDM, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=10895.

MDM Operations—provides information on how to manage MDM devices, distribute software to managed devices, manage MDM Servers, and configure MDM Services. To view Operations for MDM, see this Microsoft Web site: https://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 for reducing the attack surface of the MDM infrastructure security features such as:

• Encrypted access to e-mail and line-of-business (LOB) applications from the Internet
• Certificate based authentication for virtual private network (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.

To view Security and Protection for MDM, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=130987.