11/11/2008

This System Center Mobile Device Manager (MDM) Global Deployments Guide provides you with the structure for addressing the decisions and activities that are critical to successfully integrating MDM into a larger, more complex, or geographically dispersed enterprise environment.

This document 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 the 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:

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:

This document 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 20,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 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 15,000 concurrent Windows Mobile users within the next 3 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.

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 3 regional data centers.

Expects to support 20,000 MDM clients in three years

Expects to support 15,000 MDM clients in three years

One Forest, Multiple domains

One Domain

Five Internet entry points

Three Internet entry points

Needs very high availability

Availability not as critical

WSUS pushes applications to devices on an as-needed basis

Uses typical Windows Mobile 6.1 device with all applications pre-installed.

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

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, only one instance of an MDM Device Management Server may exist as a Service Connection Point in Active Directory. To increase up to 30,000 concurrent users, you can load-balance three MDM Device Management Servers in an array with a dedicated appliance behind one namespace. This is the only way that you can increase from 10,000 concurrent users up to the MDM maximum of 30,000.

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

In the following examples, we recommend that the MDM Device Management Server, Global Catalog, SQL database and Issuing Enterprise Certification Authority all be located in the same Active Directory site.

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

The following illustration shows this implementation.

Adventure Works MDM Device Management Server Implementation

High availability is not as critical for Adventure Works, therefore they have implemented the MDM Device Management Servers to accommodate 15,000 concurrent users, with the capacity to support an additional 5,000 users if required. Instead of a dedicated load balancing appliance, they are using a software solution (such as Windows Network Load Balancing) in a dedicated Active Directory subnet of 172.27.11.0/224.

The MDM infrastructure components are located in Sydney, where their primary data center and headquarter-based IT support personnel are also located.

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, or two servers or greater server Web farm for redundancy or failover purposes.

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 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. 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 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 the 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, 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 MDM Gateway Servers 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 MDM Gateway Servers 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 fail to another MDM Gateway Server. However, it should fail 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 as MDM Gateway Server in the devices.

The following illustration shows a regionalized global implementation of MDM Gateway Server arrays.

Each MDM Gateway Server can support up to 5,000 concurrent 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.

Applying N+1 means that a company that needs to support 8,000 users can do so with two or more MDM Gateway Servers. However, we recommend that you add a third to permit failover. This is addressed in greater detail in the Business Continuity Strategiessection 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 it.

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

To facilitate and automate implementation, all Americas computer objects are placed in an OU located in the Americas Active Directory domain. EMEA computer objects are placed in an OU in the EMEA domain. All other devices default to the APAC SCMDM2008ManagedDevices OU. This process is only automated by default if you have a region-specific MDM Enrollment Server.

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

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

A user in the Americas domain initially connects to the MDM Gateway Server in the APAC domain to receive the initial Group Policy push. Group Policy configures the device such that future VPN connections go directly to the MDM Gateway Server array in the Americas domain (Americas-VPN). Client sessions also connect more directly to the locations where LOB hosts for the region are located, which minimizes network latency.

A user in the EMEA domain behaves in a similar fashion, but Group Policy configures future VPN connections to use the EMEA (EMEA-VPN) MDM Gateway Server array.

The MDM Gateway Server in the APAC domain (Mobile-VPN) is the default to which devices connect because APAC is the Corporate headquarters and most likely to be the site where the MDM Device Management Server array is located. Group Policy to redirect to another geographic region is applied only to devices located outside the APAC domain.

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 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: http://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 the 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 is 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 to their own Mobile Operator in the Americas instead of 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.

The following illustration shows how the user connection would look after Group Policy is applied.

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 Content delivery platform is in use, the user will automatically connect through the Internet back to their normal MDM Gateway Server. This may introduce an unacceptably high degree of latency and produce a negative user experience.

The following illustration shows how the Content delivery platform 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: http://go.microsoft.com/fwlink/?LinkID=116398 .

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

Woodgrove Bank uses the centralized topology, 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:

  • SCMDM2008ServerAdministrators

  • SCMDM2008DeviceAdministrators

  • SCMDM2008DeviceSupport

  • SCMDM2008HelpDeskOperators

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

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.

Each of the three domains populates the 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:

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.

The items in this are examples only. This 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 the MDM Cert tool that is available in the MDM Resource Kit.

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

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

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

Active Directory

This section describes the following concepts:

  • Designing MDM for your Active Directory OU Model

  • Implementing the 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 SCMDM2008ManagedMobileDevices OU created 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 reflects this.

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

Implementing the MDM Self Service Portal

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

The Self Service Portal 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 SCMDM2008ManagedDevices OU. 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 powered 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

The MDM Self Service Portal is part of the MDM Resource Kit, and is available for download at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkID=116086 .

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 in the global deployment as needed, assuming they meet your security requirements for granting users permission to enroll and manage devices themselves. There are considerable administrative advantages in doing this, because it 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 instances.

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

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

Woodgrove Bank and 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. The 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 Self Service Portal

The following illustration shows MDM Self Service Portal installed as a single instance in a web farm located in the Sydney Headquarters.

The newly created Active Directory Computer Objects are stored in the default SCMDM2008ManagedDevices OU. 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 SCMDM2008ManagedDevicesOU 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 the 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 will locate MDM -created and managed Active Directory computer objects in other domains, then a Global Catalog from each domain must also be located in the same Active Directory site as the 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: http://go.microsoft.com/fwlink/?LinkID=116398 .

The following shows how our example customers would use delegation of authority:

  • Woodgrove Bank has a regionalized support model. They use Active Directory delegation of authority to permit the support teams in their three primary sites to carry out their duties.

  • Adventure Works have a centralized administration model. They manage everything from their Sydney headquarters.

Although Active Directory delegation is fully supported, there is currently no mechanism by which access to the MDM Databases through the MDM. For this reason, we recommend that MDM access always be centralized.

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 SCMDM2008ManagedMobileDevices 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: http://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. Some LOB applications are obviously a natural fit for MDM. MS Exchange Server 2007 is an example, and integrating it into MDM is extensively documented here.

Other applications need to be addressed on a case-by-case basis.

One example of how you could distribute applications with MDM is to implement MDM to put all Managed devices in the default SCMDM2008ManagedDevices OU. Both Woodgrove Bank and Adventure Works will be used as examples.

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 SCMDM2008ManagedDevices 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 Scenariossection of this guide.

Line of Business Application Deployment

For successful implementation, 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. This allows you to support up to 5,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 10,000 concurrent devices, and allows you to take one server offline without impacting users. There is a maximum of three MDM Device Management servers per Active Directory forest. Therefore the N+1 guidance applies only up to 20,000 concurrent 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 the Enrollment Server, in the form of a web farm.

You can use SQL Server 2005 clustering to achieve high availability and redundancy for MDM databases. We recommend that you do this only for business continuity. For more information on clusters with SQL Server 2005, see the product documentation.

Supporting Documents

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

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

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

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