"streaming" users with autoupdates

[andyboyd]

Hi,

We're planning to use setupbuilder to create an installer with autoupdates. When a customer's support contract runs out, we should be able to remove them from the autoupdates list, so they will no longer receive new software upgrades.

We're making the assumption that some of our customers may not be particularly tech savvy, so everything should be manageable on our end. Ideally, the system will be installed initially by a support engineer on site, and from then on any software upgrades should be done without the user really having to do anything.

Creating the autoupdate script is no problem. What I need help with is an approach to uniquely identifying a user and configuring the autoupdate script to only download the latest update if the user has a current support contract.

[linder]

Hello,

What about using the built-in Developer Edition "Subscription-Key Protection" feature? This lets you quickly generate "Subscription Keys" to protect your installations and updates. This technology is well suited for software subscription services in which the end-users subscribe, for instance on a monthly, quarterly, semi-annually, etc. basis.

At the end of the subscription period, end-users will have the option of extending the subscription or simply continuing their current version. But end-users will no longer be able to utilize product updates released after the subscription expiration date/version. With setupPROTECT, the subscription renewal is easy and simple. You only have to send a new "Subscription Key" to your end-user.

By the way, the user can still check and see if there are updates available. If an update is available and the subscription expired, you can display renewal information, forward them to your order page, whatever you want.

What do you think? If using the above method is not an option for you, let me know and I am sure we can find another solution.

Friedrich

Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[andyboyd]

OK, sounds good, but I'm a little unclear as to how this works. Do we need to generate a unique subscription key for every user? Or does it tie in with the serial number generator where a list can be created all at once?

[linder]

I assume you have quite a few users with different expiration dates. So yes, you'll generate a unique subscription key for every user.

You can generate one subscription key for all users -- but then it will expire for all users at the same time.

Does this help? Just let me know if you need more information.

BTW, here are two interesting links:

http://www.lindersoft.com/forums/showthread.php?t=1191
http://www.lindersoft.com/forums/showthread.php?t=2895

Friedrich

[andyboyd]

That should be ok. I'll have a look into it and get back to you if there are any problems. Thanks.

[andyboyd]

OK, we've been looking at this, and I have a few more questions.

Our application currently only has one feature, but in the future we plan to add more. Customers will purchase each feature separately, and the application will need to know which features a particular customer has installed. The application will then enable or disable each feature based on this information.

Setupbuilder's subscription key functionality gives the option to install different features based on the information contained within the key, but we don't want the customer to have to reinstall the application if he purchases another component at a later date. We want the customer to be able to download the software when he first buys it, then if he decides a month down the line that he wants to buy another component, we should be able to e-mail him a new subscription key, which he can input and the component he's just bought will be unlocked for him to use without the need to download anything additional.

Ideally, we would like to use the subscription key generated by setupbuilder for this. The key contains information about permitted components, but is there any way that our application can "decode" the key, so it knows which components to allow the user to run?

Just to reiterate, all the components will be installed for every user, the key will be input by the user on installation, and our application will reference this from the registry in order to determine which components to unlock for the user. A new key can be supplied at a later date if new components are purchased. Our application needs to be able to understand the information contained in the subscription key without referencing an online database. IF setupbuilder can do this, great. If not, do you know of any other options we could use?

Thanks.

[linder]

Hello,

This is absolutely no problem -- we did a Script Writing Consulting project for a large U.S. company last December that does exactly this.

In the above project, the installer has all components in one setup.exe. The SetupBuilder subscription key technology can handle up to 10 different "components". For example, one customer buys a product and only Component 1 and Component 4 are the permitted components. The installer has all the functionality built-in to decide which component is allowed to install and which component is not available (for this specific key).

And of course, there is no need to do a full reinstall if he would like to add another component. The SetupScript language lets you detect installed components (based on your own logic) and allows to install another component if required (e.g. if he buys a new subscription key that gives him access to another component).

If you are interested, we could try to develop a small demo for you that demonstrates the above.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[andyboyd]

That still sounds like it requires new components to be installed at a later date though. We have a small team, and we only want to have to maintain a single executable (of our application, not the installer), so we need the user to be able to install every currently available component, but then our application will only give access to the permitted ones. It will have to be our application that decides this, not the installer.

[linder]

Aha, okay. Sorry, I misinterpreted your requirement. Yes, the new components have to be installed at a later date in this case. The setupPROTECT feature only works from the installer application. Your own application cannot directly use the setupPROTECT technology.

Another idea. The user installs every currently available component. What you can do is to develop a small "helper" application with SetupBuilder. SetupBuilder does not only generate installations -- it can also generate tools. In this helper application, you can check if a specific subscription key gives access to a specific component. You call this helper.exe from your application and the helper returns a "magic" value that tells your application whether access to a component is permitted or not.

What do you think?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[andyboyd]

I'm not sure if that would be practical for us really, we'd probably need to invoke it too often to be ideal, but we'll need to consider the options. Thanks for your help anyway, I'll be in touch again if there's anything else you can help us with.

[linder]

You are very welcome.

IMO, the best (and most secure) solution would be to install only the permitted ones.

We will be here when you need us.

Friedrich