After the first part (http://mobilitydojo.net/2008/10/30/scmdm-distributing-software-part-1/), the server “things” should be setup for distribution. But we would still need something to distribute – cue this part of the guide 
Creating a cabinet file and signing it
This being a “perfect” little lab we’re not going to develop a large and complex program to test – that’s not necessary for illustration purposes. Maybe it’s just me, but I dislike the “Sliding Sound” the HTC TyTN II has enabled by default (it also applies to some other HTC devices). So as a signing demo we’ll create a quick cab to disable this noise.
This would be the xml we need to perform this task.
<wap-provisioningdoc>
<characteristic type=”Install”>
<parm name=”InstallPhase” value=”install” />
<parm name=”AppName” value=”Disable Sliding Sound” />
</characteristic>
<characteristic type=”Registry”>
<characteristic type=”HKLM\Software\HTC\SlidingSound”>
<parm name=”ActiveSlidingSound” datatype=”integer” value=”0″ />
<parm name=”SlidingSoundEffect” datatype=”integer” value=”0″ />
</characteristic>
</characteristic>
</wap-provisioningdoc>
Create a new file called “_setup.xml”, and copy the xml above to this file. We then need to create a cab.
Open up the command prompt and run “makecab _setup.xml DisableSlideSound.cab”.
If you have Visual Studio installed you already have makecab. If not you’ll need to download it as a stand-alone tool – http://support.microsoft.com/kb/310618
You should now have a cab file, that is ready to be signed. How to verify it’s unsigned?
You don’t have a “Digital Signature” tab in File Properties:
![image_thumb13[4]](http://mobilitydojo.net/wp-content/uploads/2008/10/image-thumb134.png "image_thumb13[4]")
A few rules regarding signing. You don’t sign every file you want to send out to devices. You only sign executable files. This means .exe, .cab/.cpf and .dll, You don’t sign .mp3, .txt, etc. A cab-file is like a zip-file with more advanced capabilities (cab = cabinet), and can contain both exe-files and dll-files. And this is important – you need to sign the content, and not just the cab. A signed cab with unsigned/untrusted content will be untrusted!
Well, we’ll have to sign it then won’t we.
Open up your command prompt, and change to the directory where signtool.exe is located. (For simplicity I dropped the cab in the same folder.)
Run “signtool.exe sign DisableSlideSound.cab”.
Now there are numerous options to the signtool command, and I’m not going into them here. This is the easiest one, and it works since we only have one code signing certificate, and no advanced needs. You can get a GUI if you like though:
We’ll just verify the file was signed by checking it’s File Properties again:
Deploying Code Signing Certificate to DeviceWe had to configure the DM server to trust the CodeSigning certificate, and the devices are no different. We use Group Policy to deploy the certificate to the device (using the SCMDM GPO templates):
And remember to set the “Action” to “Install”:
Deploying applicationWe can now add this “application” to our suite of WSUS-distributed cabs.
Let’s create a package in the Software Distribution Console. Locating “Software Packages” on your left hand side, and you’ll be able to click “Create” on the right hand side.
It’s pretty much just about following the wizard and clicking “Next”, but I’m showing the screenshots for completeness. (Except for the filename and descriptions everything is left at the default setting.)
Nothing wrong with the package I suppose, so we will approve it right away. (I created a device group called “HTC TyTN II”):
Success:
Checking installation status on deviceIt’s nice to check that the application actually installed itself on the device. This one you can check just by sliding out the keyboard, but there’s no audio in this article so I’ll also show you the other way to tell.
The “Managed Programs” utility under Start->Settings is where the records are kept regarding which applications have been distributed by SCMDM.
Before installing:
After installing:
Details:
It seems like a lot of steps to perform what seems like a very basic task. But when you have performed the steps above once, you don’t have to do them all over again so it’s probably not that bad once you get used to it
Is there anyway to force it to check for new apps to install? What is the default interval check?
Great writups.
The device will always check for new apps when it connects. But new apps will only be installed after SCMDM has recalculated policies. This should coincide with the connection schedule if nothing is altered from it defaults. I think the default for recalculation is 8 hours. The default schedule is 8 hours. But this means that if you are testing devices, and use the “Connect Now” tool from the resource kit you may experience that nothing is distributed.
When I tested for the purpose of this guide I set the recalculation policy to 30 minutes but for production purposes this might not work well.
Excellent walk through. Thank you.
Is there a decision tree published anywhere for the connection/policy/app install process?
If I have something to get out in a hurry, but its signed with by a CA that I also have to deploy certs for, is it even possible that my Root cert/SPC/Priv Exec certs would be installed before the install is attempted?
Where is there more on this?
Thank you.
Ideally you would prepare a code signing certificate when you initially deploy the servers so you will be prepared the day you want to start distributing software.
Even if the application is already signed with a certificate issued by another CA than your own you can resign it with your own certificate and it would deploy without a hitch.
On the first connect a device does to the DM Server policies will be calculated/pushed down before the software distribution process can perform any tasks.
Now I cannot say for sure that’s what happens on all subsequent connections. I’ll have to dig through some documentation to see if I can locate the specifics. Initially I am guessing that these tasks can get out of synch with each other though, and that you risk having to wait another schedule run for the process to complete.
But I’ll look it up, and post another comment if/when I find something.
Hi Andreas,
Nice post
One query. For Mobile Device which certificate we need to import in SPC/Privileged Execution Trust Authorities?
Is it Certificate Authority Certificate or certificate issued via Code sign Template!!
From your post it seems Codesign Template certificate.
Thanks
The certificate of the CA needs to be in the root store, but this is done during the enrollment process in SCMDM so that’s not something you need to do manually. For the SPC store you need to provision the certificate the cab file is signed with – which would normally be the one you issued via the Code Signing template.
Hope that makes sense – there’s a lot of certificates to keep track of with SCMDM
Hi, thanks for the posts – very useful.
A few questions regarding software distribution:-
a. When I approve the software package I see the same approval screens and then the package disappears from the Admin console. I can’t find it in WSUS either and nothing is distributed to the device.
b. My device reports as successfully enrolled but I cannot update device details, or distribute software.
Any ideas?
The WSUS in SCMDM has shown itself to be a sneaky little component. Over at the TechNet forums there’s a lot of reports that upgrading the WSUS to SP2 breaks things. Have you done any Windows Updates lately?
Is the WSUS server installed on the DM server? (If I remember correctly there’s some extra steps if you don’t have them on the same server.)
As for devices not receiving software there could be both server side and client side issues. (It seems you have a server side issue, so the question is if there’s something with the device as well.) Does this apply to only a specific device model, or have you tried different models? It’s also convenient to test with the device emulator as a reference model.