Troubleshooting MDM Device Management Issues

  • Article

2/9/2009

This section lists common issues encountered with System Center Mobile Device Manager device management. If MDM Device Management Server Setup fails, check the Setup log files.

Checking Device Management Server Connections

Use MDM Connect Now Tool to check the connection to MDM Device Management Server from the managed device. This tool also lets you check the following:

  • The connection status on the client device based on the following parameters :
    • Option to synchronize with MDM using the MDM Connect Now Tool.
    • Last connection date and time.
    • Status of the connection.
    • Next connection date and time.
  • Details of the schedule, default and setup.
  • The logging status of the device, enabled or disabled.

For information about MDM Connect Now Tool, see the MDM Resource Kit Tools at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=127030.

Enable Logging on a Device

With MDM Connect Now Tool, you can enable or disable various types of logging as necessary. To enable enrollment logging on a device using MDM Connect Now Tool, select Menu, and then select Logging.

For information about MDM Connect Now Tool, see the MDM Resource Kit Tools at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=127030.

  1. EnableNodeMon log - If this option is checked, the system generates a log file at \NodeCache.txt.
  2. Enable OMADM log - If this option is checked, the system generates a log file at \deviceupdate.log.
  3. Enable Enroll log - If this option is checked, the system generates a log file at \deviceupdate.log.
  4. Enable Scheduler log - If this option is checked, the system generates a log file at \Application Data\Logs\Scheduler.txt.
  5. Enable alerter log - If this option is checked, the system enables the following values:
    • Alerter
    • Nodemon InitSession
    • Nodemon configuration service provider
    • Software Distribution
    • TDET settings

An end user can select any of these values to generate a corresponding log file at \deviceupdate.log.

Validating MDM Administrator Tools Installation

After installing MDM Administrator Tools, validate that MDM is working appropriately by running the following commands from MDM Shell. Make sure you have the permissions to perform these commands and are a member of the appropriate Active Directory groups.

  • Get-MDMServer, or Get-WipeConfig, or another Device Management command, can validate that the MDM Device Management Server Administrator component is up and running.
  • Get-EnrollmentConfig can validate that the MDM Enrollment Server Administrator component is up and running.
  • Set-WipeConfig, or another Device Management command, can validate write operations to the database through the MDM Device Management Server Administrator component. Try setting a value, and then setting it back.
  • Set-EnrollmentConfig can validate write operations to the database through the MDM Enrollment Server Administrator component. Try setting a value like the GatewayURI value.

For example, say you receive the following error message:

Error contacting server : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

If you receive this message, you might have a certificate mismatch in your environment. This message could also indicate that the URL for the server in the Active Directory service connection point (SCP) has been altered.

Device Management Server Setup Fails to Configure SSL Certificates

If you run MDM Setup to install MDM Device Management Server and receive the error message Failed to configure SSL certificates for Web services or Certificate Install Failed; Error Constructing or Publishing Certificate, then MDM cannot retrieve the proper certificates from the issuing certification authority. To resolve this issue, check the following:

  • Make sure that the Enterprise certification authority is running Windows Server 2003 Enterprise Edition with SP2. MDM does not support running Windows Server 2003 Standard Edition on the Enterprise certification authority.
  • 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 certification authority.
  • Make sure that the SCMDMServerAdmins security group has Enroll and Auto-enroll permissions to the SCMDMWebServer and SCMDMGCM certificate templates.
  • Make sure that the SCMDMDeviceManagementServers security group has Enroll and Auto-enroll permissions to the SCMDMGCM certificate template. Make sure Authenticated Users has Request Certificate permissions to the certification authority.
  • Open the certification authority event log and check for errors.
  • Restart the certification authority service.

It is also possible that MDM Device Management Server is being installed in a domain that is different from the domain of the certification authority; 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 certification authority before installing MDM Device Management Server.

For more information about using new certificate templates, see the Knowledge Base article Q281260 at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=111994.

If MDM Device Management Server is being installed in a domain that is different from the domain of the certification authority, then use the following steps to resolve this issue:

  1. On the root certification authority server that issues signing certificates, open a Microsoft Management Console (MMC) window.
  2. Add the Certificates snap-in with the Computer Account option, not the Service or User options.
  3. Expand Certificates, expand Trusted Root Certification Authorities, and then select Certificates.
  4. Right-click the certificate template for Enrollment Mobile Device, and then select Properties.
  5. In the Certificate dialog box, on the Details tab, select Edit Properties.
  6. In the Certificate Properties dialog box, on the General tab, select Enable only the following purposes, and then select Add Purpose.
  7. In the User Defined Purpose dialog box, type 1.3.6.1.4.1.311.65.2.1, and then select OK.
  8. In the Certificate Properties dialog box, select Apply, and then select OK.
  9. In the Certificate dialog box, select OK.
  10. Repeat steps 4 through 9 to add the 1.3.6.1.4.1.311.65.1.1 object identifier (also known as OID) to the Gateway Central Management (GCM) certificate template.
  11. Request a new signing certificate for the issuing certification authority.
  12. Wait 30 minutes for replication to complete.
  13. Run MDM Device Management Server setup again.

Configuration Changes, Blocks, and Alerts are not Forwarded to Gateway

If MDM Device Management Server does not forward configuration changes, blocks, or alerts to MDM Gateway Server, check for the following:

  • Make sure that the MDM services on MDM Device Management Server are running and set to start automatically
  • A problem may prevent MDM Device Management Server from being able to access the SQL Server database for read or write operations. This problem can occur if you do not correctly configure networking or Microsoft SQL Server permissions
  • If the MDM GCM service stops abruptly, check the status of the service by using the Services.msc Microsoft Management Console (MMC)
  • A problem may prevent MDM Device Management Server from being able to access MDM Gateway Server. This behavior may occur if you incorrectly configure networking or certificates
  • If the virtual private network (VPN) or Alerter gateway services reject information data

In the previous scenarios, MDM Device Management Server logs a system event with detailed information. Check Event Viewer for more information about specific device management problems.

Wipe Takes Longer Than Expected

Normally, a device is wiped within ten minutes after the wipe request is submitted, depending on the network and other factors. You can perform the following steps to determine the cause of a latent wipe request.

  • Verify that management sessions work as expected.
  • Verify that the device is connected to the VPN.
  • Verify that the Gateway Server is not behind a Network Address Translator (NAT).
  • Check the Event Log on the MDM Gateway Server.
  • Use Device Log to Troubleshoot.

These are further described in the following sections.

Verify That Management Sessions Work as Expected

Management sessions must work properly for devices to receive the remote wipe command. Make sure that device management sessions that are not related to the wipe command work as expected.

You can use the MDM Connect Now Tool to verify that management sessions for devices are successful. The MDM Connect Now Tool is part of MDM 2008 SP1 Resource Kit Client Tools. You can download the MDM 2008 SP1 Resource Kit Client Tools and associated documentation at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=127030.

Verify That the Device Is Connected to the VPN

To send alerts to the device, remote wipe relies on the VPN being connected. The device may not be connected to the Mobile VPN for many reasons, but some of the most common reasons are:

  • The device is turned off.
  • The Mobile VPN is disabled.
  • The user is roaming and VPN is turned off.
  • The data connection is not configured properly.
  • The user is temporarily out of the service coverage area.

In these cases, because the device is not connected to the VPN, the device cannot receive the Alert message. When the device reconnects to the VPN, it will either receive an Alert message or will start a management session immediately if it has missed its regularly scheduled session.

Verify That the Gateway Server Is Not Behind a NAT

If the device management sessions are working, and the device you are trying to wipe is connected to the VPN, make sure that MDM Gateway Server is not behind a NAT. MDM does not support this scenario; MDM Gateway Server must have an external and an internal network adapter.

MDM Gateway Server must have a public IP address so that the Alerter can verify that the alert is valid and not from a potential attacker. The Alerter discards invalid alerts. Make sure that your Gateway is not behind a NAT.

Check the Event Log on the MDM Gateway Server

To check the Event Log, perform the following steps:

  1. On the MDM Gateway Server, open the VPN Policy Engine event Log.
  2. Search for events 5507 and events 5506 in the log:
    • Event 5506 indicates that the Alerter received a response from the device.
    • Event 5507 indicates that the Alerter sent a number of retries but did not receive a response from the device.
      A mixture of 5507 and 5506 events are expected for normal operations because some devices may be offline, out of service range, or not connected for another reason. This is generally normal.
  3. If the following scenarios occurred, you should debug further:
    • 5507 event occurred for every wipe issued.
    • 5507 event occurred for a wipe issued in a controlled environment where you know the device was connected, online and available.
    • 5507 and 5506 events occurred inconsistently.

Use Device Log to Troubleshoot

After you have confirmed that the device management sessions are working, the device you are trying to wipe is connected to the VPN, and that MDM Gateway Server is not behind a NAT, you can turn on device logging to further troubleshoot the issue.

The easiest way to turn on device logging is by using the MDM Connect Now Tool that is available in the MDM 2008 SP1 Resource Kit Client Tools.

Perform the following steps

  1. Put the MDM Connect Now tool onto the device as follows:

    1. Download the MDM Resource Kit Client Tools and associated documentation at this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkID=127030
    2. Unzip the file to a location on your computer.
    3. Connect your device to the computer by using a USB cable.
    4. Browse to the MDMResourceKit\MDMClientTools\MDMConnectNow folder, and then transfer the MDMConnectNow.cab file to the device.
    5. Disconnect your device from the computer.
    6. On the device, navigate to the location where you transferred the MDMConnectNow.cab, and then click on the MDMConnectNow.cab and install it.

  2. Enable Alerter client logging as follows:

    1. On the Start Menu, choose All Programs, and then run the MDM Connect Now Tool.
    2. Choose Menu, and then choose Logging.
    3. Under logging, select the Enable Alerter Log box.
    4. In the drop-down box, select Alerter.
      Alerter logging is now enabled and will write a log to ./deviceupdate.log on the device.

  3. Issue a wipe command from the Mobile Device Manager Console, MDM Shell, or MDM Self Service Portal. Note the time that you issued the wipe.

  4. Follow the previous instructions in Check the Event Log on the MDM Gateway Server and look for 5506 or 5507 Event IDs.

    Important

    If you see a 5506 or 5507 event, immediately transfer the deviceupdate.log from the device to a computer. You must do this before the wipe occurs, or you will lose the tracing information.

  5. Open the client logging file on the computer in a text editor such as Notepad, and then do the following:

    1. Mark the time of any 5506 or 5507 Event IDs.
    2. Search for Rejecting packet or Successful push packets in the Alerter log.

Rejecting Packet

If Rejecting packet is in the Alerter log, it means that the Alerter rejected the packet because the source address did not match the expected address. Seeing this in the logs is actually a good sign, because it means that the Alert is getting to the device.

The log will identify the expected source IP address (the IP address with which the Mobile VPN client communicates), and the actual IP address (the IP address from which the packet came). A mismatch between these addresses generally indicates one of two issues:

  • There is a routing problem on the VPN Gateway.
  • There is a network element between the Gateway and the device performing Network Address Translation (NAT) for the Gateway external IP address.

To troubleshoot the issue, perform the following steps.

Check again for a NAT in front of the MDM Gateway Server

Check the IP address in the log. Is this address known to you? Does it look like something is using NAT on the Gateway IP address?

Remove the NAT and try the wipe again.

Check the routing on the Gateway

There may be an issue with the routing on the Gateway. To diagnose the issue, you will determine the address pool, and determine the routes on the MDM Gateway Server:

  1. On a machine with the Administrator Tools installed, open MDM Shell.

  2. Run the Get-MDMGatewayServer cmdlet.

  3. Obtain the address pools for the MDM Gateway Server where devices are connecting. It will look similar to {10.10.10.0/255.255.255.0}, and may contain multiple values.

  4. Log into the machine that has MDM Gateway Server installed.

  5. At a command prompt, run the following command:

    >route print

    A list of routes will display, similar to the following:

    >route print

IPv4 Route Table
==========================================================================
Interface List
……
……
==========================================================================
==========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
         0.0.0.0          0.0.0.0  aaa.107.247.aaa  aaa.107.247.aaa     10
         3.4.0.0      255.255.0.0      aaa.54.44.1     aaa.54.44.33      1
        10.0.0.0        255.0.0.0      aaa.54.44.1     aaa.54.44.33      1
     10.10.10.0     255.255.255.0     aaa.54.44.32     aaa.54.44.33      1
………continues……
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
    aaa.23.64.227  255.255.255.255      aaa.54.44.1       1
     aaa.27.52.13  255.255.255.255      aaa.54.44.1       1
     aaa.27.52.33  255.255.255.255      aaa.54.44.1       1
    aaa.29.28.102  255.255.255.255      aaa.54.44.1       1
    aaa.29.28.136  255.255.255.255      aaa.54.44.1       1
 ………continues……

  6. In Active routes, look for routes with a network destination that matches the address pools obtained in the previous step.
    There should be only one route to each device address pool configured on MDM Gateway Server, and it should go through the external interface.
    For example if MDM Gateway Server has the following interfaces:

    • aaa.54.44.33 – external interface
    • bbb.192.0.1 – internal interface

    The correct route is as follows because it goes through the external aaa.54.44.33 interface:

    Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      10.10.10.0        255.0.0.0      aaa.54.44.1     aaa.54.44.33      1

    The following route is not correct because it goes through the internal bbb.192.0.1 interface:

    Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      10.10.10.0        255.0.0.0      aaa.54.44.1     bbb.192.0.1       1

    The following route is also not correct because there is a route through the internal interface in addition to the correct route through the external interface:

    Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      10.10.10.0        255.0.0.0      aaa.54.44.1     aaa.54.44.33      1
      10.10.10.0        255.0.0.0      aaa.54.44.1     bbb.192.0.1       1

  7. If the route is not correct, perform the following steps:

    • Restart MDM Gateway Server and check the route again. If the incorrect route still remains, correct the route by using the route command. For more information, run the route at the command prompt.
    • Check for incorrect routes in the Persistent Routes section.

  8. After the routing is correct, perform the troubleshooting steps again.

Successful Push Packet

If there are Successful push packets in the log, the device is receiving and processing alerts. If the wipe request is still taking too long, make sure that the MDM Device Management Server is functioning as expected.

If there are no Successful push packets in the log, the device is not receiving alert requests. Perform the following tasks:

  • Check the routing on the MDM Gateway Server by following the steps that are described previously in Check the routing on the Gateway.
  • Check the networking connection between the MDM Gateway Server and the device and correct any networking issues.

Wipe Now Fails

Device wipe does not work unless MDM Gateway Server has a public IP address. If MDM Gateway Server has a private IP address on the external, internet-facing network interface, the Wipe Now functionality does not work.

The device is not wiped until the next scheduled policy update occurs. This behavior is by design. The Windows Mobile device ignores Wipe Now requests when they come from a gateway server that has a private IP address.

To resolve this issue, use a public IP address on the external network interface. Or, adjust the interval for periodic policy updates for mobile devices by using MDM Shell. The following syntax shows you how to adjust the interval for periodic updates:

C:\PS>$a = Get-DeviceManagementConfig 
C:\PS>$a.ConnectInterval = New-TimeSpan -hours xx
C:\PS>Set-DeviceManagementConfig $a

In the previous example, xx is the interval in hours. The default interval is eight hours and the minimum interval is one hour. If you adjust the update interval, you limit the maximum time span between issuing the Wipe Now requests and the actual device wipe to one hour.

Warning

If you set the scheduled connect time to occur more frequently, then the device is wiped at the next scheduled connection time. However, this is not a recommended configuration because it increases network traffic and may increase the possibility of unauthorized access to the network.

The Alerter agent on the device handles Wipe Now requests. If you issue a Wipe Now request, MDM Device Management Server instructs MDM Gateway Server to send a specially formatted packet to the managed device and instructs the device to request a policy update immediately and results in a device wipe.

The Alerter agent on the device compares the IP address of MDM Gateway Server with the IP address of the gateway that sent the packet. If these addresses do not match, the packet is ignored for security reasons. The potential attacker in the company network might send alerter packets to many devices. This causes all devices to request policy updates at the same time and will overload MDM Gateway Server. The IP address comparison check helps protect the MDM infrastructure from this kind of malicious attack.

HTTP 401 Unauthorized Logon Failed

You may receive the following error message when trying to connect:

HTTP 401.1 - Unauthorized: Logon Failed.

This issue can occur if the fully qualified domain name (FQDN) or custom host header does not match the local computer name. It can also occur if you install the Windows Server 2003 operating system with Service Pack 1 (SP1) because this operating system includes a loopback-check security-related feature that helps prevent malicious attacks on your computer.

This issue occurs when the Web site uses Integrated Authentication and has a name that maps to the local loopback address. In a load-balanced array, a server running MDM Console or MDM Shell accesses the Web services on itself through the load balancer.

To resolve this issue, disable the loopback check or specify host names for any computers that are running MDM Device Management Server. For more information about this issue, see this Microsoft Web site: https://go.microsoft.com/fwlink/?LinkId=109943.

Services Fail when Restarting Device Management Server

When you restart MDM Device Management Server, you might get the message One of the services failed to start, or you might see in the Service Control Manager (SCM) that one or more of the MDM services are not started. Or, after restarting MDM Device Management Server, MDM does not function properly.

To resolve this issue, verify in the SCM that all MDM services are running. If any are not, then start them manually.

Failed to Set the Inventory Default Settings

After you install MDM Device Management Server, it may take a short time for Active Directory replication to complete. As a result, you may see non-fatal errors such as the Failed to restore the Inventory Default Settings message.

If this error message appears at the end of the installation process, and in the Setup log file, then you should run the Restore-MDMInventoryDefaults cmdlet in MDM Shell for the MDM instance that is affected. If this cmdlet returns an error, it could be for the following reasons:

  • Setup was unable to contact the Web site. To resolve this issue, make sure that the IIS service is running, and that the Web server is reachable.
  • Issues with the Web site certificates. To resolve these issues, make sure that the certificate is valid and that all MDM certificates chain to the same root certificate. The Subject name must match the Domain Name System (DNS) host name of the server.
  • Active Directory replication delays. To resolve this issue, allow some time for Active Directory to replicate the changes made by MDM Device Management Server installation, and then run the Restore-MDMInventoryDefaults cmdlet manually.
  • Setup was unable to authenticate to the IIS Web site. To resolve this issue, see the "HTTP 401 Unauthorized Logon Failed" section above.
  • SQL Server is running in a separate domain from MDM, and the logon account for installing MDM does not have access to the SQL Server instance in the separate domain. This configuration uses SQL Administrator (SA) credentials as the access method for MDM to connect to the SQL Server instance.
  • The MDM Administrator account was added to the SCMDMServerAdmins group, but the Administrator has not logged off and logged back on again. To resolve this issue, log the Administrator account off, and then log back on again.
  • The MDM Administrator account was added to the SCMDMServerAdmins group, but the change has not completed replication in Active Directory. To resolve this issue, wait for Active Directory replication to complete, after you install MDM Device Management Server.
  • The FQDN used to reach the MDM server does not match the FQDN in the MDM SCP. To resolve this issue, open MDM Shell on a computer where you have MDM Administrator Tools installed. Check the MDM Active Directory SCP and set the URL to the FQDN of MDM Device Management Server, or the MDM Device Management Server load balancer. For more information about how to configure the SCP, see the MDM Planning Guide.

Install WSUS to a Separate Web Site

MDM requires Windows Server Update Services (WSUS) 3.0 SP1 to be installed on the same server as MDM Device Management Server. You can install MDM Software Distribution Console on a remote server or desktop computer.

You must install WSUS under a new Web site, not the Default Web site. If you installed it under the Default Web site, then use this command to move it to its own Web site:

C:\Program Files\Update Services\Tools\wsusutil UseCustomWebSite true

When running the WSUS installer, select the default options except for the Database Options page. Either select the Use an existing database server on this computer option, or select the Using an existing database server on a remote computer option and specify the name of the remote computer.

Make sure that you can successfully connect to the SQL Server instance when you click Next after selecting the necessary option. If you have multiple servers running MDM Device Management Server, which means there are multiple WSUS servers, make sure that all WSUS servers use a single WSUS database instance.

Reinstalling WSUS

When you uninstall and reinstall WSUS, you must restart the MDM software distribution service.

Unresponsive WSUS Console after .NET Reinstallation

If you reinstall .NET Framework 2.0 on a server which already has the WSUS server installed, you will see the following two errors in the WSUS console: (System.IO.IOException, System.Net.WebException). Also, none of the WSUS services will restart from that moment on, resulting in the disruption of the software distribution service. To resolve this issue, do the following:

  • Make sure that IIS is not running in 32-bit mode for 64-bit computers. This setting may be enabled if you reinstall .NET Framework 2.0 for other applications. You can verify this setting by running the following command:

    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs GET W3SVC/AppPools/Enable32bitAppOnWin64

  • If the command returns 1, then run the following command:

    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

  • Run the aspnet_regiis.exe –ir command under your local .NET Framework 2.0 directory; or on 64-bit computers, go to the Framework64 directory of .NET Framework 2.0 to register ASP.NET into your ISAPI filter.

  • Make sure that ASP.NET v2.0 is set to Allowed as one of the Web Services Extensions. This configuration could be set to Prohibited as a result of reinstalling .NET Framework.

  • Restart IIS as appropriate.

Cannot Establish Trust Relationship for SSL/TLS

If the server running MDM Administrator Tools does not have the root certification authority certificate installed, you will see the following error when using MDM Console or running MDM Shell cmdlets: Error contacting server: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

To resolve this issue, copy the certificate from the root certification authority to the server running MDM Administrator Tools, and then install it.

Cannot Connect to MDM Gateway Server

You may see errors when you connect to MDM Gateway Server from MDM Device Management Server if MDM Device Management Server has two or more certificates from the same MDM instance, and at least one certificate is invalid.

To resolve this issue, remove all unnecessary certificates. Make sure that the certificate store on MDM Device Management Server contains only the GCM certificate that you want to use for communication with MDM Gateway Server, and that the object identifier of this certificate matches the current MDM instance on MDM Device Management Server.