none
Managed device doesn't contact the DM Server

    Question

  • When enrolling new devices, we have big problems getting the devcies fully enrolled, domain joined and GPO's applied.

    The enrollment procedure as such works perfectly, We get a message saying that the device is domain enrolled, and that a reboot is required. After the reboot, the device connects the VPN without any problems, and the GW logs a "Client Connected Successfully" message in the event log.

    After that - nothing. Period. Full  Stop. Absolutely nothing.

    We have a Wireshark trace on the inner NIC on the GW, as well as ISA monitoring on the inner FW. Nothing. The device never contacts the Device Management server. It doesn't even try. No DNS name resolution for the DM is sent. Nothing.

    We wait 12 hours. Nothing.

    We reboot the device numerous times; the VPN is reconnected each time. Then...nothing.

    We then install the ConnectNow tool and forces the device to connect to the DM server. Now it happilly connect to the DM Server without any problem whatsoever, downloads the GPO's and continues as a fully managed device.

    Why doesn't the device contact the DM server unless we force it with the ConnectNow  tool?
    (BTW - we're using the Device Emulator, build 19202.1.0.0)

    /Gunnar
    Wednesday, May 07, 2008 6:55 AM

Answers

  •  I've flagged this as a potential bug which the MDM team should look at reproducing (and resolving!). Rather than leave this thread open I'm going to mark this as the answer for now and if I hear in future of a definitive resolution will post it out here.

    best, Pat.
    Mobility Architect, Enterprise Mobile
    Tuesday, July 08, 2008 3:41 PM

All replies

  • This is one of those problems when you wish you had a physical device in your hands and not just the emulator :)

    What kind of connection are you emulating to the server? A wireless adapter will usually disconnect when the screen goes dim to save battery, and network cards could have similar issues. A GPRS/Edge/3G/etc connection should be always on, but might disconnect for a number of reasons as well.

    Do you have anything running/installed/configured on the device other than MDM? When I see similar issues, (not related to SCMDM but scheduling), I sometimes enable push mail as that will reconnect the data connection if you lost it.
    Wednesday, May 07, 2008 7:53 AM
  • We're using the network card adapter in the emulator, no cellular emulator.
    We have nothing at all installed except for the MDM software; we initialize the emulator (Clear Saved State - reboot) and as soon as the device is rebooted we connect to the network and start the domain enrollment.

    The connection is not disconnected; the GW reports a successful connection, and no disconnects (during the 12 hour period that is the longest we've had the patience to wait).

    But this can't be a disconnection problem - the device should contact the DM server as soon as the VPN is established, right?
     
    And when using the ConnectNow tool, the connection to the DM server is immediate. (in fact, the ConnectNow tool connects to the DM Server as soon as it is started, we don't need to click "Connect Now" for this to happen).

    We do not have any defined policy that disable management while roaming, so that's not the problem either...
    • Proposed as answer by David Madison Monday, June 02, 2008 7:53 PM
    Wednesday, May 07, 2008 8:58 AM
  • How is your gateway connected between the LAN and WAN.  Are we NATing anywhere.

    I agree, it would be good to test with a physical device instead of an emulator.
    I have a device if you want me to test.  If you can give me some details i can test for you.

    Wednesday, May 07, 2008 1:15 PM
  • The GW sits between an inner and an outer ISA server, using a public IP address. The outer ISA is routing, not NAT'ing the traffic.

    The emulators are run from an internal network segment that the GW is not aware of as being local, hence it treats them as any Internet based addresses.

    And please note that - as far as I understand - it is only the initial contact(s) that are not happening. Once I have forced the emulator (by means of the ConnectNow tool) to contact the DM server, it will work from then on...
    Even wipe requests are handled in "real time", indicating that the VPN tunnel and DM connection is actaully working as it should.

    To enroll a device against our system:

    User name: David
    enrollment server: mobileenroll.mobilewithstyle.com
    password: kvw723ybhh (valid for 8 hours)

    Please be aware that the device  - once fully enrolled - will be encrypted.

    Wednesday, May 07, 2008 3:14 PM
  • Some additional notes.

    First: another thread covers asimilar situation when the device doesn't contact the DM server, but that communication starts when you ping the device. I have tried this, but cannot reproduce that situation iin my network. Ping to/from the device does not cause the device to contact the DM server.

    Now to the bahavior in our setup; wierd, but fully reproducable...

    When we enroll a new device (emulator), the enrollment always is successful, i.e. we get a message saying that the device is domain enrolled, and that a reboot is required.

    After the reboot, the device always successfully connects the VPN and the GW logs a successful client connect.

    After the VPN connection, the device sends a name resolution request for isatap. No isatap is available in the DNS.

    After that, nothing happens.

    Not to the really wierd part: If I now initiate a CAB installation on the device, the device immediately contacts the DM server!  It doesn't matter what program I try install, and I don't need to finish the installation. When I start the CAB installation I get a message asking whether to install to the device or to the storage card. I can just leave it there (or click cancel); either way, the device has  already initiated contact with the DM server.

    The device now has quite some communication with the DM server for more than a minute, I assume that it downloads policies. After that - nothing. The GPO's are not applied, no matter how long I wait.

    I reboot the device once more, and the behavior from this point is somewhat random. Sometimes the device automatically contacts the DM server, and eventually I get the PIN registration screen indicating that the PIN GPO has been applied. Sometimes I need to initiate another CAB installation in order to get the DM communication and GPO processing to start.

    I will file an error report on this.
    Tuesday, May 13, 2008 9:20 AM
  • Sorry, i didn't get to the enroll in time. Can you provide it again and ill test now.
    Thursday, May 15, 2008 1:34 AM
  • I'm not at the site today, I'll do it on monday.
    Friday, May 16, 2008 6:12 AM
  • What is the default gateway for the devices?  Are they pointing to the FW, which routes traffic internally?

    Sunday, May 18, 2008 10:57 PM
  •  Yes, the devices uses the same default gateway as the MDM GW server; the the inner firewall.

    Monday, May 19, 2008 7:53 AM
  • New pre-Enrollment:

    User name: David
    enrollment server: mobileenroll.mobilewithstyle.com
    password: 2w6tqdwg7g (valid for 8 hours)
    Monday, May 19, 2008 7:57 AM
  • Did you get any further with this issue Gunnar?

    I had a very similar problem in a setup. I don't know all the details from your scenario, but can share the experiences from mine :)

    The device is able to establish a VPN connection as long as the gateway is correctly configured and the enrollment is completed even though the device can't connect to the MDM server properly.

    1. Isatap - this probably occurs because a network adapter has IPv6 configured. In my scenario the gateway is a virtual Win2K3 running on a Windows 2008 physical box. The physical box had IPv6 enabled, the virtual not. When I unchecked IPv6 on the physical box the DNS query was "plain".

    2. I'm using an ISA server between the DMZ where the gateway is running and the LAN where the MDM-server is located. Turns out that ISA server created inbound routes, but not an outbound route. I had to add a route on the ISA server to establish full communication.
    Monday, June 09, 2008 12:29 PM
  • I mentioned the isatap dns query only to prove that the device is in fact online and talks to internal systems (the dns). The problem was that the MDM client did not talk to internal system, not even the dns for name resolution for the DM server. When I triggered the DM contact manually through the ConnectNow utility, the DM server connection is immediate and everything works. So it cant really be a connection problem, it must be an MDM client problem.

    The current state in our environment is now somewhat different.

    When using the emulator, the problem is as stated above, the MDM client never contacts the DM server by itself.

    Whe using a real 6.1 device, it contacts the DM server immediatelly after the reboot and the machine part of the GPO is immediately applied (including a reboot for encrypting the device). The user part of the same GPO on the other hand, seems to take hours before it is applied (!?)

    We have now tried the emulator and two different devices from different manufacturers (HP and HTC). All three has failed in different ways. All three is of build 19202. What gives?

    Wednesday, June 11, 2008 9:07 AM
  • Gunnar Carlson said:


    We have now tried the emulator and two different devices from different manufacturers (HP and HTC). All three has failed in different ways. All three is of build 19202. What gives?



    In light of what is being reported in other threads here I'm starting to think there must be some minor bugs in the MDM client currently available in most devices...
    Friday, June 13, 2008 2:05 PM
  •  I've flagged this as a potential bug which the MDM team should look at reproducing (and resolving!). Rather than leave this thread open I'm going to mark this as the answer for now and if I hear in future of a definitive resolution will post it out here.

    best, Pat.
    Mobility Architect, Enterprise Mobile
    Tuesday, July 08, 2008 3:41 PM
  • I have posted a troubleshooting blog on http://blogs.technet.com/scmdm which covers most common causes of problems connecting to the DM server. It may well be this particular issue is with the emulator, but others looking for answers may find the blog helpful.

    Regards,

    Jarrett
    Tuesday, August 19, 2008 10:54 PM