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
- :
- Re: Update Thoughts
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
‎Feb 12, 2005
08:51 AM
Update Thoughts
Years ago ( IS Pro 5.0 ) I wrote a custom update service for a powerbuilder client/server application. Basically in those days each "site" ( 120 of them ) had different network operating systems with no standard baseline of capabilites. The system we designed was basically a self contained solution. The requirement was the end users could update the client without the need for an Administrator to walk around and do it.
Our solution was pb framework and system services code that checked a table on the database. If the table said there was a newer version then what we had, a message was displayed to the user saying they needed to update and then a web page was launched where InstallFromTheWeb was ready to serve them.
This worked really well for several years until most of our sites started getting more sophisticated. A massive W2K/XP migration occurred and suddenly site administrators were no longer happy with users doing the update. They wanted to lock the desktops down and do it themselves. So we exposed the web content through a share and gave them instructions for how to extract the files and what commandline was needed to run the setup silently.
The concept here is managed desktops versus unmanaged desktops. They both have two seperate sets of requirements when you get down to it.
So perhaps ISUS/UM could be controlled via Policy so that those sites who don't want it can forbid it where they need it forbidded.
Our solution was pb framework and system services code that checked a table on the database. If the table said there was a newer version then what we had, a message was displayed to the user saying they needed to update and then a web page was launched where InstallFromTheWeb was ready to serve them.
This worked really well for several years until most of our sites started getting more sophisticated. A massive W2K/XP migration occurred and suddenly site administrators were no longer happy with users doing the update. They wanted to lock the desktops down and do it themselves. So we exposed the web content through a share and gave them instructions for how to extract the files and what commandline was needed to run the setup silently.
The concept here is managed desktops versus unmanaged desktops. They both have two seperate sets of requirements when you get down to it.
So perhaps ISUS/UM could be controlled via Policy so that those sites who don't want it can forbid it where they need it forbidded.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2005
10:06 AM
Christopher,
A good point, but I think the problem is deeper than that.
You clearly have a particular perspective and requirements based on your experience from EDS / Continental. I work for a company that sells software development tools to software developers in large and small companies. Neal007 sells software to pilots. My Mum might use a word processor that installs the Update Manager. We're all InstallShield customers or users.
InstallShield's aim appears to be to get everybody in the world to use the Update Manager to patch their applications. If this is what they want to do then they need to ensure that you, your system administrators, me, my customers, Neal007, aircraft pilots and my Mum are all happy with their product.
If you're going to go beyond the pure update service that was available in version 2.x and provide a universal update manager for software patches then this is probably a very difficult problem to crack. To solve it, I think they're going to need to some deep thinking about the problem and make some significant changes to the Update Manager.
At the moment I think the Update Service and Update Manager may make some people happy, but they're also going to alienate and frustrate a lot of other people.
If I were the product manager, I would provide a patch to the update manager which didn't require products to register with it to receive updates, then pull it from general release, look at this forum and other feedback, and then think about the problem better before deciding if/how to do it again.
Note that I don't have a problem with the concept or implementation of the update *service*, just the manager.
A good point, but I think the problem is deeper than that.
You clearly have a particular perspective and requirements based on your experience from EDS / Continental. I work for a company that sells software development tools to software developers in large and small companies. Neal007 sells software to pilots. My Mum might use a word processor that installs the Update Manager. We're all InstallShield customers or users.
InstallShield's aim appears to be to get everybody in the world to use the Update Manager to patch their applications. If this is what they want to do then they need to ensure that you, your system administrators, me, my customers, Neal007, aircraft pilots and my Mum are all happy with their product.
If you're going to go beyond the pure update service that was available in version 2.x and provide a universal update manager for software patches then this is probably a very difficult problem to crack. To solve it, I think they're going to need to some deep thinking about the problem and make some significant changes to the Update Manager.
At the moment I think the Update Service and Update Manager may make some people happy, but they're also going to alienate and frustrate a lot of other people.
If I were the product manager, I would provide a patch to the update manager which didn't require products to register with it to receive updates, then pull it from general release, look at this forum and other feedback, and then think about the problem better before deciding if/how to do it again.
Note that I don't have a problem with the concept or implementation of the update *service*, just the manager.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2005
11:21 AM
Concur, I think the Update Service has GREAT value and I'll probably hang in there one more year, depending on the cost of my renewal in early April which the contract is up for re-negotation (one bad vibe and I'm out!).
However, this "intrusion" is just really riling the feathers of many and most importantly IT staff that don't want things out of their control. The UM has great intentions to help keep a PC up to date, but you go installing an "application" that is not clear to the end user that will be installed, you have a problem. When my users install "Application X" they only expect to see "Application X" not some additional application appear that totally catches them by surprise. This is parallel to Adware and probably falls directly inline with the definition of it if it were defined somewhere...which I'm sure it is.
However, this "intrusion" is just really riling the feathers of many and most importantly IT staff that don't want things out of their control. The UM has great intentions to help keep a PC up to date, but you go installing an "application" that is not clear to the end user that will be installed, you have a problem. When my users install "Application X" they only expect to see "Application X" not some additional application appear that totally catches them by surprise. This is parallel to Adware and probably falls directly inline with the definition of it if it were defined somewhere...which I'm sure it is.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2005
01:43 PM
I work in "Enterprise Engineering" and I can vouch that they don't allow Windows Update via policy and they sure won't allow another vendor to do it. We know what days Microsoft releases patches and we go through a drill where we look at the vunerabilities and impacts. The updates are then piloted to test machines in different organizations and then shortly there after we deploy across the enterprise ( all 17,000 machines ). To think that we'd let microsoft push the updates to our machines when they are the users are ready is not realistic. All we expect from a vendor is bits that are deployment ready. Often that doesn't happen so we have to repackage. But the distribution method of when where and how is up to us.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2005
08:48 PM
Christopher,
The way I'd go about solving the problem is simply through some creative use of the update conditions ISUS gives me. Perhaps I would have all enterprise computers have a registry setting or a file that would essentially mean "I'm an enterprise computer, don't update me, my admin will do it later!" So, when you release an update, they wouldn't get targeted.
Then, I would simply email the enterprise admin about a new update, provide the patch, and ask them to put it in the next time they can.
Given that virtually all enterprise admins handle their networks differently, I would assume I'd need to contact them all personally via phone or email, and let them know of new updates, and then let them handle it.
Of course, as the rest of us have been discussing on lately, this would require that UM is not installed, and if another application did install UM, that we could have the option to not have our application updates ever be handled through UM.
The way I'd go about solving the problem is simply through some creative use of the update conditions ISUS gives me. Perhaps I would have all enterprise computers have a registry setting or a file that would essentially mean "I'm an enterprise computer, don't update me, my admin will do it later!" So, when you release an update, they wouldn't get targeted.
Then, I would simply email the enterprise admin about a new update, provide the patch, and ask them to put it in the next time they can.
Given that virtually all enterprise admins handle their networks differently, I would assume I'd need to contact them all personally via phone or email, and let them know of new updates, and then let them handle it.
Of course, as the rest of us have been discussing on lately, this would require that UM is not installed, and if another application did install UM, that we could have the option to not have our application updates ever be handled through UM.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2005
08:56 PM
neildavidson wrote:I would somewhat disagree. In version 3, they released a merge module that does not include UM. Also in version 3, they released documentation that specifically details how to handle updates automatically through your app without using the UM. In version 4, they have a checkbox in InstallShield 10.5 that apparently makes it so UM is not installed. (Unfortunately, this checkbox does not exist in InstallShield X Express).
InstallShield's aim appears to be to get everybody in the world to use the Update Manager to patch their applications. If this is what they want to do then they need to ensure that you, your system administrators, me, my customers, Neal007, aircraft pilots and my Mum are all happy with their product.
If they wanted everyone to use UM, they probably would not have released that version 3 merge module, or documentation and objects that make updates possible without the UM, or web page based updates, or a checkbox in 10.5.
I just think that InstallShield has not yet been able to reconcile the differences with UM with other ISUS updating scenarios. We've only started really harping on the Update Manager within the last 2 months, so I'm going to give them some time to see if they will mature the ISUS service to fit our needs to never allow UM to intregrate with our products.