System Center Mobile Device Manager Team Blog

FAQ for System Center Mobile Device Manager 2008

Jarrett Renshaw — Wed, 24 Sep 2008 23:33:00 GMT

We will update these FAQ as new issues arise, so check back frequently.

General

Q: What is the level of integration between SCCM and SCMDM?

A: There is currently no direct integration between SCMDM and SCCM, SCMDM is run standalone.

Q: What is Microsoft's support policy on running SCMDM on VMWare?

A: These articles are structured to provide a quick answer on supportability.

<http://go.microsoft.com/fwlink/?LinkId=125767> points to 897615 Support policy for Microsoft software running in non-Microsoft hardware virtualization software

<http://go.microsoft.com/fwlink/?LinkId=125818> points to 957006 Microsoft server software and supported virtualization environments

Note: Running SCMDM on Hyper-V and Virtual Server will be supported in SP1.

Q: Is there a maximum number of users supported by MDM and how many servers would you need to support this?

An MDM Instance can support up to 30,000 devices.

There may be up to 16 servers running MDM Gateway Server in an MDM instance

There may be up to six computers that are running MDM Device Management Server in an MDM instance

You can have up to two computers that are running MDM Enrollment Server in an MDM instance

Certificates

Q: Is there any easy way to renew the device certificate when it expires?

A: Certificate renewal is automated, as long as the device can connect to the issuing CA via mobile VPN. For CS server configuration for MDM see Configure Certification Authority for MDM in the SCMDM documentation.

Q: How does a device know when and how to renew its certificate? Is this done directly from the device or handled by the DM server and then passed to the device?

A: The renewal request is handled by the certificate CSP on device and is uses the path to the CA that is specified in the certificate. This is done over HTTPS using mutual SSL authentication. You can see the certificate renewal information for the device by viewing the XML the device gets provisioned with during enrollment. To do this, open the MDM shell and run Get-EnrollmentServiceLog. Locate the enrollment record for the device and search for RenewalInfo. The section will look something like:

</characteristic>

Q: What happens when a server needs to renew its certificate?

A: SCMDM 2008 servers do not renew their web certificates automatically. However, you can use the MDM Certificate tool located in the Resource Kit to check expiration dates and even send e-mail when a certificate is nearing its expiration date. The tool can be also used to create new certificates for the SCMDM server's web sites.

You can also manually create the certificates - see http://technet.microsoft.com/en-us/library/cc135742.aspx

You will need to create the following certificates:

GCM
DM Web Service
DM Admin Web Service

Enrollment

Enrollment Web Service
Enrollment Admin Web Service

Gateway

Gateway management web site

Note: You cannot simply import a new certificate into the Gateway management web site. To replace the Gateway certificate:

1. Remove the existing certificate.
2. In Control Panel run Setup for the Gateway from Add/Remove Programs > Change.
3. Select the Change option and enter the new certificate information on the appropriate page in the wizard.

Q: If the firmware is upgraded on a device, it can't use the previously assigned certificate. Is this normal?

The existing certificate in AD cannot be reused when a device is re-flashed because the private key associated with the certificate is lost, so the certificate can no longer be used by the device to perform encryption or assert the device identity.

Q: Is there a supported way to change the CA that SCMDM uses after SCMDM was installed?

A: If the devices use a different CA than the servers, you can change the device CA by running the following cmdlet in the MDM Shell:

Set-EnrollmentConfig -CertificationAuthority caserver\cainstance

Note: this may cause enrolled clients to not renew their certificates when they expire, as they will be pointing to a different CA for renewal than the one that issued the certificate.

To change the CA the servers will use, you can use the MDM Certificate tool in the MDM Server Tools section of the Resource Kit.

Use the /ca parameter to specify the CA server.

AD Group Policy

Q: The GPO creates policies for both machine and user. How are these targeted? What are the criteria?

A: Some policies are under machine and should be targeted at the location of the computer account in AD.

Some policies are under user and should be targeted at the location of the user account in AD.

The split is based on whether the policy setting is considered a device or OS setting (i.e. most of them) or an application setting (e.g. Outlook Mobile).

This is a common cause of support calls - if a policy is not applying, make sure it is targeted to the correct machine or user container.

Q: Is it possible to generate a report of the current settings for all my MDM policies?

A: The MDM GPMC allows you to generate a Group policy report per device. This functionality is available out of the box. Instructions on how to do this can be found here.

http://technet.microsoft.com/en-us/library/cc135619.aspx

Q: Can SCMDM block the use of applications that come preinstalled on a device by the OEM?

A: There is a Group Policy setting to block in-ROM applications. Apps included in the device ROM by the OEM or operator could be added to this block list.

Q: What policies can be enabled for roaming?

Device Management | Configure device management when roaming
Mobile VPN settings | Always connected when roaming
ActiveSync | Block sync when roaming

Software Distribution

Q : Is it possible to deploy Windows Mobile updates ?

The current release of SCMDM does not support patching WM devices with firmware updates. However, administrators can allow/disallow enterprise devices to talk to WMU services directly via group policy.

Q : Can I distribute software to user groups? Is it possible to script the creation of groups in WSUS ?

A : The current release of SCMDM does not support user-identity based targeting. We do realize the demand for this feature. It is possible to script the creation of WSUS groups via the public APIs.

Q : Does Software Distribution have a mechanism (like BITS for desktop) to resume transfer when the network connection has been temporally broken?

A: Yes, this mechanism is in place

Q: Is there in SCMDM a mechanism to control the bandwidth used for software distribution? Is it possible to specify a bandwidth percentage allowed for SD?

A: In the current release of SCMDM, we don't have the feature that gives users control over the bandwidth used for software distribution. People have expressed the need for this feature and the team is well aware of it.

Q: Does SCMDM allow whitelist functionality for applications on the device?

A: You can use the functionality provided by two policies to control this behavior

- Allow specified unsigned applications to run as privileged
- Allow specified unsigned applications to run as normal

More info here: http://technet.microsoft.com/en-us/library/cc135661(TechNet.10).aspx

Q: What is the largest package size supported by MDM?

512 MB is the hard limit imposed by Software Distribution package creation wizard on the server.

Cab size limitation from client perspective is dependent mostly on following external factors.

·         Memory available on device.
·         Connection speed.
·         CPU speed of the device.

During the test process we were successful in downloading cabs up to 25 Mb in size on the device.

Administration

Q : Is it possible to delegate the management of WM devices to different groups of admins based on their location ? For example, the UK admin would manage the UK devices ?

The current release of SCMDM does not support administering deployments based on geographical locations.

Q: What is the level of delegation with regards to administration? (e.g. Could someone at the help desk be granted permissions to do a remote wipe if a device is reported missing but not be permitted to change the software assigned to the device)

Currently for most admin activities role customization is not implemented. Therefore admins in certain groups have the permissions to perform a set of activities (like wipe, block devices) while others have different set of permissions (like reading configuration). These mappings are not customizable in current versions. There are some exceptions to this:

-Group Policy
-Software Distribution

Group Policy permissions (setting policy on a device) are controlled via Group Policy and OU delegation. Therefore you could have a user that only manages policy for devices and does not have any other permissions. Software distribution is controlled via the WSUS Administrators group and through the WSUS permissions model.

For a listing of the role mappings to actions that roles can perform, see here: http://technet.microsoft.com/en-us/library/cc135605(TechNet.10).aspx

Inventory

Q: Is it possible to perform software inventory on a device and have the device send files to the DM server, similar to software inventory file collection in SMS/SCCM?

A: SCMDM does not support file inventory file collection.

Security

Q: Where can I find out what kinds of encryption MDM supports for things like WiFi, storage card, etc?

A: The documents Security Model For Windows Mobile 5.0 and Windows Mobile 6 contain this. For information on the Mobile VPN protocols for Windows 6.1 see http://msdn.microsoft.com/en-us/library/cc440249.aspx

MDM Client/Mobile VPN

Q: What SCMDM factors affect device battery life?

A: There are several factors that affect battery life:

Connection type - Typical APN settings have short timeouts. These force VPN reconnections at short time intervals and result in poor battery performance. This is the most common (but not the only) reason for poor battery performance. Check the APN (Start - Settings -GPRS ) . You may be able to change to another provided by the ISP that has longer timeouts.
NAT KeepAlive frquency - If NAT is detected by the Mobile VPN, keepalives will be sent periodically (45 seconds). The period between keepalives is configurable. Because sending too many keepalive signals may significantly impact the battery life of the mobile device, it is recommended to contact the Mobile Operator and use a cellular data connection that does not require NAT or ensure that NAT inactivity timeouts have been customized for UDP.

To get information about the NAT and keepalives, download and run this tool on your device:

http://technet.microsoft.com/en-us/scmdm/cc304591.aspx

MDM VPN Diagnostics Tool

1. Install this tool on the device and run it.

2. Go to Menu->Diagnosis, scroll down to the NAT Status Key portion of the diagnosis. It will tell you if NAT is detected, KeepAlive is needed, and the KeepAlive interval.

The NAT timeout can be adjusted via a registry key using the VPNDiag tool (see Menu->Configuration->NAT Keep Alive Interval). However, most devices use 45 seconds. If battery life is still a problem, check with the ISP and find out their NAT timeout interval.

Other possible causes: Application traffic, the device itself, characteristics of the Mobile Operator's network, shorter MDM sync times may have been configured (the default interval is 8 hours).

Q: Is data encrypted in memory (e.g. if end user opens a Word doc that is encrypted on the device) on the mobile device?

A: There are Exchange and SCMDM policies that can enforce encryption of data on the device in internal storage and also a storage card. This is actually a Windows Mobile 6 feature - from http://www.microsoft.com/technet/solutionaccelerators/mobile/maintain/SecEntMessaging/4ea10143-5661-45c7-a26b-d01070e3632b.mspx

Support for encryption of data stored in removable storage cards. Storage card encryption supports Advanced Encryption Standard (AES) in 128 bit cipher strength.

The following list shows the storage card encryption support:

	Encrypt data written from the mobile device to removable media. The data will be encrypted for use on the encrypting device only. If unencrypted data is transferred to the storage card by another device (Phone, PC), the content is not encrypted by the device. ActiveSync file explorer provides desktop access to encrypted data files.
	Enable over-the-air (OTA) provisioning of encryption by using Exchange or other OTA device management solution.

OEMs and Mobile Operators can provision the encryption policy during a cold boot of the device.

Encryption is transparent to applications and users, not including performance impacts.

Storage card encryption can be managed by Exchange 2007 policies [JR] or SCMDM policies. The user can also manage the mobile encryption configuration through the control panel [JR] if no policy is being applied.

For more detail, check the documentation for the Windows Mobile SDK.

Q: Is it possible to have a user use his GPRS connection and/or a home WiFi connection, but have them switched over to the corporate WiFi network when they access the company building?

A: The connection will not switch dynamically.The user can switch it manually. If the user is connected via GPRS, VPN will stay on GPRS until the GPRS connection is no longer available. It will not automatically switch to WiFi when WiFi becomes available.

What's coming in SCMDM SP1

TechNet Archive — Wed, 03 Sep 2008 08:43:00 GMT

Like all engineering groups at Microsoft, after shipping a version of a product, we move on to building the next version. And like all other product groups, the SCMDM team is committed to delivering product updates that improve the quality and experience for our customers and partners. We continually focus on enhancing security, increasing reliability, and simplifying administration. MDM is no exception. Since shipping SCMDM 2008 we have been working on new features and fixes or Mobile Device Manager. We thought you’d like to hear the latest, so here is an update on what you will see coming with SP1.

System Center Mobile Device Manager 2008 Service Pack 1 will deliver improved performance and scalability, increased reliability, and an expanded set of supported topologies.

The key new features of SP1 are support for multiple instance, PIN reset, and support for running with Windows Server 2008 Active Directory Domain Services.

The SP1 update can be applied to all previously installed instances of System Center Mobile Device Manager 2008 as well as new installations. The service pack consists of the following features:

– Multiple-instance: allows large organizations with distributed IT control points to independently manage devices within the area of their control. This applies to instances within a single forest. Today when SCMDM is deployed at a company, that deployment will manage all devices in an organization; there is no ability to have multiple SCMDM installation. With SP1, if your company has offices or divisions that have their own IT departments, these offices will be able to install an instance of MDM that does allows devices to managed separately from other offices in the company.

– PIN reset. This feature is the same as what is currently available with Exchange 2007. It will allow device PIN reset either by the SCMDM administrator for a specific device or self-service via the MDM Self-Service portal. This feature requires an update to the client as well. Consequently, client support for this feature will be made available as a downloadable CAB file for WM 6.1 phones.

– Windows Server 2008 support. Support for Windows Server 2008 including Domain functional mode, Forest functional mode. If you are running AD with functional levels raised to WinServer 2008, MDM SP1 will support that architecture. In addition, Hyper-V (virtualization) will be supported for using hosted Windows Server 2003 for testing purposes.

– Performance and scalability enhancement. The release criteria for SP1 is to increase system coverage to 40,000 users in a single instance versus the 30,000 user single instance limitation in MDM 2008. If you require large scale, but want to keep your deployment within a single instance without acquiring additional hardware, this will be very helpful. (The numbers were adjusted from the original post to more accurately reflect what the test team's release criteria is. We will strive to get the supported number has high as possible, but our current goal for release is 40,000)

We’re currently in Beta and are soliciting feedback from customers with needs that match the SP1 feature set. We anticipate that SP1 will be available for download in mid-to-late December and will include the installable CAB file for supporting PIN reset on 6.1 devices and later.

We hope you are as excited as we are about the benefits MDM SP1 will bring to your mobile enterprise solutions. We’re seeing a great response to Mobile Device Manager in our trial programs—if you haven’t tried it yet you can get an evaluation copy here: http://technet.microsoft.com/en-us/evalcenter/cc339027.aspx.

UPDATE: The point regarding support for Windows 2008 in MDM SP1 has raised some questions. MDM SP1 will not support running on a Windows 2008 server. MDM SP1 will only support running in a Windows 2008 Domain, and support running on Windows 2003 in a Windows 2008 Hyper-v configuration. Support for running MDM on Windows 2008 will be a post SP1 release.

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.

Remote Wipe Now and MDM Alerter troubleshooting - Part 2

TechNet Archive — Mon, 28 Jul 2008 04:21:00 GMT

In my last post I discussed the basics of Remote Wipe, and some steps to take to ensure if it is working or not. In this second part, we will get more detailed on how to troublehoot Device Wipe.

1. Troubleshooting with the Device Log

Once you have confirmed that the conditions in 1-3(described in the previous post) are not the case, you can turn on device logging in order to narrow down the problem. The easiest way to turn on device logging is by using the SCMDM 2008 Resource Kit client tools, located here: http://technet.microsoft.com/en-us/scmdm/cc304591.aspx

1. Enable Alerter client logging

a. Download the client tools from the above location

b. Unzip to a location on your computer.

c. Once you have unzipped this file, connect your device to the computer via a cable

d. Transfer the MDMConnectNow.CAB (located in the MDMResourceKit\MDMClientTools\MDMConnectNow folder) to the device.

e. Disconnect your device from the computer.

f. On the device, navigate to the location where you transferred the MDMConnectNow.CAB. Click on the MDMConnectNow.CAB and install it.

g. Once installed, go to the Start Menu and then All Programs. Run the MDMConnectNow tool.

h. Choose Menu >> Logging

i. Under logging, check the “Enable Alerter Log” check box

j. Once you check that box, below in the dropdown box, you must also select Alerter (without this it will not work).

k. Now Alerter logging is enabled and it will write a log to ./deviceupdate.log on the device.

2. Once you have Alerter logging enabled, issue a wipe from the Mobile Device Manager Console, the MDM shell, or the Self Service Portal. Mark the time that the wipe was issued.

3. Look for the presence of 5506 or 5507 event IDs on the Gateway Server (as in the section “Check the Event Log on the MDM Gateway” above. Mark the time for the 5507(s) or 5506(s).

4. Once you see a 5506 or 5507 event on the Gateway for the device, transfer the deviceupdate.log to a computer from the device. You must do this before the wipe happens or you will lose all the tracing information.

5. Open the client logging file on the computer in a text reading program like Notepad.

6. Search for the following terms in the document:

a. “Rejecting packet” – See below for Rejected packets

b. “Received push with timestamp” and “Accepting packet” -- See below for Successful packets section

c. No “Received push with timestamp” in the log

a. Rejected Packets

If you see the text “Rejecting packet” in the Alerter log, it means that the Alerter was rejecting the packet because the source address did not match the expected address.

Seeing this in the logs is actually a good sign, in that the Alerts are getting to the device, but they are being rejected.

In the log it will give the expected source IP (The IP address that the Mobile VPN client is communicating with) and the actual IP (The IP address that the packet came from). A mismatch here 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 for the Gateway external IP address

· Check Again for a NAT in front of the GW

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

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. Perform the following steps to diagnose the problem.

Determine the Address Pool

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

2. Run Get-MDMGatewayServer

3. For the Gateway Server(s) where devices are connecting, obtain the address pool which should be in the form of something like: {10.10.10.0/255.255.255.0}. It may contain multiple values.

Determine the routes on the Gateway Server

4. Log into the Gateway Server machine(s)

5. Open a Command Prompt on the Gateways and run the following command

>route print

6. The above command will print out a list of routes like 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……

7. Look in the Active routes for routes with a Network Destination that matches the address pool(s) obtained in Step 3 above.

8. There should be only 1 route to each of the device address pool(s) configured on your Gateway(s). That route should go through the external interface on the Gateway.

For example if a Gateway has the following interfaces:

o aaa.54.44.33 – external interface

o bbb.192.0.1 – internal interface

The below is a correct route 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 below is an incorrect route 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 below is incorrect as well. Although there is a route correctly through the external interface, there is also one through the internal 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

9. You can reboot the Gateway server and recheck the route. If the incorrect route still remains, you can correct the route using the “route” command. Run “route” at the command prompt for more information.

10. Also check for incorrect routes in the Persistent Routes section.

11. Once the routing is correct, try the troubleshooting steps again.

b. Successful Push Packet

If you see successfully received push packets to the Alerter it means that Alerts are getting to the device and they are being processed.

If you are still having issues with the wipe request and the time it is taking, you can check the Device Management server to ensure that it is functioning as expected.

c. No Successful Push packet in the log

If you do not see any successful push packets in the log, it means that the device is not receiving any alert requests. Check the routing on the Gateway by following the “Check the routing on the Gateway” steps above.

Check the networking between the Gateway server and the device and correct any networking issues.

Ideally, Remote Wipe Now should work smoothly. In the event there are problems, these steps should help you determine the cause.

Marc McClure

Program Manager

Mobile Information Worker

Remote Wipe Now and MDM Alerter troubleshooting

TechNet Archive — Tue, 22 Jul 2008 03:07:00 GMT

Remote Wipe Now and MDM Alerter troubleshooting

A key security feature of SCMDM is the ability to wipe a device remotely. Often time is of the essence, so it is important to know if a wipe was successful or not. Here we will discuss how remote wipe works and how to troubleshoot it,

Introduction

Remote wiping of a device is a security feature that allows administrators to remotely send a command to an MDM managed device that causes it to erase all data and return to factory defaults. This is useful if the device has been lost or stolen. In a remote wipe, the flash and storage card data are overwritten, leaving only the base OS on the device and no user data. Administrators can also deploy the Self Service Portal which allows users to wipe their own devices.

For wipe operations, time is critical - that's why we tend to call the feature "Wipe Now" internally. Without the Now you just have a Wipe Soon operation. Wiping in 8 hours doesn't work great when your device and all its data are lost or stolen. Remote wipe commands in MDM depend heavily on networking between the server and the device and this is where problems can often occur.

In pilot environments administrators often run MDM Remote Wipe tests because it is easy to see it working. However, this is one area in deployment where it is easy to make mistakes and cause the Wipe to take longer than expected. Below are troubleshooting steps to help to determine the cause of a Wipe Now command taking longer than the expected ~~2-6 minutes~~. Failed to catch this before posting...expected time is 3-15 minutes.

How Remote Wipe Works

Before going into troubleshooting, here's a brief overview of how Wipe Now works.

An administrator or user submits a wipe request through the console, MDM Shell, or Self Service Portal.
The wipe request is stored in the DM Engine database for the device to pick up at its next scheduled OMA session

If we were to stop at this point it would be a "Wipe Soon" and the device would connect at its regular interval (4 hours, for example) and pick up the wipe. Wipes submitted are always submitted as a "Wipe Now" now command, and thus we have to go a step further

In parallel to adding the wipe request for retrieval, the wipe driver also calls the Alerter component to inform the device of a pending wipe request.
The Alerter sends an alert to the device over the Mobile VPN. The alert can only be sent through the VPN tunnel and thus Wipe Now requires VPN connectivity
The Alerter client on the device receives this Alert and immediately starts a management session with the Device Management server.
The device picks up its wipe request from the Device Management server, sends back an Acknowledgement that started the wipe, and starts the wipe process

Troubleshooting Wipes that are Taking Longer than Expected

From the moment a wipe request is submitted, a wipe should take approximately ~~2 - 6 minutes~~ 3-15 minutes] depending on the network and other factors. If it is taking longer than that, below are some troubleshooting steps that you can perform to determine the cause of the latent wipe request.

1. Verify that Management Sessions are operating as expected

Ensure that typical device management sessions, not related to wipe are working as expected. You can download the MDM Connect Now tool located in the SCMDM 2008 Resource Kit Client Tools package here: http://technet.microsoft.com/en-us/scmdm/cc304591.aspx Using this tool and associated documentation, you can verify that management sessions for devices are successful.

If management sessions are not working, you will need to fix this problem before devices can successfully receive the remote wipe command.

2. Verify the device is connected to the VPN

As discussed in the above "How Remote Wipe Works" section, remote wipe relies on the VPN being connected in order to send alerts to the device. The device may not be connected to the Mobile VPN for many reasons, but some of the most common are:

The device is switched off
The Mobile VPN is disabled (if users have the ability to disable it)
The user is roaming and VPN is off
The data connection is improperly configured
The user is temporarily out of service coverage area

In all the above cases, the device will not receive the Alert message as it relies on the VPN tunnel being up. When the device reconnects to the VPN, it will receive an Alert message or will start a management session immediately if it has missed its regularly scheduled session.

3. Verify the Gateway Server is not behind a Network Address Translator (NAT)

Once you have verified that management sessions are operating and the VPN was up on the device you were attempting to wipe, you need to check that the Gateway is not behind a Network Address Translator. MDM does not support locating a Gateway Server behind a NAT. There are several reasons for this requirement; one of the reasons has to do with the Alerter.

The reason the Alerter does not work with Gateway Servers behind a NAT is for security purposes. We'll talk about this some more, but for added security, the Alerter checks to ensure that the Alert it received is really from the MDM Gateway Server and not from a potential attacker.

The Gateway Server must have a public IP address and must not sit behind a NAT or the Alerter cannot verify the alert that the alert is valid. The Alerter discards invalid alerts. Ensure that your Gateway is not behind a NAT.

4. Check the Event Log on the MDM Gateway

On the MDM Gateway server, open up the "VPN Policy Engine" Event Log. 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 never heard from the device.

Further debugging information is needed for the following scenarios:

5507 events for every wipe issued

5507 event for a wipe issued in a controlled environment, where you know the device connected, online and available

Inconsistent 5507 and 5506 events

A mixture of 5507 and 5506 events are expected for normal operations as some devices may be offline, out of service range, or not connected for another reason. This is generally normal.

In our next post we will look at how to use the some client tools available in the resource kit, and how to use the Device Log to further narrow down any issues.

Marc McClure

Program Manager

Mobile Information Worker

Getting Started with SCMDM

TechNet Archive — Mon, 07 Jul 2008 07:39:00 GMT

At the risk of stating the obvious, System Center Mobile Device Manager (SCMDM) is a Version 1 product. There are many opportunities that come with shipping a V1 product. The most important opportunity is for the team firs to identify the need for the product, it was clear to us that mobile devices were becoming an essential tool for information workers. In addition, the upcoming workforce will expect and demand that the majority of their information be accessible from their mobile device. In short, your mobile device is just as important as your laptop. That situation also presents opportunities for a company's IT departments. How do they manage those devices in the same manner they manage laptops and desktops? This, then, was the challenge we set out to solve with SCMDM. We worked closely with key enterprise customers, to identify what they needed--the ability to enforce policies, wipe devices, access data inside the firewall securely, and make Line of Business applications available on the mobile device. As we built the product and went through our milestones, we worked with our Technology Adoption Program customers to get specific technical feedback on the product in "the real world". These customers told us we had met their primary requirements and the product was ready to go. So, we launched SCMDM this past April 2008.

Three months have since passed, with many of our TAP customers continuing with their testing and pilot programs. But the momentum has yet to really get started. Because SCMDM supports Windows Mobile v. 6.1 and above, the real benefit of the product will start to take off over the next weeks and months as the 6.1 devices start to become commercially available. You will also be hearing more about SCMDM from your Microsoft account teams.

But don't wait for them; you can get started testing and piloting SCMDM. There is a 180-day Evaluation version available at http://technet.microsoft.com/en-us/evalcenter/cc339027.aspx. The perfect place to get the technical content you need to get started is The SCMDM Tech Center.

Many customers that are testing and piloting SCMDM have asked how to best integrate it with existing server technologies they may have. We've heard them and responded. We recently published a series of technical guides that explain how SCMDM can integrate with your existing solutions:

· Configuring External and Internal Firewalls for MDM

· Integrating MDM with Microsoft Exchange Server

· Deploying Mobile Device Manager in a Global Enterprise Environment

· Integrating Mobile Device Manager with Existing Web Sites or SharePoint Server

· Integrating Mobile Device Manager with Office Communications Server

We hope this gives you a good start in understanding and planning for SCMDM. While pointing you to all this great content is important in building your foundation, over the next weeks, months, and beyond you will start seeing posts from the product team that will discuss specific SCMDM technologies in depth. Your comments and feedback will be essential in ensuring we continue to deliver the best Mobile Device Management technology.

Welcome to the System Center Mobile Device Manager Product Team Blog

TechNet Archive — Tue, 17 Jun 2008 02:50:00 GMT

Welcome to our System Center Mobile Device Manager 2008 blog. I encourage you to take this opportunity to connect to the Mobile Device Manager Product team, learn more about our products, and share your thoughts and opinions about enterprise mobility. Our team is looking forward to working with you to build a great community!

SCMDM 2008 launched in April 2008 after years of interactions with IT professionals. Mobile Device Manager is here today because of their vision of how enterprise IT could meet the needs of a mobile workforce. Mobile e-mail capability has become a given. Businesses want more—they want to give their employees access to the same line of business (LOB) applications and data available inside corporate networks. They want to manage mobile devices with the same infrastructure they use to manage PCs. Mobile Device Manager was designed to meet these needs of enterprises by integrating Windows Mobile with the Windows Server System.

Through this blog and other community efforts, we hope to provide you the information and insight you need to enable your Windows Mobile Devices to be more productive. I welcome your feedback and suggestions on how to improve our product.

Dieter Zirkler

Principal Group Program Manager