This section contains common issues encountered during System Center Mobile Device Manager (MDM) Setup, which consists of separate MSI packages for MDM Device Management Server, MDM Enrollment Server, and the Administration Tools. As you install each MSI package, Windows Installer gathers information and writes it to the MDMsetup.log file. Depending on the specific device, this log file is located in the Temp, System Temp, or User Temp directory.
The ADConfig Tool
The ADConfig tool, or ADConfig.exe, is a configuration tool that you use to configure Active Directory and create the required objects, groups and certificate templates for MDM Setup. ADConfig.exe does not modify or remove inherited permissions. Therefore, inherited permissions apply to the AD objects created during ADConfig.exe. ADConfig.exe lets you do the following:
- Create the Active Directory® Universal Security Groups and
containers for MDM.
- Add the service control points (SCP) for MDM.
- Create the Mobile Device Templates in the enterprise
certification authority (CA).
- ADConfig.exe is in the ADConfig directory of the installation
disc for MDM. You can start the ADConfig tool at a command prompt,
as the following describes.
- You must run the ADConfig tool from a computer or server that
is in the same site and domain as the MDM system servers.
- You must allow for enough time for the changes to replicate
across all domain controllers before you continue with the next
parameter in the process.
- You must run the ADConfig tool from a secure local location and
not from a network share.
- You must have Domain Administrator or equivalent permissions to
create the Universal Security Groups (USG) and SCP.
- You must have Enterprise Administrator (or equivalent)
credentials to create a new template in the enterprise, because the
template writes to all Global Catalogs in the company network.
- You must have Enterprise Administrator and Administrator
permissions on the CA to enable certificate templates and grant
revocation permissions on the CA.
- For the /gpsecurity parameter, depending on the options that
you select, you must have either Domain Administrator permissions,
Schema Administrator permissions, or permissions on a specific GPO.
Do not place objects in MDM Server or other infrastructure groups. Do not add objects, users, or containers to the following:
- SCMDM2008 Infrastructure Groups OU
- SCMDM2008DeviceManagementServers Group
- SCMDM2008EnrollmentServers Group
- SCMDM2008EnrolledDevices Group
- SCMDM2008SelfService Group
You may add objects into the SCMDM2008 Managed Devices organizational unit.
Active Directory Configuration Issues
Make sure that you have the appropriate permissions to run the ADConfig.exe commands. The following shows the required permissions for each command.
Command |
Permissions |
|
This command requires that the user be a member of the Domain Administrators group. |
|
This command requires that the user be a member of the Enterprise Administrators group. |
|
This command requires that the user be a member of the Enterprise Administrators group. |
|
This command requires that the user be a member of the Domain Administrators and Schema Administrators groups. |
For more information about running each of these commands, see the System Center Mobile Device Manager (MDM) Deployment Guide. After running ADConfig.exe, allow time for the Active Directory changes to replicate fully before installing the MDM servers. If the user who runs ADConfig.exe subsequently installs the MSI packages, then this user must log off and then log back on after running the ADconfig.exe commands, and before installing the MDM servers.
System Containers, SCPs, and Security Groups
Do not move or rename the system-level containers and service connection points (SCPs). Also, do not rename any of the Universal Security Groups created by MDM, especially account names for versions prior to Windows 2000, such as samAccountName.
To remove the system containers, SCPs, and security groups created by ADConfig.exe, you must uninstall all MDM servers. For more information, see the MDM 2008 Deployment Guide and MDM Operations Guide.
Cannot Connect to Domain Controller: The Server is Not Operational
If you receive the error
Unknown Error 0x80005000: The server is not operationalwhile
you are running the
adconfig /domain
command, then the domain controller is
offline or unreachable.
To resolve this issue, follow these steps:
- Make sure that all domains in the forest are functioning
correctly, and that all domain controllers are online and reachable
through DNS.
- Make sure that there is only one domain in the domain forest;
MDM does not support multiple domains in a single domain forest.
- Check the DNS configuration for appropriate network routing.
- Connect to the domain controller by using ADSIEdit, which uses
DNS to locate the target server. If this connection succeeds, then
DNS configuration is not the issue. For more information about this
tool, see ADSIEdit Overview at this Microsoft Web site:
http://go.microsoft.com/fwlink/?LinkId=109940 - Connect to the domain controller by using LDP.EXE. If this
connection succeeds, then DNS configuration is likely the issue.
- Run
nslookupand specify a different DNS server. If this command
succeeds, then the DNS server is likely the issue.
Non-Functional Domains
If non-functional domains exist in the domain forest, or there are multiple domains in the forest, then MDM encounters an unknown error when checking the domain mode.
If you receive the error
Checking the domain mode of domain <Domain1> in forest
<Forest1> failed with an exceptionwhile running the
adconfig /domain
command, then either the AD forest has
domains that are not functioning properly, or the domain
controllers for these domains are not reachable.
To resolve this issue, follow the steps in the previous Cannot Connect to Domain Controller: The Server is Not Operationalsection above.
Error Creating Certificate Templates
If you receive errors while you create certificate
templates by using the
adconfig.exe /createtemplates
command, follow these
steps:
- If the certification authority (CA) server is in a different
domain, make sure that the logged-on user account has Administrator
credentials to the CA server.
- Make sure that you can contact the fully qualified domain name
(FQDN) and the IP address of the CA server.
- Try to create the certificate templates manually. For more
information about how to create certificate templates manually, see
Creating Manual Certificatesin the MDM Deployment Guide.
Error Enabling Certificate Templates
If you receive errors while you enable certificate
templates by using the
adconfig.exe /enabletemplates
command, follow these
steps:
- Make sure that the certification authority (CA) server is
running Windows® Server® 2003 Enterprise Edition operating
system with SP2. MDM does not support CA servers that are running
Windows Server 2003 Standard Edition.
- Make sure that the logged-on user account has Administrator
credentials to the CA server.
Setting Up Multiple MDM Servers
When setting up multiple MDM servers, allow some time for replication to complete after installing the first MDM Enrollment Server or first MDM Device Management Server. Also, allow some time for replication to complete after running ADConfig.exe, and before installing the first MDM Enrollment Server or MDM Device Management Server.
To install MDM Enrollment Server or MDM Device Management Server, you must be a member of SCMDM2008 Server Administrators group in Active Directory, and a member of the local administrators group on the computer where you are installing MDM. If you add members to a group, log off and log back on before running MDM Setup.
Database Provisioning Failed
If you receive the error message Event 10005: Error 4020. Database provisioning failed. Setup will rollback all changes, it may occur for one or more of the following reasons:
- Authentication, Domain Name System (DNS), or network issues
contacting the SQL Server database
- Incompatibility between Microsoft SQL Server and Windows-based
operating system versions
- Unsupported topology
- Corrupted database (see the following section,
Manually Deleting the Database .mdf File)
To help troubleshoot this issue, verify that you can reach the SQL Server by FQDN and IP address from MDM Enrollment Server. Check the Windows Installer MSI and server event log files for more information. Look for the SQL Server error to get an indication of the problem. If the log information is inconclusive, then check the log files on the SQL Server computer, or traces from SQL Server.
Manually Deleting the Database .mdf File
During MDM uninstall, Microsoft® SQL Server® may drop the MDM database, but leave the corresponding .ldf and .mdf files in their existing locations. This generates a database provisioning error and causes Setup to fail if you reinstall MDM.
If you intend to drop the database during uninstall, you should check after uninstallation is complete to make sure that the .ldf and .mdf files were removed. If they still exist, delete them manually.
By default, these files are located in the %SystemDrive%:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data directory.
Database Log File Has Changed
You may encounter errors in subsequent installations if you change the database log, or .ldf file. If there is an orphaned database log file in the default log location with the corresponding MDF file absent, then MDM Setup fails with a database provisioning error. This error should be outlined in the setup log.
Unexpected Error Writing to Database
If you receive the error message Unexpected error "<specific error message>" writing to database, then it is likely that there are connectivity issues with the SQL Server database. To resolve this issue, check database connectivity and configuration.
Failed to Reset Active Directory Service Connection Point
When there is a problem writing data to MDM service connection points (SCP) in Active Directory®, you receive the error message Event 10005: Error 4033. Failed to reset the Active Directory Service Connection Point. This error message can also occur if you install MDM in different domains, as all MDM servers must be members of the same Active Directory domain and site. The certification authority (CA) server must be a member of the same site, but not necessarily the same domain.
Check the following to troubleshoot this error:
- Verify that MDM Enrollment Server is in the same domain that
ADConfig.exe configures. This tool creates Active Directory objects
in the root domain. Therefore, you should install MDM in the
root domain also.
- Make sure that the computer that is running SQL Server meets
all the software and hardware requirements listed in the MDM
Planning Guide.
- Make sure that the computer that is running SQL Server is in
the same domain as the MDM system.
- Verify that the account has access (Windows Integrated
Authentication) to Active Directory.
- Verify that you can reach the computer that is running SQL
Server by FQDN and IP address from MDM Enrollment Server.
- If you are reinstalling MDM, but using a different SQL Server
database or instance name, then make sure that the Active Directory
Dependencies and Server SCPs are fully removed. When the database
is fully removed, the keywords for the Dependencies SCP should be
database=and
sqlinstance=, with no values entered.
MDM Certificates Missing on Certification Authority Server
At Setup, every computer that is running MDM, except for the non-domain joined MDM Gateway Server, installs a certificate from the certification authority (CA). If the certificates are not created on the CA server, there is likely a connectivity issue and MDM cannot access the CA server.
To resolve this issue, check the following:
- Verify that you ran the adconfig /createtemplates and adconfig
/enabletemplates commands.
- Verify that the specified CA does not have the MDM templates
enabled on it during Setup.
- During Setup, select to request certificates (a page in the
Setup Wizard).
- Make sure that you have permissions on the templates.
After you resolve issues to access the CA server, create the MDM certificates manually. For more information about how to create MDM certificates manually, see Creating Manual Certificatesin the System Center Mobile Device Manager (MDM) Deployment Guide.
WSUS Encounters Errors After Reinstalling .NET Framework
If you reinstall the .NET Framework on a computer that is running Windows Server Update Services (WSUS), it may cause errors in the WSUS console. Then, the WSUS services will not restart. These symptoms result in the disruption of MDM software distribution.
Follow these steps to restore WSUS and MDM software distribution functionality.
- Make sure that IIS is not running in 32-bit mode for 64-bit
computers. This mode may reset if you reinstall .NET
Framework 2.0 for applications other than MDM. To verify the
IIS application mode, at a command prompt, run the following
command:
Copy Code cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs GET W3SVC/AppPools/Enable32bitAppOnWin64
Copy Code cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
- In your local .NET 2.0 directory, run
aspnet_regiis.exe –ir
. For 64-bit computers, locate the .NET 2.0 directory, and then the Framework64 directory to register ASP.NET into your Internet Server API (ISAPI) filter. - Make sure that you set ASP.NET 2.0 to
Allowedfor the Web services extensions. This property may
reset to
Prohibitedwhen you reinstall .NET Framework.
- Restart IIS.
Event 9030: The Port Specified is Invalid
If you receive the error message Event 9030, The port specified is invalid, while upgrading MDM Device Management Server from an earlier version of MDM, you can safely ignore this event because it does not affect the functionality of the servers in any way.
Enrollment Server Setup Fails to Configure SSL Certificates
If you run MDM Enrollment Server setup and receive the error message Failed to configure SSL certificates for Web servicesor Certificate Install Failed; Error Constructing or Publishing Certificate, then MDM cannot retrieve the proper certificates from the issuing certification authority (CA). To resolve this issue, check the following:
- Make sure that the Enterprise CA is running Windows Server 2003
Enterprise Edition with SP2. MDM does not support running Windows
Server 2003 Standard Edition on the Enterprise CA.
- Verify that the domain functional level is raised to Windows
Server 2003, as described in the MDM Deployment Guide.
- Verify that you created and enabled the MDM templates on
the CA.
- Make sure that the SCMDM2008ServerAdministrators security group
has Enroll and Auto-enroll permissions to the SCMDM2008WebServer
and SCMDM2008GCM certificate templates.
- Make sure that the SCMDM2008DeviceManagementServers security
group has Enroll and Auto-enroll permissions to the SCMDM2008GCM
certificate template. Make sure Authenticated Users has Request
Certificate permissions to the CA.
- Open the CA event log and check for errors.
- Restart the CA service.
It is also possible that the MDM Enrollment Server is being installed in a domain that is different from the domain of the CA; or, the certificate enrollment request is using a certificate template that was recently created. You should wait for 30 minutes after the templates are enabled on the target CA before installing MDM Enrollment Server.
For more information about using new certificate
templates, see KB article Q281260 at this Microsoft Web site:
If MDM Enrollment Server is being installed in a domain that is different from the domain of the CA, then use the following steps to resolve this issue:
- On the root CA server that issues signing certificates, open a
Microsoft Management Console (MMC) window.
- Add the
Certificatessnap-in with the
Computer Accountoption, not the
Serviceor
Useroptions.
- Expand
Certificates, expand
Trusted Root Certification Authorities, and then select
Certificates.
- Right-click the certificate template for Enrollment Mobile
Device, and then select
Properties.
- In the
Certificatedialog box, on the
Detailstab, select
Edit Properties.
- In the
Certificate Propertiesdialog box, on the
Generaltab, select
Enable only the following purposes, and then select
Add Purpose.
- In the
User Defined Purposedialog box, type
1.3.6.1.4.1.311.65.2.1, and then select
OK.
- In the
Certificate Propertiesdialog box, select
Apply, and then select
OK.
- In the
Certificatedialog box, select
OK.
- Repeat steps 4 through 9 to add the
1.3.6.1.4.1.311.65.1.1OID to the GCM certificate template.
- Request a new signing certificate for the issuing CA.
- Wait 30 minutes for replication to complete.
- Run MDM Enrollment Server setup again.
Enrollment Server does not Update Device Certification Authority Information
If you uninstall MDM Enrollment Server but keep the existing databases, then re-install MDM Enrollment Server on another computer, the new device certification authority (CA) information does not get updated in the database. To resolve this issue, run the Set-EnrollmentConfigcmdlet with the new CA information.
Uninstalling MDM
Uninstalling MDM involves removing System Center Mobile Device Manager (MDM), its databases, and Active Directory Objects. If the standard uninstallation procedures are not an option, such as in a disaster recovery scenario, use the manual removal steps as described in the “MDM Backup and Recovery” topic at this Microsoft Web site:
If you are reinstalling or migrating to a new version of System Center Mobile Device Manager (MDM), you can minimize disruption to Windows Mobile powered devices by keeping all currently-active gateways, and reinstall the gateways last, after verifying that all servers are installed and operating appropriately.
When uninstalling MDM, keep the following considerations in mind:
- Uninstalling MDM Device Management Server or MDM Enrollment
Server fails with a database provisioning error if you ran the
ADConfig /unconfig /force command before starting the
uninstallation. Uninstalling MDM requires access to Active
Directory and the MDM AD infrastructure. Contact the support team
for assistance with recovery.
- Uninstalling MDM Device Management Server or MDM Enrollment
Server fails if the relevant AD SCP is missing or corrupt. Use
ADSIEdit to verify and edit the keyword values. If the SCPs are
missing, see the previous point.
- Setup fails to uninstall the servers if the
SCMDM2008ServerAdministrators or any other infrastructure group
(for example, SCMDM2008DeviceManagementServers or
SCMDM2008EnrollmentServers) is removed before uninstalling the
servers.
- Uninstalling MDM Device Management Server or MDM Enrollment
Server fails if the MDM databases are deleted before the
uninstallation. SQL Server must be available for uninstallation to
succeed.
- Uninstalling MDM servers may fail if the IIS metabase is in an
unstable or unexpected state (for example, if you manually changed
the Web site properties). Restore a backup of the metabase if it
exists.
- Uninstalling MDM servers fails if IIS is uninstalled before
uninstalling MDM. Setup fails to uninstall MDM Device Management
Server, MDM Enrollment Server, and Gateway Server if IIS is
uninstalled before removing these servers. Also, if you need to
reinstall IIS for some reason, make sure you backup the metabase
before this operation, and restore it later. After the metabase is
restored, Setup can uninstall the MDM servers.
- You must restart the VPN Gateway Server after uninstallation.
The Ipsecvpn driver is loaded into the memory. If an uninstallation
procedure cannot remove it from the memory, the next installation
uses the old driver until the next restart. Therefore, reboot the
VPN Gateway Server after uninstalling MDM.
- Only currently-installed MDM Device Management Server computers
should belong to the SCMDM2008DeviceAdministrators security group.
- Only currently-installed MDM Enrollment Server computers should
belong to the SCMDM2008EnrollmentAdministrators security group.
- Only currently-installed MDM Self Service Portal Servers should
belong to the SCMDM2008SelfService Universal Security Group.
Removing MDM Objects from Active Directory
To remove the MDM structure from Active Directory, including all MDM objects, groups, and certificate templates, open a command prompt window and run these commands in the following sequence (with the /domain switch last):
Copy Code | |
---|---|
ADConfig.exe /enabletemplates /ca:<ca_server>\<ca_name> /unconfig [/quiet] [/force] ADConfig.exe /createtemplates /unconfig [/quiet] [/force] ADConfig.exe /gpsecurity:<all|ID> /gpdomain:<domain_name> /unconfig [/quiet] [/force] ADConfig.exe /gpsecurity:default /unconfig [/quiet] [/force] ADConfig.exe /domain:<domain_name> /unconfig [/quiet] [/force] |
Only use the
/forceparameter if the Active Directory object is not
removed. If you run ADConfig.exe with the
/forceparameter while MDM is installed, then you will not be
able to un-install MDM. For recovery steps, see
MDM Backup and Recoveryat this Microsoft Web site:
Verifying Database Removal
After you uninstall MDM Device Management Server, MDM Enrollment Server, and MDM Administrator Tools, make sure that the MDM databases and SQL Server logins were removed correctly by using Microsoft SQL Server® Management console or Microsoft SQL Server® Management Studio Express. If necessary, go back and remove the databases and logins. Make sure that you uninstall the MDM system and components first, before you remove a SQL Server database.
If you modify databases and database logins directly, this may cause system problems or issues. If you decide to modify the databases and database logins directly, you do so at your own risk.
Follow these steps to make sure that you removed the databases successfully:
- Open Microsoft SQL Server Management Studio.
- Connect to the database server.
- Expand the server list.
- Expand
Databases.
Delete the following databases if they appear:
AdminServices, MobileEnrollment, TEEDB.
- After you delete a database, the
Delete Objectmessage appears. Make sure that you select the
Close Existing Connectionscheck box.
- Expand
Security.
- Expand
Logins. Delete the following Logins if they appear:
- domain name/MDM2008DeviceManagementServers
- domain name/MDM2008EnrollmentServers
- domain name/MDM2008ServerAdministrators
- domain name/MDM2008DeviceManagementServers
If you receive a warning message that you are about to delete these logins, confirm the deletion(s) and then continue with the migration process.
Preserving Device Accounts
To preserve devices and to avoid device wipes and re-enrollments, copy the devices in your device organizational unit (OU) to a temporary OU. Then rename the DefaultEnrolledDevices group to DefaultEnrolledDevicesBeta2. This does not work if the devices have not been enrolled, or if you must upgrade them to a new version.