This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Connect
- :
- FlexNet Connect Forum
- :
- Update Manager and our trial software.
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 22, 2006
11:59 AM
Update Manager and our trial software.
Any comment would be more than welcome, we are really out of ids on this one.
We have a trial software, which users can register or not.
Since installshield has no starter edition anymore we came up with the conclusion that only registered users would have access to the update (so that they are not counter in the user count $$).
Few problems with that.
1. Still need to install update manager during the evaluation. which mean we had to come up with a way to install update manager without our product listed.
What we did basically is install the sdk within our project. not the cleanest solution but works.
2. why on earth wouldnt flexnet let us block users on the server side. any one with an id on this? What i mean is even if your user is not allowed to get update it will still be counted in the user count $$.
My conclusion right now is that even with all the positive ways the solution can help, I am still going to look for alternative unless they surprise us and come back with a good answer.
Did anyone run into the same problems? If yes, what do you think we should do? any usuable way to achieve what we are trying to do.
Thank you.
D.
We have a trial software, which users can register or not.
Since installshield has no starter edition anymore we came up with the conclusion that only registered users would have access to the update (so that they are not counter in the user count $$).
Few problems with that.
1. Still need to install update manager during the evaluation. which mean we had to come up with a way to install update manager without our product listed.
What we did basically is install the sdk within our project. not the cleanest solution but works.
2. why on earth wouldnt flexnet let us block users on the server side. any one with an id on this? What i mean is even if your user is not allowed to get update it will still be counted in the user count $$.
My conclusion right now is that even with all the positive ways the solution can help, I am still going to look for alternative unless they surprise us and come back with a good answer.
Did anyone run into the same problems? If yes, what do you think we should do? any usuable way to achieve what we are trying to do.
Thank you.
D.
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 24, 2006
07:53 AM
Hello D,
You'll definitely want to speak with a sales representative about your concerns, as perhaps there are options that are not immediately apparent. Be vocal and contact them. Posting here may help vent, but won't help drive any solutions for you. We want our customers to succeed.
Regarding your comments, my initial thought was: why not prevent your application from even checking for updates until they're registered customers of yours? Every user that performs a check does use network bandwidth and does hit the server cluster, however small the request/response is. The FNC servers don't know whether they're a customer of yours or not (unless you use something like entitlement-based updating), but there's a cost associated with ensuring that they're always there and ready to respond to your applications' requests.
Regards,
Kelly
You'll definitely want to speak with a sales representative about your concerns, as perhaps there are options that are not immediately apparent. Be vocal and contact them. Posting here may help vent, but won't help drive any solutions for you. We want our customers to succeed.
Regarding your comments, my initial thought was: why not prevent your application from even checking for updates until they're registered customers of yours? Every user that performs a check does use network bandwidth and does hit the server cluster, however small the request/response is. The FNC servers don't know whether they're a customer of yours or not (unless you use something like entitlement-based updating), but there's a cost associated with ensuring that they're always there and ready to respond to your applications' requests.
Regards,
Kelly