To run the SMS Online Library after you install SMS 2003 SP2:

From the Start menu, click Programs, click Systems Management Server, and then click SMS Online Library.

-Or-

Right-click SMS Online Library in the SMS Administrator console tree, and then click Run Online Library.

Visit the Microsoft Systems Management Server Web site to locate product information, product documentation and other information about Systems Management Server (SMS) 2003 Service Pack 2 (SP2) and related products.

Visit the Microsoft Help and Support Web site to search the Microsoft Knowledge Base and other technical resources for fast, accurate answers to SMS questions. You can query the Knowledge Base to find an article about a specific issue by using the number that is assigned to the issue.

It is important to install the latest security updates available, for any new software being installed, to help protect against security vulnerabilities and viruses. For more information, see Microsoft Security.

If you have general comments or suggestions about Systems Management Server (SMS), send them to smswish@microsoft.com.

To provide comments about Systems Management Server (SMS) documentation, send your documentation feedback to smsdocs@microsoft.com.

In addition to the System Requirements detailed in the SMS 2003 Device Management Feature Pack Guide, the following additional requirements should be noted:

SQL Server 2000 or later version is required for installation of the Device Management Feature Pack. Specifically, SQL Server 7 is not supported.

The desktop inventory extensions and device client deployment components are supported for use only with the SMS 2003 Advanced Client.

To distribute software to Windows Mobile for Pocket PC 5.0 or later devices and Windows Mobile for Pocket PC Phone Edition 5.0 or later devices that are managed by SMS 2003, you must sign all software distribution packages and their contents with their privileged SPC certificate before sending the package to the distribution point.

To distribute settings to Windows Mobile for Pocket PC 5.0 and Windows Mobile for Pocket PC Phone Edition 5.0 or later devices, you must sign all settings (.cab) files before sending the package to the device.

Use a cab signing tool to sign .cab files and their contents. Signtool.exe can be used to sign executable files. Signtool.exe is available for free download at the MSDN Web site (http://go.microsoft.com/fwlink/?LinkId=59261).

Important
Versions of Pocket PC prior to Pocket PC 5.0 do not support code signing. A signed package sent to one of these earlier versions will fail to install.

SMS 2003 Device Management Feature Pack password application will not install on devices that have been upgraded to the Microsoft Messaging & Security Feature Pack (MSFP). MSFP introduces new password settings, such as local wipe, that provide additional security options.

If you have upgraded to MSFP, you can use this example .xml text to create a configuration file to manage MSFP password settings that can be distributed to devices using software distribution.

To create a configuration file to manage MSFP password settings:

1. Configure the registry settings in a valid provisioning .xml file (see example below).
   
   
2. Save the .xml file as _setup.xml (this file name must be in lower case characters).
   
   
3. Create a .cab file from the _setup.xml file using the makecab.exe utility available from the MSDN Web site.
   
   
4. Code-sign the .cab file with the necessary certificates (see information regarding code-signing in the release notes).
   
   
5. Distribute the code-signed .cab file using SMS 2003 software distribution.
   
   

Example _setup.xml file

Copy Code

<wap-provisioningdoc> <!-- Password Required Policy --> <characteristic type="SecurityPolicy"> <!-- Specifies if a password must be configured on the device --> <!-- (if it is not already configured) and that all other --> <!-- password complexity policies should be followed --> <!-- [0] Password configuration is required --> <!-- [1] Password configuration is not required --> <parm name="4131" value="0"/> </characteristic> <!-- Timeout Policies --> <characteristic type="Registry"> <characteristic type="HKLM\Comm\Security\Policy\LASSD\AE\{50C13377-C66D-400C-889E-C316FC4AB374}"> <!-- [0-9999] This is the amount of time in minutes after --> <!-- the device is turned off(Pocket PC) or idle (Smartphone) --> <!-- that will cause the device to become password locked --> <parm name="AEFrequencyValue" value="5"/> <!-- [0] Triggers device lock at every Authentication Event --> <!-- [1] Countdown based on shell idle time behaviour --> <parm name="AEFrequencyType" value="1"/> </characteristic> </characteristic> <!-- Device Wipe Threshold Policy --> <characteristic type="Registry"> <characteristic type="HKLM\Comm\Security\Policy\LASSD"> <!-- [1-4294967295] Specifies the number of times an incorrect --> <!-- password can be entered before the device memory is erased --> <parm name="DeviceWipeThreshold" value="20"/> </characteristic> </characteristic> <!-- Minimum Password Length Policy --> <characteristic type="Registry"> <characteristic type="HKLM\Comm\Security\Policy\LASSD\LAP\lap_pw"> <!-- [1-40] Specifies the minimum number of characters required --> <!-- in a password or PIN. If this is applied more generically --> <!-- to another LAP that does not take character input, it can --> <!-- be used to specify the length of the encryption key (in bits) --> <parm name="MinimumPasswordLength" value="8"/> </characteristic> </characteristic> <!-- Password Complexity Policy --> <characteristic type="Registry"> <characteristic type="HKLM\Comm\Security\Policy\LASSD\LAP\lap_pw"> <!-- This security policy determines the complexity of the --> <!-- password or PIN allowed --> <!-- [0] Only a strong password can be used --> <!-- [1] Only allow a PIN to be used (no non-numeric) --> <!-- [2] Any type allowed --> <parm name="PasswordComplexity" value="0"/> </characteristic> </characteristic> </wap-provisioningdoc>

The DmCommonInstaller.ini file will not be replaced by the upgrade when the .ini file under the SMS\DeviceClientManagement\ClientTransfer directory has newer timestamp than the one from the Device Management Feature Pack Upgrade. This would generally occur when the DmCommonInstaller.ini file has been manually updated sometime after the release date of Device Management Feature Pack.

WORKAROUND:   Save the DmCommonInstaller.ini file from the Device Management Feature Pack to an alternate directory, edit the DmCommonInstaller.ini file from the Device Management Feature Pack applying any custom updates and then replace the file in the SMS\DeviceClientManagement\ClientTransfer directory with the newly updated version.

Device Management Collections do not show up in the SMS Administrator Console at child sites that do not have the Device Management Feature Pack installed. This is cause by missing tables that are used by the collection queries.

WORKAROUND:   Install the Device Management Feature Pack on the child site to add to the necessary tables to the SQL database. If the collections still do not appear at the child site, it might be necessary to either add or delete a collection at the parent site to force a resync of all collections at the child site.

The Device Client Agent and password application will install correctly on Pocket PC 2002 and Pocket PC 5.0 devices, but a warm reset is required for the application icons to appear in Control Panel on the device.

For Pocket PC 5.0 devices, wait 3 minutes after the Device Client Agent or password application completes the installation before performing a warm reset. This allows the device to commit changes to the registry. Resetting the device too soon might result in the loss of settings.

WORKAROUND:   Perform a warm reset of the device after installation.

Uninstallation of the SMS 2003 password application on Pocket PC 2002 devices, using client deployment, does not restore the original password application.

WORKAROUND:   Perform a warm reset of the device.

When a password is set, the Device Management Feature Pack password application may truncate the owner name displayed on the password entry screen.

WORKAROUND:   None.

When a .CAB file is installed on a Pocket PC, the file will be removed after installation. For a recurring device advertisment, the Device Client Agent will not repeatedly download files that have not changed on the distribution point. This leads to recurrent .CAB installations failing after the first installation. This is specifically an issue for reapplying device settings packages that are enclosed in a .CAB.

WORKAROUND:    Use Device Management script functionality to copy the .CAB before it is run by performing the following steps. The original.cab is the name of the installation file in the package source directory. Ensure that the location of this file matches the download location specified in the device program property page, in this case \temp.

Create a file Rerun.dms, and enter this text:

copy \temp\original.cab \temp\torun.cab

run \temp\torun.cab

Include the Rerun.dms file in the package source directory.

Set the command line for program to be Rerun.dms.

DMConsol is a debugging tool included with the Pocket PC 2002 and Pocket PC 2003 Device Management Clients. It is not localized.

WORKAROUND:   None.

By default, the DMCommonInstaller.ini file specifies that HTTPS should be used: the UseHTTPS flag is set to True. This means that the Device Client Agent requires a certification authority root certificate in order to trust the device management servers it connects to.

WORKAROUND:    Perform the following steps to use a server certificate based on trust from public or enterprise certification authority and distribute the public key version of the root certificate to the devices:

Obtain a root certificate from the certification authority which issued the device management server’s web-server certificate.

Distribute this certificate as part of device client deployment. To distribute a certificate file (.cer) to the devices, it should be placed in the same directory as the DMCommonInstaller.ini file.

In the DMCommonInstaller.ini file, the InstallCerts property should be set to True for this certificate to be installed by the device management installer.

The Registry Entry settings user interface in Device Settings Manager does not allow user to enter the Time field correctly when Time Only or Date and Time registry data types are chosen. As a result, the above registry data types cannot be created on the device.

WORKAROUND:   Use a manual registry file if registry configuration of this type is required. This file can be distributed using software distribution and applied using the device management script.

Create a file applyreg.dms, and enter this text: loadreg

Include the applyreg.dms and registry file in the package source directory.

Set the command line for program to be applyreg.dms.

All currently available consumer Pocket PC devices support a unique hardware ID that the Device Management Agent uses as the SMS unique identifier, and the device management functionality works as designed.

Certain industrial devices do not report a unique device ID, so multiple devices share the SMS unique identifier, rendering the devices individually unmanageable by SMS. The result is that only a single device discovery data record (DDR) appears in the SMS Administrator console, even though multiple devices are successfully communicating with the SMS device management point.

WORKAROUND:   Use alternative Device Client registry settings to change DeviceID behavior. To do this, create a registry script or use other means to change two registry keys on the device as follows:

Create this registry value : HKLM\Comm\ApplicationDownload\SimDeviceID with a type DWORD

Set the value to one of the following (values 1-3 change the behavior of the Device Client Agent):

Value 0 : Default hardware ID functionality

Value 1 : Generate an ID based on a random numbers.

Value 2 : Generate ID from MAC address, if this fails return ID "NO_MAC_ADDR_DEVICE"

Value 3 : Generate ID from MAC address, if this fails generate an ID based on random numbers.

Set this value as a blank string to trigger the Device Client Agent to reset the DeviceID: HKLM\Comm\ApplicationDownload\DeviceID

These steps can be carried our prior to device installation, or subsequent to Device Client Agent installation, even when the Agent is running. If the Agent is running, then the next HTTP request to the device management point will generate a new device ID. The Device Client Agent will set the new device in the ‘DeviceID’ registry value, and not change this value again.

Caution

Use of options 2 or 3, blanking of the device ID and subsequent reset of the device might result in the Device Client Agent being unable to acquire a MAC address because device networking components are still initializing. It is recommended that options 2 or 3 are not used in a reset scenario.