Use the MDM Connect Now Tool to check the connection to MDM Device Management Server from the Windows Mobile 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 the MDM Connect Now Tool, see the MDM Resource Kit Tools at this Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=108953 .

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

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 CSP
     
     
   • Software Distribution
     
     
   • TDET settings
     
     

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

After installing the Administrator Tools, validate that things are 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 AD groups):

• Get-MDMServer, or Get-WipeConfig, or some other Device Management command, can validate that the MDM Device Management Server Administrator component is up and running.
  
  
• Get-EnrollmentConfigcan validate the same for the MDM Enrollment Server Administrator component.
  
  
• Set-WipeConfig, or some other 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-EnrollmentConfigcan validate write operations to the database through the MDM Enrollment Server Administrator component. Try setting a value like the GatewayUri value.
  
  

For example, if you receive the following error message:

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

Then you might have a certificate mismatch situation in your environment. This message could also indicate that the URL for the server in the Active Directory SCP has been altered.

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.

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:

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

In the previous example, xxis 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.

Caution:
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 protects the MDM infrastructure from this kind of malicious attack.

In scaled-out topologies with load-balanced MDM Device Management Server arrays, you may receive the following error message when trying to connect.

HTTP 401.1 - Unauthorized: Logon Failed.

This issue occurs if you install Windows® XP operating system with Service Pack 2 (SP2) or Windows Server 2003 operating system with Service Pack 1 (SP1). These Windows-based operating systems include a loopback-check security feature that helps prevent reflection 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 Network Load Balancing (NLB) array, a server accesses the Web services on itself through NLB. This issue can also occur if the fully qualified domain name (FQDN) or custom host header does not match the local computer name.

To resolve this issue, follow these steps to disable the loopback check on any computers that are running MDM Device Management Server:

1. On the Startmenu, choose Run, type regedit, and then choose OK.
   
   
2. In Registry Editor, find and select the following registry key:
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
   
   
3. Right-click Lsa, point to New, and then select DWORD Value.
   
   
4. Type DisableLoopbackCheck, and then press ENTER.
   
   
5. Right-click DisableLoopbackCheckand then select Modify.
   
   
6. In the Valuebox, type 1, and then choose OK.
   
   

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.

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. 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 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, 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.
  
  
• The MDM Administrator account was added to the SCMDM2008ServerAdministrators 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 SCMDM2008ServerAdministrators 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 SCPs. To resolve this issue, open MDM Shell on a computer where you have MDM Administrator Tools installed. Check the MDM Active Directory SCPs for MDM Device Management Server 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.
  
  

MDM requires Windows Software Update Services (WSUS) 3.0 SP1 to be installed on the same server as MDM Device Management Server. You can install the 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:

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

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

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

When you uninstall and re-install WSUS, you must restart the SCMDM Software Distribution Service.

If you re-install .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:

• Ensure 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:
  
  

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

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

  	Copy Code
  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 Allowedas one of the Web Services Extensions. This configuration could be set to Prohibitedas a result of re-installing .NET Framework.
  
  
• Restart IIS as appropriate.