Troubleshooting device connection to the Device Management server

Jarrett Renshaw — Wed, 20 Aug 2008 00:25:00 GMT

You are enrolled. The device resets and shortly afterward you see the checked "V" icon, indicating you have a successful VPN tunnel to the MDM GAteway. Yes!

Now you wait for that PIN policy to come down, or that software package... and nothing happens.

Hmmm... are we REALLY connecting to the VPN server? The VPNDiag tool confirms that indeed we are.

At this point, the device has a VPN tunnel to the MDM Gateway, but something is wrong with the rest of the path to or from the Device Management server. (If VPN is not working, check out the Enrolled device cannot connect to Gateway topic the Technet troubleshooting documentation.)

If VPN is working but the client cannot connect to the DM, the client will not receive policy, software or Wipe Now requests. Until the device can contact the device management server and become managed, it remains in the Pending Enrollments node.

Troubleshooting

Test the DM server URL from the client and the DM server. You can find the URL in a number of ways to verify it is correct:

a. Device Status Viewer tool in the Client Resource kit. The URL is displayed on the home screen of the tool

b. \Deviceupdate.log on the device will show this if logging is enabled (see troubleshooting step 2 below)

c. The URL is also stored in the SCMDM2008DeviceManagement Active Directory SCP under ‘keywords’ > “url=”

d. You can easily enter the URL on the device or a test computer using the format:

https://DMServer.Mydomain.com:8443/MDM/TEE/handler.ashx

Enter this into Pocket IE on the device. You should get a “Choose a certificate” warning.

If the device cannot connect to the URL, you can also test this URL locally on the DM to narrow down the issue to connectivity or a problem with the server itself.

We’ll assume for now that the DM can connect to the URL using the localhost address so we know IIS and the server-side MDM services are working. Only devices cannot reach the DM. In this case, the issue is with the network, firewall, web certificate, or DNS.

The device might fail to contact the device management server for the following reasons:

1. It is necessary for the device to be able to resolve the FQDN of the DM server in DNS. Make sure there is a correct A record on the DNS server for the DM server. Depending on the network topology, DNS may be configured in different ways. If using the DNS server on the internal network, DNS traffic must be allowed on the internal firewall so the device can query the DNS server. If using a DNS server on the perimeter network, DNS must be configured to resolve the DM FQDN to the internal IP address of the DM.

2. The company firewall is blocking port 8443. For a list of ports required by SCMDM on the firewall see the planning guide.

3. The company proxy is blocking TCP port 8443 to the device management server. Allow tunneling on this port to allow the device to contact the device management server. This will only occur if the device connected successfully once before and received proxy policy. For details and resolution steps see Error 2147467259 When Synchronizing Policy in the Technet troubleshooting documentation.

4. A persistent route is needed on the MDM gateway to the corporate network through the back-end firewall, and another route is needed on the back-end firewall server to the VPN client address pool subnet through the MDM gateway. One simple method that may or may not satisfy your topology requirements is to configure the routes locally on the MDM Gateway and backend firewall servers as shown in this example:

Route #1 (on the GW): “route –p add <corporate subnet> mask <subnet mask> <Firewall IP>” which adds a route to the corporate network through the Back-end Firewall.

Route #2 (On the back-end firewall): “route –p add <Client pool subnet> mask <subnet mask> < Gateway IP>” which adds a route to the SCMDM 2008 client network through the SCMDM GW.

Note: If a Redirection Default Gateway is configured, MDM Gateway server will still prioritize any local static routes configured to particular destinations. If there is no such static route for the destination that you are trying to reach, then the packet will be forwarded to the Redirection Default Gateway.

5. It is also necessary to make sure the internal DNS server can access the Client VPN address pool on the MDM Gateway in order to forward resolved queries back to the devices. If the default gateway is, for example, the internal IP address of the back-end firewall, and the DNS server default gateway is not the internal IP address of the back-end firewall, a persistent (static) route may need to be configured as follows:

“route –p add <Client pool subnet> mask <subnet mask> < Firewall IP>” which adds a route to the SCMDM 2008 client network through the back-end firewall.

6. The DM’s web certificate subject name must match the FQDN of the DM server and chain to a valid root CA. Use the Best Practices Analyzer in the resource kit to check this.

These scenarios can vary, but the principle is the same

- Devices must have access to a DNS server to resolve the FQDN of the DM server

- There must be a route from the client VPN address pool on the MDM Gateway to the internal network

- There must be a route from the internal network to the Client VPN address pool on the MDM Gateway

- The internal DNS server must have access to the VPN client address pool subnet in order to respond.

- The DM certificate must be configured correctly and chain to the same root CA as the other servers – SCMDM only supports one root CA per instance.

Logging

Enable OMADM logging on the device using the Connect Now tool from the Client Tools in the MDM resource kit download. Issues contacting the DM server are logged in \deviceupdate.log.

The error codes in the log are Wininet errors, so you can look them up. Some that I have run across are:

Fail (-2147012889)

This error translates to ERROR_WINHTTP_NAME_NOT_RESOLVED and the symptoms are that we cannot connect to the internal network or the internet.

Check all the items above and make sure routing and DNS are configured properly. Also make sure port 8443 and Protocol 50 (IPSec ESP) are allowed both ways on the external firewall and Gateway Server’s Windows Firewall if it is enabled. This protocol allows browsing of internal and external web sites.

Failed sending an HTTP request to the server (0x80072f7d).

This can be caused by a problem with the certificate on the DM web site. Usually the log will show a successful connection to the server followed by the failure:

2008-07-17 15:58:38 omadmclient.exe: Establishing connection to https://dm.mdm.com:8443/MDM/TEE/Handler.ashx

2008-07-17 15:58:39 omadmclient.exe: [PID = 0x9e0b15d2] + Attempting to establish connection

2008-07-17 15:58:39 omadmclient.exe: [PID = 0x9e0b15d2] - Establishing connection

2008-07-17 15:58:39 omadmclient.exe: [PID = 0x9e0b15d2] + Transmitting package data

2008-07-17 15:58:41 omadmclient.exe: Failed sending an HTTP request to the server (0x80072f7d).

2008-07-17 15:58:41 omadmclient.exe: [PID = 0x9e0b15d2] - Transmitting package data FAILED (hr = 0x80072f7d)

Check the DM's web certificate and make sure the subject name matches the DM FQDN, the url= value in the SCMDM2008DeviceManagement SCP, and that the certificate is valid. Certutil is invaluable for verifying that all the certs are correctly deployed. A good resource for how to use certutil is http://blogs.technet.com/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx

You can replace the certificate manually with a new one by using the MDM Certificate tool in the MDM Server resource kit or by following the intructions in the MDM product documentation at http://technet.microsoft.com/en-us/library/cc135742.aspx.

System Center Mobile Device Manager Team Blog : Gateway

Troubleshooting device connection to the Device Management server