Best Practices in MDM Deployment
2/9/2009
The following describes some best practices to deploy System Center Mobile Device Manager infrastructure.
Configuring Active Directory for MDM
- Make sure that the domain controller is online and that you can access it
Before you use the Active Directory Configuration Tool (ADConfig) parameters, make sure that all domains that contain MDM instances in the forest are functioning correctly, and that all their respective domain controllers are online and that you can access them through the Domain Name System (DNS). Check the DNS configuration for suitable network routing.
Use /enabletemplates parameter in a highly secure environment
When running the ADConfig.exe /enabletemplates parameter, Setup may fail to install certificates on Web sites in hardened environments. The cause is that the SCMDMServerAdmins group is not given the rights to enroll by default. Possible fixes for this issue can include the following:- Have a certification authority administrator manually give permissions to the group SCMDMServerAdmins to enroll. Next, uninstall and then reinstall the MDM server role you were attempting to install.
- Install the certificates manually. For more information see Manual Certificate Procedures.
MDM Groups, Containers, and Certificate Templates
Put objects, users, and containers into MDM organizational units or groups is not supported
We strongly recommend that users do not add objects, users, or containers to the following groups:Organizational Units:
- SCMDM Infrastructure Groups
Groups:
- SCMDMDeviceManagementServers
- SCMDMEnrollmentServers
- SCMDMEnrolledDevices
- SCMDMSelfServiceServers
Follow conventions when renaming and moving Universal Security Groups (USGs), containers, the SCP, and certificate templates
You should do the following when you rename or move USGs, containers, service connection points (SCPs), or certificate templates:- You can move USGs to another location in Active Directory within the same forest.
- You can take USGs out of the SCMDM Infrastructure Groups OU and place them in another OU.
- You can rename the friendly name of USGs, but you cannot change the SAM account name (Pre-Windows 2000 name).
- Do not move or rename the SCMDM container in the system container or the SCP.
- Do not move or rename the SCMDM Managed Device OU.
- Do not rename certificate templates.
MDM Server Installation
- Do not run MDM Setup installations by using elevated credentials
For security reasons, we strongly recommend that you do not run any MDM installation MSIs by using elevated credentials. We recommend that you run the Setup.MSI with an account that is a member of the SCMDMServerAdmins group only, instead of using elevated credentials.
Use enrollment autodiscovery in MDM 2008 SP1 to find a specific MDM Enrollment Server by using only the email address
You can use enrollment autodiscovery to find a specific MDM Enrollment Server by supplying an e-mail address in the device enrollment utility. In MDM 2008 SP1 you have the ability to create multiple MDM instances that are capable of supporting many MDM Enrollment Servers in a forest. When a Windows Mobile device is being enrolled, the device must be redirected to the same instance where the pre-enrollment request is made so that the process completes successfully.For more information about autodiscovery and MDM enrollment, see Device Enrollment with Mobile Device Manager.
Important
Enrollment autodiscovery in MDM 2008 SP1 works for devices that are running Windows Mobile 6.1.4 or later. On Windows Mobile versions 6.1, 6.1.1, 6.1.2, and 6.1.3 autodiscovery will work only if all devices are all enrolled to the instance whose MDM Enrollment Server is referenced by the externally facing mobileenroll DNS A record; for example, mobileenroll.contoso.com.
Use filtering to block unauthorized access to the Alerter service
For added security, you can add filtering rules to the internal perimeter firewall to block unauthorized traffic to the Alerter service port (UDP port 5359) on the managed device.Because the Alerter service communicates with managed Windows Mobile devices through the VPN tunnel, blocking port 5359 on external and internal firewalls does not impact Alerter communications (such as Wipe Now requests). Blocking port 5359 may provide additional security in the following instances:
- On the internal firewall (between the company network and the peripheral network), blocking port 5359 helps prevent a "fake" Alert from being directly submitted to the Alerter client on the device by a malicious internal user.
- On the external firewall (between the peripheral network and the Internet) blocking port 5359 helps prevent a "fake" Alert from being submitted to the Alerter client through MDM Gateway Server by a malicious user on the peripheral network.
- On the external firewall (between the Internet and the peripheral network), blocking port 5359 helps prevent a malicious Internet user from contacting the Alerter on MDM Gateway Server.
Blocking port 5359 in these instances is optional because the Alerter client validates the IP address of the alert request to ensure that it is coming only from MDM Gateway Server, and some of these ports may be blocked already by default.
- Use network adapters that support receive-side scaling
On MDM Gateway Server, you can improve performance for Windows Server 2003 Service Pack 2 by using network adapters that support Receive Side Scaling.
Use MDM Best Practices Analyzer
You can use MDM Best Practices Analyzer Tool to analyze a group of servers to determine if prerequisites for deploying MDM are met. You can also use the tool to analyze servers post-deployment to verify things such as port settings. To download MDM Best Practices Analyzer Tool, see this Microsoft Web page:
- Restart MDM services if you reinstall Windows Server Update Services (WSUS) 3.0 SP1
If you need to install and reinstall WSUS 3.0 SP1 for any reason, you must restart the SCMDMSoftwareDistributionService service when finished. This is necessary for the WSUS and MDM software distribution components to remain in sync. For procedures on how to restart the MDM software distribution service, see Stopping and Restarting MDM Device Management Server in the MDM Operations Guide.
SQL Server
- Ensure that remote connections are enabled on a SQL Server installation
Remote connections must be enabled on a SQL Server instance even if the MDM Device Management Server and MDM Enrollment Server roles are installed on the same server. If it is not enabled, the Administrator services will not function properly. Setup may complete with an error message that reads, "Could not restore inventory defaults"; or, none of the MDM Administrative services will start.
- Delete MDM database and transaction logs after you reinstall SQL Server
If you perform a new MDM installation over a preexisting installation and do not intend to upgrade the server, you must completely uninstall all server components and delete the SQL database (.mdf) and transaction log (.ldf) files from the previous installation. A remaining database or log file may produce Setup errors while reinstalling MDM after uninstalling the previous version. The reason is that the SQL scripts cannot create a new database and transaction log files if they already exist. If you do not remove the SQL database and transaction log files from the original installation, a data corruption error will occur and Setup will fail.
Ensure that the Database Master Key is backed up if you use SQL Server database encryption
If you attempt to rebuild and restore an encrypted MDM database, you may receive an error when creating an enrollment request. It will state that the Database Master Key was not backed up with the database. The database error message, Event ID 2211, will appear in the Event Viewer stating that a master key must be created or used to open the database. MDM Database Master Keys for the MDM enrollment and the Device management databases are generated during setup and need to be backed up when the databases are backed up. For more information on how to back up and restore Database Master Keys see: