Here's another MDM SP1 issue for you.  This one involves the Set-EnrollmentPermissions command and an error you can receive if SCMDMEnrollmentServers has full permissions on the specified OU:

========

Issue: When running the Set-EnrollmentPermissions command you may receive the following error:

Set-EnrollmentPermissions : Error encountered when delegating container "OU=SCMDM Managed Devices (Instance1),DC=yonaloc,DC=nttest,DC=microsoft,DC=com" permission to Enrollment Server.
At line:1 char:26
+ Set-EnrollmentPermissions  <<<< "SCMDM MAnaged Devices (Instance1)"

Cause: The Set-EnrollmentPermissions command verifies what permissions SCMDMEnrollmentServers has on the specified OU (i.e. the OU that is passed in the command).  There is a known issue in this verification process where it will return false if Full Permissions are enabled.

Resolution: Do not enable full permission for SCMDMEnrollmentServers group on the device OU. To workaround this issue delete the SCMDMEnrollmentServers group from Security.  To do this follow these steps:

1. Run DSA.MSC.
2. Find the OU where you were trying to set permissions.
3. Right click on the OU and select Properties.

4. On the Security tab, click on SCCMEnrollmentServers(<your instance name>) and remove it.

The last step is to run the Set-EnrollmentPermissions command again.  This time it should succeed without error.

========

J.C. Hornbeck | Manageability Knowledge Engineer

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

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.

or

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

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

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

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

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

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

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

After being enrolled for a year, a System Center Mobile Device Manager (SCMDM) managed device may fail to renew its client certificate.  As a result it will fail to connect to the SCMDM VPN successfully.

Additionally, the issuing Certificate Authority Application Event Log contains a warning similar to the following:

Event Type: Warning
Event Source: CertSvc
Event ID: 53
Description:
Certificate Services denied request 97 because The request contains conflicting template information. 0x80094802 (-2146875390).  The request was for CN=device.contoso.com.  Additional information: Denied by Policy Module  0x80094802, The request specifies conflicting certificate templates: 1.3.6.1.4.1.311.21.8.13101452.6590778.3820446.1524682.2069567.226.1027488195.1669196290/SCMDMMobileDevice(MDM1).

This can occur if there is a space in the template name.  When the SCMDM managed device requests to renew its client certificate, the space character in the template name is dropped.  As a result, the certification authority cannot process the request and results in the above error.

For the latest information on this issue including the resolution, see the following Knowledge Base article:

KB2273458 - System Center Mobile Device Manager 2008 SP1 device certificate renewal request fails after 12 months

J.C. Hornbeck | System Center Knowledge Engineer

Here's another MDM SP1 issue for you.  This one involves the Set-EnrollmentPermissions command and an error you can receive if SCMDMEnrollmentServers has full permissions on the specified OU:

========

Issue: When running the Set-EnrollmentPermissions command you may receive the following error:

Set-EnrollmentPermissions : Error encountered when delegating container "OU=SCMDM Managed Devices (Instance1),DC=yonaloc,DC=nttest,DC=microsoft,DC=com" permission to Enrollment Server.
At line:1 char:26
+ Set-EnrollmentPermissions  <<<< "SCMDM MAnaged Devices (Instance1)"

Cause: The Set-EnrollmentPermissions command verifies what permissions SCMDMEnrollmentServers has on the specified OU (i.e. the OU that is passed in the command).  There is a known issue in this verification process where it will return false if Full Permissions are enabled.

Resolution: Do not enable full permission for SCMDMEnrollmentServers group on the device OU. To workaround this issue delete the SCMDMEnrollmentServers group from Security.  To do this follow these steps:

1. Run DSA.MSC.
2. Find the OU where you were trying to set permissions.
3. Right click on the OU and select Properties.

4. On the Security tab, click on SCCMEnrollmentServers(<your instance name>) and remove it.

The last step is to run the Set-EnrollmentPermissions command again.  This time it should succeed without error.

========

J.C. Hornbeck | Manageability Knowledge Engineer

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

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.

or

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

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

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

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

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

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

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

After being enrolled for a year, a System Center Mobile Device Manager (SCMDM) managed device may fail to renew its client certificate.  As a result it will fail to connect to the SCMDM VPN successfully.

Additionally, the issuing Certificate Authority Application Event Log contains a warning similar to the following:

Event Type: Warning
Event Source: CertSvc
Event ID: 53
Description:
Certificate Services denied request 97 because The request contains conflicting template information. 0x80094802 (-2146875390).  The request was for CN=device.contoso.com.  Additional information: Denied by Policy Module  0x80094802, The request specifies conflicting certificate templates: 1.3.6.1.4.1.311.21.8.13101452.6590778.3820446.1524682.2069567.226.1027488195.1669196290/SCMDMMobileDevice(MDM1).

This can occur if there is a space in the template name.  When the SCMDM managed device requests to renew its client certificate, the space character in the template name is dropped.  As a result, the certification authority cannot process the request and results in the above error.

For the latest information on this issue including the resolution, see the following Knowledge Base article:

KB2273458 - System Center Mobile Device Manager 2008 SP1 device certificate renewal request fails after 12 months

J.C. Hornbeck | System Center Knowledge Engineer