In MSP 3.31 you can select settings and create select registry.settingxml and follow directions. go ahead and create staging barcode with the setting value. You will need to probably update the client on the handheld

The "best" way depends on the details of your requirements, including the degree of persistence you need and whether the registry settings you need to make are the same for many devices or vary from device to device. In MSP 3.3.1, you can use Registry Settings Objects to make changes to the registry.  This is best when the changes to be made for different devices vary, since it can be used with Dynamic Deployment to send different registry infomation to different devices.  If a Registry Settings Object is included in a Bundle, then it will be re-applied on cold/clean reboot hence will be persistent.  But since you can only have ONE persistent Registry Settings Object per device, it may not be the best solution if you have many different things to set into the registry for each device, as part of many different applications or policies. In ALL versions of MSP, you can deploy .REG files via Packages.  If you merge them as part of the install command of the Package and store them in \Application, then they will perist across cold/clean reboot.  This approach is more complicated, since it requires building Packages correctly, and it is less amenable to use with Dynamic Deployment.  So, it is better if the same .REG file is to be deployed to many devices.  It has the advantage that any number of .REG files can be deployed to a given device and all will be persistent, so long as they are named differently.  So, it is fairly easy to include parallel registry settings for different applications in different policies. In Windows Mobile devices, bit NOT on Windows CE devices, you can also use Provisioning XML to configure the registry.  In MSP 3.3.1, you can use an MSP XMLProv Settings Object to deploy such XML.  I would generally not recommend doing that unless you already have XML that works, since it is generally more trouble to construct such XML than to construct registry changes directly, for use with a Registry Settings Object.