Deployment of SmartFTP Client using SMS

This thread has been started to share experience, problems and solutions deploying the SmartFTP Client using Microsoft System Management Server (SMS).

Do you or did you have any problems deploying the SmartFTP software using SMS?
Did you create MSI Transforms (MST)?
What tools did you use? Wise? Installshield?
How did you deploy the license key to the licensed users?

We would appreciate any feedback.
Thank you.
-Mat

References
Microsoft System Management Server (SMS)
MSI at MSDN
MST File Viewer
Moving Software Installation Packages between Group Policies
InstallSite

OK, this took seriously much longer than expected, mostly due to completely unrelated issues
The one thing that did cause me some headache was the deployment of the license file, mostly due to my own inexperience with the tools at my disposal.

But now that I'm done I figure I might as well share my approach with others, and in the process document it for myself for the future (my memory stinks, and I just know I'll have forgotten this within a month).

Let me just first briefly outline the setup I did this in.

[indent]We've got a Microsoft Systems Management Server (SMS) 2003 SP1 located in another country but which the clients connect to over the WAN. Local distribution points take care of the speed concerns, and the biggest impact this has is the dead-slow response of the MMC GUI for us deployment people

For repackaging I have a license for Wise Package Studio, but for this particular task I think you can get by with just about any repackager. For a flat-out basic install I'll even throw in a mst later.

As I started this I was working with 1.5.x, but I soon noticed v2.0 was being promoted on the front page so I decided to switch to that allthough I can't find any sort of announcement that it's officially out of beta and the new major version. Subsequently, all the following applies to v2.0 and v3.0

Also, I did this for Windows XP Pro AD member machines, but it should work just the same in Win2k Pro[/indent]

The transform file I created is a standard affair which accepts all the defaults and makes a typical install to the default location. If that's all you need, you're free to download and use the one I made from here. It doesn't contain any files, it simply provides the installer with answers to all the questions. Also keep in mind that by default the 2.0 installer doesn't replace or upgrade the 1.5.x version if installed, so you'll want to uninstall that separately unless you want to use them side by side. Upon launch v2.0 will still offer to import the favourites etc from 1.5 tho.

Now, when you create the package in SMS or a similar deployment solution, thanks to SmartFTP's clean use of the MSI technology, you can use a plain vanilla msiexec command like this:
MSIEXEC.EXE TRANSFORMS="SmartFTP.mst" /i "SmartFTP.msi" /qn /log c:\smslog_SmartFTP_2.0.993.10.log
This will run the installation with the transform applied silently, and log the installation to a log file in root. Feel free to change this to whatever suits you, just make sure the folder you specify already exists or the install will fail.

This pretty much takes care of the actual SmartFTP deployment, it's really straightforward. As I mentioned in the beginning, the license file was a different matter. When you run the licensing exe you get when you register, it places a license file in the users \Documents and Settings\"profilename"\Application Data\SmartFTP\ (in the case of 1.5) and \Documents and Settings\"profilename"\Application Data\SmartFTP\Client 2.0\ (in the case of 2.0)
To make this approach work you'll need to register SmartFTP on a system and then copy the SmartFTP.key from that and to a network share that your users will have read access to.

Because most software deployment solutions such as SMS will run the installation under the context of an administrative account or LocalSystem, it will have no concept of who the actual user is or what profiles might be in use, so putting it with the rest of the install isn't going to do you much good.

After spending too much time thinking about the problem and too little time looking into the options of SMS 2003, it turns out the solution comes in the form of a simple batch file and some simple settings in SMS:
(I've decided to use drive mappings because I can rely on that this mapping is present for all users that needs to be licensed, and we're currently migrating servers so locations are shifting, you might want to use UNC instead)

First of all you might want to set the program to run hidden, otherwise the batch file will cause a cmd box to flicker on the users screen:


Secondly, under Environment, make sure you set the program only to run when a user is logged on, and with the users rights. I've also made a check for the appropriate drive mapping, you might choose not to.


Finally, under the Advanced tab I've made a check to make sure the actual application is installed first, this really isn't all that important, I just always try to link dependancies to their parent apps as a rule. More importantly, I've set the batch file to run once every time a new user logs on. This is the core to get this to work, as this makes sure you'll get the license file distributed to the profiles on each system, including the main user. IMPORTANT: As this will in effect license every user that logs on to every system this is applied to, make sure you're not violating the EULA or exceeding your license count.


Finally, the contents of the Lic.bat file. This is ultrasimple:
REM This will install the license file for v2.0 and v3.0 of SmartFTP

xcopy "P:\INSTALL\SmartFTP\SMS\SmartFTP.key" "%APPDATA%\SmartFTP\Client 2.0\" /Y



REM This will install the license file for v1.x of SmartFTP

xcopy "P:\INSTALL\SmartFTP\SMS\SmartFTP.key" "%APPDATA%\SmartFTP\" /Y

The reason I have both in there is that we already have old manual installations out there with an old license file, this way those gets updated to the latest license file with updated maintenance periods too.
If you're deploying only new clients you obviously only need to copy to the first location. The reason I use xcopy is that it will automatically create the destination directory if it doesn't exist, whereas "copy" will not, and I use the /Y parameter to instruct xcopy to overwrite existing files such as old license keys.

OK, so this wasn't rocket science, and I guess it's not the most elegant of solutions, but it works and it saved me a whole lot of "Nike-based deploment". I hope it will at least prove remotely useful to others too

/rant

Regards,
Tomas Fjetland