The Mobile Device Manager Support Team Blog : Troubleshoot

Software Distribution 8041 warning

Rob Davies — Mon, 02 Nov 2009 10:39:00 GMT

Here’s a problem which we’ve seen a couple of times which can be caused by bad packages in software distribution. This problem can arise when Software Distribution is being used, and you notice that devices don’t seem to be getting packages, nor getting updated in the Software Distribution console. As well as this, the following message is logged in the MDM event log on the Device Management Server:

Event Type:        Warning
Event Source:    Device Manager
Event ID:              8041
Description:
Software Distribution service received insufficient query results from device {DeviceSID}.
Missing LocUri ./Vendor/MSFT/SwMgmt/Download?list=StructData.

You will also notice that in the Device History tab in the ‘./Vendor/MSFT/SwMgmt/Download?list=StructData’ URI will have returned a status of ‘Failed’.

Firstly, let’s look at what this means. ‘./Vendor/MSFT/SwMgmt/Download?list=StructData’ is part of the Download Configuration Service Provider, which you can find documented at http://msdn.microsoft.com/en-us/library/cc563003.aspx. This is described as “Parent characteristic for the components that are ready to download or are in the process of downloading”. So this stores information about packages which are in the process of being distributed, before they have finished installing.

The Device management server is requesting this information, so it can know which packages are in the process of being downloaded. In this situation, the data returned is showing an error – so we know the problem occurs on the mobile device itself when we ask for this info.

This situation can typically occur in situations such as:
- A package is distributed which requires user interaction, for example to click a button or agree to some terms. If the user cancels this or ignores it, the install may fail.
- A package is distributed which restarts the mobile device forcefully, before the install process has completely finished.

When a scenario like these happens, the package distribution process doesn’t finish installing the software and cleaning up the download list. Therefore, the device gets left in a state where the software installer has finished, but the data at ‘./Vendor/MSFT/SwMgmt/Download?list=StructData’ hasn’t been cleared up. We then get left with some orphaned information left in the download list, which causes the error which you see on the Device Management Server.

How to fix it

To stop the error & to get software distributing again, you need to do two things. Firstly, you need to clear up that orphaned data, then check your software packages to see which is the culprit.
To clear up the download list, we can use some provisioning XML:
- Download the _Setup.xml file which is attached to this entry
- Use ‘makecab.exe’ to convert this into a .cab file. The easiest way to do this is to load up the Visual Studio 2008 Command Prompt and run:
o Makecab _setup.xml SWDist.cab
- Now you need to install this cab on the devices. The easiest way to do this is to import the cab into the SCMDM Software Distribution console.
- Once it’s imported, click on the ‘File Information’ button & copy out the ‘File URI’.
- Email this link out to the mobile devices, click it & run the file!

After this has been applied to the devices, you should see software distribution working again & ‘./Vendor/MSFT/SwMgmt/Download?list=StructData’ will start reporting success in the MDM console. Remember to go and test out your packages afterwards!

Please note: As this change removes information about packages which are downloading, this process shouldn’t be done at the same time a new software deployment is being pushed out.
Rob Davies | Senior Support Engineer

Group Policy setting “Code Word” for System Center Mobile Device Manager 2008 is not correctly applied to Windows Mobile 6.1 mobile devices when the policy is Disabled

jchornbe — Thu, 13 Aug 2009 19:00:55 GMT

When you disable the Group Policy setting Code Word by using Microsoft System Center Mobile Device Manager (MDM) 2008 Group Policy management functionality, some Windows Mobile 6.1 mobile devices may continue to use the previously set code word.

This group policy setting affects this Windows Mobile registry key when applied to the device:

HKEY_LOCAL_MACHINE\Comm\Security\LASSD\CodeWord

When this policy is set to Enable the Code Word value is set in this registry key, however when this policy is set to Disable the registry key is deleted. When the registry key is not found, the Windows Mobile device continues to use whatever code word was set previously.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. This problem has not been corrected at the time of publication of this article.

The only workaround at this time is to not disable the policy. Using the Group Policy Management Console, rather than set the policy to Disable, always set it to Enable and specify your desired code word.

Note: Special thanks to our very own Dave Hattaway for contributing the preceding information.

J.C. Hornbeck | Manageability Knowledge Engineer

The Group Policy setting “Code word frequency” for System Center Mobile Device Manager 2008 is not correctly applied to Windows Mobile 6.1 mobile devices when the policy is “Disabled”

jchornbe — Wed, 12 Aug 2009 20:03:47 GMT

When you disable the Group Policy setting Code word frequency by using Microsoft System Center Mobile Device Manger (MDM) 2008 Group Policy management functionality, some Windows Mobile 6.1 mobile devices may continue to ask the user to enter a code word after a number of incorrect password attempts.

This group policy setting affects this Windows Mobile registry key when applied to the device:

HKEY_LOCAL_MACHINE\Comm\Security\LASSD\CodeWordFrequency

When this policy is set to Enable the frequency value is set in this registry key, however when this policy is set to Disable the registry key is deleted. When the registry key is not found, the Windows Mobile device reverts to the default behavior, which is to ask the user to enter a codeword after 8 incorrect password attempts.

This issue is fixed in System Center Mobile Device Manager 2008 Service Pack 1 but the following workaround is also available:

Important: The following workaround applies only to the English version of Microsoft System Center Mobile Device Manger 2008. There are no workarounds for other language versions of the product at this time.

Warning: Serious problems might occur if you modify system files incorrectly. These problems might require that you reinstall server software or components of server software. Microsoft cannot guarantee that these problems can be solved. Modify the system files at your own risk.

Important: The following workaround requires you to modify an important system file. Make sure that you back up the referenced file before you modify it. Make sure that you know how to restore the system file if a problem occurs. Do not proceed with the following procedure if you do not know how to back up and restore a file. Revert to the original file if you encounter any problems with the workaround.

The following steps modify the ADM template file that includes the Code word frequency Group Policy setting. When you have successfully modified the file, you can use the Code word frequency Group Policy setting to correctly update managed devices.

1. On the computer on which you have installed the MDM Administrator Tools, navigate to the %windir%\INF folder.

2. Type the following at a command prompt to make a backup copy of the mobile.adm file:

copy mobile.adm mobile.adm.bak

3. In a text editor, such as Notepad, edit the mobile.adm file to change the MIN setting for Policy_CodeWordFrequency

REPLACE:

        POLICY !!Policy_CodeWordFrequency
        EXPLAIN !!Explain_CodeWordFrequency
        PART !!Part_CodeWordFrequency NUMERIC
            KEYNAME "SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\Security\Policy\LASSD"
            VALUENAME "CodewordFrequency"
            MIN 1
            MAX 4294967295
            DEFAULT 8
        END PART
    END POLICY ;;!!Policy_CodeWordFrequency

WITH:

        POLICY !!Policy_CodeWordFrequency
        EXPLAIN !!Explain_CodeWordFrequency
        PART !!Part_CodeWordFrequency NUMERIC
            KEYNAME "SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\Security\Policy\LASSD"
            VALUENAME "CodewordFrequency"
            MIN 0
            MAX 4294967295
            DEFAULT 8
        END PART
    END POLICY ;;!!Policy_CodeWordFrequency

4. Save the file and exit the text editor.

5. Using the Group Policy Management Console, instead of setting this policy to Disable, set it to Enable and set the value to 0.

To apply the new setting to managed devices, you must update the Code word frequency Group Policy setting in MDM. To refresh the setting in MDM, in MDM Console, run the following cmdlet:

Update-MobilePolicyCalculation <device>

Where <device> is the managed device on which you want to update the Group Policy setting. New settings are pushed down to managed devices during the next synchronization with MDM.

Note: Special thanks to our very own Dave Hattaway for contributing the preceding information.

J.C. Hornbeck | Manageability Knowledge Engineer

SCMDM SP1 Support for Virtualization

Rob Davies — Thu, 28 May 2009 09:57:00 GMT

As you may know, with the Service Pack 1 release of SCMDM we introduced support for virtualization of our server roles. This allows you to run the Windows Server 2003 x64 guest OS in a Hyper-V environment. We wanted to clarify that this applies to the virtualization of the Device Management and Enrollment Server SCMDM roles, but does not apply to the Gateway Server role.

The architecture of the Gateway server requires two network cards, one for the internet and one for the internal network, which the SCMDM VPN monitors traffic on. We recommend that this should not be implemented on a virtual machine due to the complications that this introduces. Therefore the supported setup is to use a physical server with 2 network interfaces for your SCMDM Gateway Servers. For more information about the Gateway Server role and its requirements, please see http://technet.microsoft.com/en-us/library/dd252779.aspx.

Rob Davies | Senior Support Engineer

SCMDM Solution: Signed applications install but fail to run with a signature failure related error

jchornbe — Thu, 21 May 2009 19:12:59 GMT

Here’s an interesting issue that a one of our top Support Escalation engineers by the name of James Geater ran into a while back. It can be a tricky one to troubleshoot as the cause of the issue isn’t obvious so I thought it would be worth a quick post here:

========

When using System Center Mobile Device Manager to distribute software, the installation may complete normally but the application fails to run with a signature failure of some kind. I say “some kind” because the exact error may vary depending on the application.

This can happen if the files used by the application are altered during the installation. For example, if the date/time stamp is changed at the time of install, possible from the file getting renamed, you can see this exact issue. This is because altering the file invalidates the digital signature.

To verify this look at the files in the source and compare them to the ones on the device. Look closely at the size and the Date/Time stamp. If there’s a discrepancy, copying the original files from the source onto the device may server as a workaround to the issue.

========

Thanks James!

J.C. Hornbeck | Manageability Knowledge Engineer

System Center Mobile Device Manager support for Windows Server 2008 Certificate Authority

jchornbe — Mon, 18 May 2009 19:03:47 GMT

We are happy to announce that we now support System Center Mobile Device Manager 2008 SP1 with a Windows Server 2008 Enterprise Edition Certificate Authority. We’ll be documenting this on TechNet in the near future but we wanted to let you all know that this is now fully tested and supported.

For this to work on the device side, we require Windows Mobile build 6.1.4 or later. For earlier Windows Mobile 6.1 builds, you can install update KB951840 from http://support.microsoft.com/kb/951840/.

So now you can deploy SCMDM with a Windows Server 2008 issuing CA in a Server 2008 functional level domain. For the complete list of system requirements for SCMDM please see http://technet.microsoft.com/en-gb/library/dd261866.aspx.

Rob Davies | Senior Support Engineer

Solution: The Group Policy setting “Block unsigned theme installation” for System Center Mobile Device Manager 2008 is not correctly applied to Windows Mobile 6.1 mobile devices

jchornbe — Wed, 11 Mar 2009 18:06:01 GMT

Just a quick FYI on an issue we came across recently. This should be a Knowledge Base article soon but I figured I’d post it here first to give all you faithful readers first notice. If you’re trying to use the Group Policy setting “Block unsigned theme installation” for System Center Mobile Device Manager 2008 and it’s not working correctly then this one’s for you:

Issue: When you Enable the Group Policy setting Block unsigned theme installation by using Microsoft System Center Mobile Device Manger (MDM) 2008 Group Policy management functionality, some Windows Mobile 6.1 mobile devices may not allow the installation of default built-in themes.

When you Disable the Group Policy setting Block unsigned theme installation by using Microsoft System Center Mobile Device Manger (MDM) 2008 Group Policy management functionality, some Windows Mobile 6.1 mobile devices may continue to block the installation of unsigned themes.

Cause: This group policy setting affects Windows Mobile Security Policy 4103 SECPOLICY_UNSIGNEDTHEMES when applied to the device. The default value for this policy is SECROLE_USER_UNAUTH, however when the group policy setting is set to Disable the value SECROLE_USER_AUTH is applied.

When this policy is set to Enable the value SECROLE_NONE is applied. Theme files as well as other cab files do not receive special permissions as executable files do, even if they are placed in-rom, so this policy continues to affect these default theme files and blocks their installation.

Note: SECROLE_USER_UNAUTH corresponds to the decimal value 64, and SECROLE_USER_AUTH corresponds to 16.

Workaround: To work around the behavior when set to Enable, you must sign the default theme files you want to enable users to install. To work around the behavior when set to Disable follow the procedures below:

The following steps modify the ADM template file that includes the Block unsigned theme installation Group Policy setting. When you have successfully modified the file, you can use the Block unsigned theme installation Group Policy setting to correctly update managed devices.

1. On the computer on which you have installed the MDM Administrator Tools, navigate to the %windir%\INF folder.
2. Type the following at a command prompt to make a backup copy of the mobile.adm file:

copy mobile.adm mobile.adm.bak

3. In a text editor, such as Notepad, edit the mobile.adm file to change the VALUEOFF setting for Policy_BlockUnsignedThemes

Replace this:

        POLICY !!Policy_BlockUnsignedThemes
        EXPLAIN !!Explain_BlockUnsignedThemes
        VALUENAME "4103"
        VALUEON NUMERIC 0
        VALUEOFF NUMERIC 16
END POLICY

with this:

        POLICY !!Policy_BlockUnsignedThemes
        EXPLAIN !!Explain_BlockUnsignedThemes
        VALUENAME "4103"
        VALUEON NUMERIC 0
        VALUEOFF NUMERIC 64
END POLICY

4. Save the file and exit the text editor.

To apply the new setting to managed devices, you must update the Block unsigned theme installation Group Policy setting in MDM. To refresh the setting in MDM, in the MDM Console run the following cmdlet:

Update-MobilePolicyCalculation <device>

Where <device> is the managed device on which you want to update the Group Policy setting. New settings are pushed down to managed devices during the next synchronization with MDM.

This information applies to:

• Microsoft System Center Mobile Device Manager 2008
• Microsoft Windows Mobile 6.1 mobile devices

Hope this helps,

J.C. Hornbeck | Manageability Knowledge Engineer

Collecting large amount of device inventory information during OMA session causes MDM server to timeout

jchornbe — Thu, 08 Jan 2009 16:38:50 GMT

Here's an issue we run into every now and then so I thought it might be worth a mention here. If you're noticing GP and software distribution delivery failures then this may be your issue:

========

Issue: Collecting large amount of device inventory information during an Open Mobile Alliance (OMA) session may cause the System Center Mobile Device Manager server to timeout.

Cause: During the first OMA session on some devices, if the device is instructed by the server to collect a large amount of inventory information it might result in the session taking up to 20 minutes to complete or it may timeout completely depending on the timeout settings on the server. This delay results from the time taken by the device to retrieve and process inventory information that the server requested.

Resolution: To resolve this problem, restore the default inventory collection set using the Restore-MDMInventoryDefaults cmdlet or remove items from the inventory collection using Set-MDMInventoryItem cmdlet.

Additional Information: In this scenario the device user will notice Group Policy and software distribution delivery failure. The server administrator may also notice two messages in system logs:

The management session with device xxx (device SID is displayed here not device ID) was not completed. The connection may have been lost, or the session timed out due to inactivity.

and

Erroneous OMA DM message received from device xxx (device SID is displayed here not device ID) during management session.

========

J.C. Hornbeck | Manageability Knowledge Engineer

New Knowledge Base articles for 12-14 through 12-20

jchornbe — Tue, 06 Jan 2009 17:14:24 GMT

For the week of 12-14 through 12-20 we had three new System Center Mobile Device Manager 2008 KB articles. Links and titles are below:

========

KB960829 - Error message when you try to upgrade to System Center Mobile Device Manager 2008 Service Pack 1: "Failed to determine status of MDM databases on SQL instance"
Sys Ctr Mobile Dvc Mgr 2008 EN
EN-US

KB960920 - Constraint violation 0x8007202F running AdConfig /enableGPSecurity
Sys Ctr Mobile Dvc Mgr 2008 EN
EN-US

KB961018 - Upgrade to System Center Mobile Device Manager SP1 Database Credential Failure
Sys Ctr Mobile Dvc Mgr 2008 EN
EN-US

========

Enjoy!

J.C. Hornbeck | Manageability Knowledge Engineer

SCMDM: Enrollment fails with "Unknown error in Enrollment service: System.ArgumentNullException: Value cannot be null"

jchornbe — Mon, 05 Jan 2009 17:29:00 GMT

Here's another MDM enrollment failure issue we ran across recently that's caused by the CA not being available when the SCMDM Enrollment Service starts. Fortunately the solution to this one is pretty easy:

========

Issue: Enrollment fails and the following event is logged on the Enrollment Server:

Unknown error in Enrollment service:
System.ArgumentNullException: Value cannot be null.
Parameter name: data
   at Microsoft.Mobile.ManagementServices.EnrollmentServer.CryptoService.ComputeHmac(Byte[] data, Byte[] sessionKey)
   at Microsoft.Mobile.ManagementServices.EnrollmentServer.Authentication.AuthenticateServer(BootstrappingRequest rc)
   at Microsoft.Mobile.ManagementServices.EnrollmentServer.Authentication.Authenticate(RequestContext rc)

Cause: This can occur if the Certificate Authority (CA) was not running when the SCMDM Enrollment Service started.

Resolution: Restart the SCMDM Enrollment Service.

========

J.C. Hornbeck | Manageability Knowledge Engineer

SCMDM: Mobile Device Manager setup error: "Failed to determine status of MDM databases on SQL instance"

jchornbe — Thu, 18 Dec 2008 19:28:00 GMT

Here's one more MDM Service Pack 1 issue for you, this one involving a setup error you might run into when upgrading:

========

Issue: Upgrading to System Center Mobile Device Manager 2008 SP1 fails with the following message:

Failed to determine status of MDM databases on SQL instance '<instance_name>'. Setup will now roll back all changes

Cause: During the upgrade, System Center Mobile Device Manager 2008 SP1 does not have access to the DB_USER and DB_PWD properties provided in previous installations of Device Management Servers or Enrollment Servers. It will instead default to using the current windows user's credentials.

Resolution: There are two ways to work around this issue:

1. Use Windows integrated authentication instead of the SQL username and password. The user who performs the upgrade must have sufficient privileges on the SQL Server where the MDM databases reside.

2. Uninstall your existing version of MDM prior to installing the SP1 version. Do not remove the existing databases during the uninstall process or your data will be lost. Once MDM is uninstalled, install System Center Mobile Device Manager 2008 SP1. It will give you the option to use the databases from your previous installation of MDM.

========

J.C. Hornbeck | Manageability Knowledge Engineer

SCMDM: Enrollment fails if a port other than 443 is used for the Enrollment Service

jchornbe — Wed, 17 Dec 2008 16:45:01 GMT

Here's another SP1 issue that we came across. If your server and client logs indicate that Enrollment failed because it could not resolve the Enrollment server URL and you changed the port then this may be your issue:

========

Issue: The server and client logs indicate that enrollment failed because it could not resolve the enrollment server URL.

Cause: Enrollment can fail if PAT (Port Address Translation) is used or if an alternate port other than 443 is used for the Enrollment Service.

Setup itself does not allow you to specify an alternate port number for the enrollment server when it is installed, so if an alternate port is specified in IIS after installation, and the SCP value for the enrollment server is not changed, then client auto discovery breaks. What happens is that the client is sent back a request to switch to the URI of an enrollment server without the alternate port causing the enrollment to fail.

Resolution: If the port number in IIS is changed to a port other than 443, the SCP value must also be changed.

To change the SCP value follow these steps:

1. Launch ADSIEDIT.MSC.

2. Right click on “CN=Instance” to bring up the property dialog box.

3. Check the ‘Show only attributes that have values’ checkbox.

4. Double click on ‘keywords’ attribute.

5. Change the “enurl= …” value to the new port number.

========

J.C. Hornbeck | Manageability Knowledge Engineer

The same software package may be installed every time a device connects to a System Center Mobile Device Manager 2008 server

jchornbe — Wed, 10 Dec 2008 18:53:49 GMT

Here's an interesting MDM issue I ran across the other day. If you're seeing the same package being installed again and again and again on your device then this may be what you're running up against:

========

Issue: A software package may be installed every time a device connects to a System Center Mobile Device Manager 2008 server. The user of the device may also notice multiple entries for a software package under Managed Programs.

Cause: If a managed Windows Mobile powered device is offered a software package through the MDM Software distribution console and the device installs the package, under certain conditions the status for the installation may not be received by the MDM server. If this occurs, the software package is re-offered to the device and the device reinstalls it. The result is that the user may see the package installed multiple times and multiple entries for the package may appear in the Managed Programs history on the device.

This issue can occur if the cab being installed reboots the device without prompting the user because the device goes offline after installing the software but before the next OMA session connection. The default OMA session connection interval (ConnectInterval value) is eight hours, so if the device then stays offline for longer than the software package re-offer period, MDM software distribution offers the package to the device again the next time that the device connects. The default setting for the re-offer period (ReofferPeriodInDays value) is seven days.

Resolution: To resolve this problem please work with provider to repackage the cab so that it will prompt the user before rebooting the device.

========

J.C. Hornbeck | Manageability Knowledge Engineer

SCMDM: The management console is no longer available after installing the MDM Reporting Services v1.1 reporting snap-in

jchornbe — Tue, 09 Dec 2008 17:00:19 GMT

Here's kind of a wacky issue we've seen a couple times so I thought I'd give you a heads up just in case you run into it. If you're trying to run the MDM Management console on the same box as the MDM Reporting console and seeing things disappear then this may be your issue:

========

Issue: The System Center Mobile Device Manager (MDM) management console is no longer available after installing the MDM Reporting Services v1.1 reporting snap-in. This only occurs on the system on which the MDM Reporting MMC was installed. Other MDM workstations that have installed the management console are unaffected.

Cause: This is caused because the MDM v1.1 Reporting snap-in is registered into the MMC catalog with the same name as the main management console.

Resolution: Until the complete fix for this problem has been made available, the MDM Reporting Services snap-in and the MDM Management Console snap-in cannot both function if installed on the same machine. To restore the MDM Management Console, run the SCMDM setup and re-install just the MDM Management Console.

========

Once an update for this becomes available an announcement should show up here on this blog or as part of a 'new KB' post. Stay tuned...

J.C. Hornbeck | Manageability Knowledge Engineer