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.

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.

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:

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. To do this, you can use software load balancing or 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

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

Network Characteristics

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

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.

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.

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.

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.

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: http://go.microsoft.com/fwlink/?LinkId=120227.
  
• Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003, at this Microsoft Web site: http://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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.