I just don't get it

[cterpm]

Normally I figure out software easily. But I just don't understand the update service. If I want to target just system admins, what am I supposed to do? Why aren't there some easy to follow examples anywhere? Why does it say "Click on any [question mark] icon to get help on that field," but nothing happens when you click? Why does the help file require that you click on 12 links to put together one answer?

Frustrated,
ctm

So many wizards, so few results.

[Brad_Peterson]

Heh, you're NOT alone. I've wanted documentation that includes many code examples and update approaches for a long long time. Unfortunately, I've had to figure out the updating process through months of trial and error. I've learned a great deal along the way, but I sure wish I had someone else I could have chatted with before I started.

Your best bet is to probably just ask us what update service plan you have (the free Starter edition? Or the paid version?), the installer you use, what update scenario you plan on doing, and how often you plan on updating. From there, we can get a better idea of a solution for you.

To answer your current question, to target just system admins, I would simply have the Update Service look for a special registery setting that only the sysadmins would have. That way, only they would see that particular update. That way, it's as simple as creating a registry setting on their machine, and putting that condition in that particular update. If you need mor details, just ask.

[cterpm]

First, I want to apologize for the snippy tone of my original post. My fingers got ahead of my brain.

Here's an overview of what I need to do: I am using IS 11 with an Installscript (non-MSI) install. I have a relatively small base of users (under 1000), of which many are single users; the multi-user situations have anywhere from 2 to 30 users. I will be updating on a regular basis, and all sites (at least for now) will need all updates. Generally, only a handful of files will be updated. When I build my installation, it tells me that the install has been update-service enabled. There is no special code in my install or my exe related to the update.

So my question is:

How do I target the single users and the sys admins? Brad recommends that I make a registry key to flag the admins; unfortunately my product is already deployed and there is no such key made. However, I do have a setting in a config file that tells me if a user is an admin for my product.

Still frustrated but calmer,
ctm

[KellyF]

cterpm wrote:
If I want to target just system admins, what am I supposed to do?

I like Brad's idea of registry (or even a file) to distinguish a system admin. You could even set a profile item and use it to help you decide when you're dealing with a SysAdmin's machine. One note though, the update service agent can help you by using conditions, but you'll still need to have some way of marking the machine as belonging to a system admin in the first place.

Why aren't there some easy to follow examples anywhere?

We've asked that question as well, but sometimes it's difficult to push back against the tide of those who feel that the product should have features x, y, z. Given our typical aggressive schedule, we typically don't have much time to write the comprehensive examples that some would like to see. I always recommend that persons send feedback via the website as that will go to the management persons who make the decisions, but do not frequent this site.

Why does it say "Click on any [question mark] icon to get help on that field," but nothing happens when you click? Why does the help file require that you click on 12 links to put together one answer?

Well, the "click" icons should launch javascript to send a description to the left-hand side of the page. So please verify that you have javascript enabled (and are using IE or FireFox which are the browsers we do most testing with.... I've seen things not work right when I used Opera)

The online help system is something else. I believe that they are moving to a new system, but I do not have any timetable or knowledge of what they're going to.

Regards,
Kelly

[KellyF]

Figures.... just as I'm sending off my last reply, I see this new one... :rolleyes:

Given that your items are out there, I suggest that you create an update which will execute some vbscript. That script can then read your config file and decide whether you've got an admin or not. You can then write that info to a registry key if desired, or a Profile item. Either of those can then be used as conditions in future updates. Alternatively, if your config file is in classic .INI file format, you could place conditions on the section/key value from your file.

I can dig around for a code sample, but you can probably also find a code snippet on various websites. Also note, the update doesn't necessarily need to send a file, but would need some way to indicate that it's been "updated" and shouldn't run again. (Hence a condition on it for a lack of a registry key or lack of a profile to let it be run)

Regards,
Kelly

[Brad_Peterson]

cterpm wrote:
First, I want to apologize for the snippy tone of my original post. My fingers got ahead of my brain.

Here's an overview of what I need to do: I am using IS 11 with an Installscript (non-MSI) install. I have a relatively small base of users (under 1000), of which many are single users; the multi-user situations have anywhere from 2 to 30 users. I will be updating on a regular basis, and all sites (at least for now) will need all updates. Generally, only a handful of files will be updated. When I build my installation, it tells me that the install has been update-service enabled. There is no special code in my install or my exe related to the update.

So my question is:

How do I target the single users and the sys admins? Brad recommends that I make a registry key to flag the admins; unfortunately my product is already deployed and there is no such key made. However, I do have a setting in a config file that tells me if a user is an admin for my product.

Still frustrated but calmer,
ctm

Oh, you didn't any code yet in your compiled application to handle updates? Ooh, that gets a lot trickier now. If I'm guessing right, you had assumed that by making an installer with InstallShield and having some portion of the installer say it's Update Service enabled, that you will be able to update that install freely.

Unfortunately, that is probably not the case. It's not that easy (I wish it was, I thought along similar lines too when I started). Instead of explaining what it doesn't do, it's probably better to explain how Update Service works, and then from there you should get an idea of how you can make it work in your system.

Update Service's framework consists of the following:

1) A web page publication system, so you can give it the the logic of what updats are available and how to target them to specific installs.
2) The Update Service server. This server handles checkes to a) let your app or InstallShield's apps send the server the product code. b) Let the server send the client computer what updates are possible so that it can determine what ones actually apply. If your installation and/or application knows the GUIDs necessary to identify your product, you are on the way to having your users' computers talk to Update Service's servers and tell it what product it needs to search for updates for.
3) One or two Update Service applications installed on the users machines that get installed by your installation package. These are applications that help the process of talking to the Update Service server and checking to see what updates are possible on the users machines. These applications include Agent.exe, which works great for checking for updates and having it help the update process along within your application, and Update Manager, which is InstallShield's attempt to make the update process as uniform and quick as possible, as well as freeing you from having to compiling code to handle updates withing your application.
4) Update Service API which you can use in your code. The free version of Update Service doesn't let you have this. The pay version does. And the API is soooo flexible and nice. Like any API, it lets you figure out how you want to code the update process into your application. Remember back in #3 how I mentioned the two Update Service applications? The API needs the agent.exe. Update Manager on the other hand can work without any API calls compiled into your code.
5) Your server. Your server is where you put the files that need to be updated. You then tell the Update Service web page the URL to find a particular update. When the process goes along and something tries to download the update, it simply tries to download whatever data it can get from that URL.
6) Various means of updating the application. MSI installed apps can send out MSI packages which lets you update a bunch of files in one shot, as well as being able to uninstall any new files you've added. With MSI patches, you first create the updated patch as an .exe, then you tell Update Service to tell your apps a new patch is available, and it can download and run that .exe for you. Scripted installs such as InstallScript engines may not have the ability to quickly design patches or updates in .exe formats that your users can double click and run. You may need to write your own .exe patches that do some file copying and updating for you, or you may want to use the API to download files manually and process them manually. Depening on what you pick here, any new files may not get uninstalled.

Now, back to your situation, when you said you enabled Update Service within your application, it simply sounds like your installer has the GUID information in it to allow it to talk to Update Service's servers, and Update Service's servers know about your product and are ready and waiting to receive requests from client machines about any possible updates. However, did you also include the package to install some of the Update Service files on the users computer? If not, then your users' computers have no means of sending the GUIDs and other info to the Update Service servers to see what updates are available. If you did include the package in the install, then it's possible you can use Update Manager to send out some updates.

Now from here, I could explain more, but it's best to hear your response, and then we can help you design a solution you need (such as it being through Update Manager or through coded API, as well as getting Update Service to know that some users are admins and get different updates).

[cterpm]

Thanks, Kelly, for your ideas. At least I have a starting place now.

Regarding the help icons: some of them work and some don't, so I have to think that it's something on your end. Here's an example: Update | Add new update--the help icons work fine. But on Administration | Add new account they do not work.

Which brings up another question: who exactly are these people who have accounts? People within my company, I assume. Is there a place where I build a list of customers?

ctm

[KellyF]

cterpm,

You haven't posted for a bit, so I really don't know what you've included in your installer.

If you included the Program Manager, your customers should be able to run that application ("Program Updates" under Start Menu) and see updates for your product. Given that, you could:
1. Create an update which contains a VBscript which reaches out to your config file and creates a registry key with the values to identify administrators or ordinary users. You would need to condition this update on that registry key not being present otherwise your customers will constantly see this update.
2. Create your updates for admins/non-admins and use that registry key as the defining point for whether it is delivered. Whenever they run Update Manger (or when it was scheduled by them) they'll receive updates.

So if you do not mind the person checking for updates using that Update Manger, then you're set. If you wish them to check for updates any time they run your app, then you'll need to add a bit of code to your application startup. It's not that bad, you'd only call AppUpdate() and let it do the lifting. That piece of code (to check at startup) would require you to send out a patch that includes it.

Finally, that administration tab will allow you to create users in the publisher who could create products, create updates, create messages, run reports, etc. For example, your program manager could have read only access to Products & updates, but read/write access to Messages & reports.

Regards,
Kelly

[cterpm]

Hi,
Sorry -- I've been off buying a house and running around throwing thousands of dollars at complete strangers.

I did not include update mgr in my package. I can certainly do that, but I really just want things to update quietly, without relying on users remembering to check for updates. Right now, our client base is compact enough that I can foist anything I want on them.

Setting aside the admin/non-admin issue for the moment, this is what I want:

A user starts my app. The app looks to see if there is an update. If there is, a little message box pops up, asking if they want to update. The user has the option to automatically update without this annoying little message box. And then, the update happens.

So what do I need to do with my app?

Figuring out the Update Service interface is a whole 'nother issue. As I read things, I do not create a list of users anywhere. How then do I target emails?

As I said at the beginning of this thread, I usually learn software just by glancing it over. But this update service has defeated me.

[Brad_Peterson]

Based on what you've said, here's some things you have already decided on.

1) You don't want Update Manager. That means you'll need to use the pay service of Update Service to do the quieter update you're describing. You'll also need to select the option or options within the Update Service merge module to not include Update Manager in the install. The free version of Update Service (Update Starter Edition) only targets updates via Update Manager.

2) You will need to learn the API. Luckily, it sounds like you don't need it to do that much. If so, you won't need much knowledge of the API. In fact, what language do you use? Many of us have freely shown the code we use to check for updates. It's not that many lines of code. What you've described sounds very common, in fact, I do exactly you've described that you want done.

What you still need to determine is *how* you want to update your application. Do you want to create a patch every 3 months or so, where you decide that if a user has an older version, send them the new patch? Or do you want to target updates on a file by file basis, and you need to be very picky about what users get which files?

Regarding targeted emails, what do you mean by that? Targeted messages to certain users? So admin users can get some messages that normal users don't? If so, this is actually incredibly easy. When you publish a new update/message, you simply put condition on it. For example, my app places registry values to let me decide which user is which. So you would just have admin users have a certain registry value, and then you can have Update Service say "If they have this registry value, send them this message. If not, don't"

Also, don't let Update Service defeat you. Once you understand the 6 items I described in my post before this one, and you have a basic feel for the API, it's all downhill from there.

[Arman_Legend]

Hi there,

I found these posts quite useful for what I'm about to do. It's nature is very similar to what's being discussed here, how ever few thing remain unsolved in my mind.

How are these updates treated once the software is being Uninstalled? Will the new files remain as unknown files to the uninstalling script or they become part of the whole thing and therefore get uninstalled? Furthermore what is the best way of packaging an update? Should it be a patch if say you want to add few new files into the installation directory or maybe change a registery? or its better to just have the whole software packaged again if possible to replace the current installed version?

This part seems to be an important one however not emphasized enough based on what I gather. For every update that you perform, the installation of it is supposed to set a registery flag/key to indicate itself being installed. So when you publish that update on the Update Service Portal, as one of the conditions to show this update you will also check the absence of that registry key. This ensures that once a user installs that update, they will not see it listed again under the list of available updates. Please correct me if I'm wrong!

[Brad_Peterson]

Arman, excellent question.

I wondered the same question for a long time. Here's what I've determined.

1) MSI installers that are updated via MSI patches will uninstall all files added by the installer or by a patch. If you add your own files manually and not through MSI, then the Uninstaller will NOT remove those files, as it doesn't know about them. Again, MSI only removes the files it knows about. It does not delete out the application directory in one shot.

2) Scripted installs I believe give the flexibility to tell the uninstaller to remove the entire application directory. This means you don't have to worry about if the installer knows about the file or not. Killing the an entire directory takes care of that for you.

3) After chatting with an InstallShield technician over this, he mentioned that many apps leave behind many files when the uninstall takes place. After some grumbling, I've gone along with that philosophy too. We're removing many files, but with our scenario, it would take far too much development time to remove a few remaining files in various folders.

[Brad_Peterson]

This part seems to be an important one however not emphasized enough based on what I gather. For every update that you perform, the installation of it is supposed to set a registery flag/key to indicate itself being installed. So when you publish that update on the Update Service Portal, as one of the conditions to show this update you will also check the absence of that registry key. This ensures that once a user installs that update, they will not see it listed again under the list of available updates. Please correct me if I'm wrong!

ISUS does not get involved with updating your main app's version. The installer you used to make a patch is what updates the main app's version. In my case, I have to put a new version number in Install Express X when I create an MSI patch.

When the patch is run, it updates it's own version number.

ISUS only queries this version number for possible use in sending out more updates.

Now, the API gives you flexibility to set conditions to let you manually control this version number checking. For example, perhaps you don't want to rely on your main app's version number, but rather, the main .exe's version number. It's possible to set something like this up.

For me, I'm not using the main app's version number anymore. I actually just insert my own version number in one of the unused fields of an update. My app then grabs that version number, and the application uses that to figure out what updates it should download. It's not the cleanest, but it gets the job done. The only point I'm trying to make here is that there is some flexibility in making sure your users don't see the same update after the app has been updated.

[Arman_Legend]

Thanks for the details in your replies.

If I'm correct your application takes advantage of the API. Therefore programmatically your application checks the current version number and through the API it compares what's available on the ISUS with respect to that version number.

I like to allow the most likable method of updating the software. It appears to me that the APIs for that matter are the most elegant way of doing an update. Could you please further explain about what functionalities are provided through the ISUS APIs?

Thanks.

[Brad_Peterson]

Heh, what you can do with the API?

There are online docs and if you install the Update Service SDK, the docs come with it. You just have to read through and find the API section, then look at all the objects you can create and all the method and properties of them.

Real quickly, here's a run down of some of the basics.

I can tell Update Service the product's GUID. It then can pass back all updates and messages for that GUID. I can then go through each possible update or message one by one, and pick out all the information I've already supplied in that update (such as the description, the URL, the size, command line options, etc.)

There is also an ability for Update Service to do most of this work for you. I can tell it to simply download and process all updates available for my GUID. This function loads a separate window, it downloads the updates, then sends an event to your app letting you know it's downloaded them and is ready to process them. It then attempts to process them (usually, these updates are .exe updates that can run themselves). After the last update has been processed, the function is done, and your app is hopefully updated. If you are technical enough, you can do some post-update callout code as well to further do some processing after the updates are installed. Personally, I just throw that post-update stuff in my .exe patch I've manually created.

[Arman_Legend]

At the moment I'm caught up with a few things which doesn't give me enough time to properly investigate the APIs, so I apologize for asking basic questions.

These APIs are not used by the actual .exe which is shipped out with your Setup.exe, is it? Are they meant to be used by InstallShield or one can just write a quick app (in C++) which uses this APIs?

[Brad_Peterson]

Oh, these API's are definitely shipped with your setup.exe. They are included in the merge module in the setup.exe installer, and you have to compile the API calls in your application.

The API essentially work for both your app and InstallShield. It's like your bridge to comminicate what you want your program to do and what InstallShield is capable of doing. So yes, you can write a quick C++ app which uses the API, and those API calls in turn load up InstallShield objects so that InstallShield can do it's own complex stuff.

[Arman_Legend]

Now I have some ideas. The ISUS merge-module ships the Update Service API with your installation package. You could perhaps make use of the APIs inside your installation package, but how often will this it be run? Maybe twice, once to install and once to uninstall. So it then makes sense call the APIs through your own application for checking on the update status and so on.

Sorry again its too basic, but is this correct?

[Brad_Peterson]

Ya, you don't want the installer or uninstaller doing any auto updating work. It only installed or uninstalls any Update Service related files.

The API calls take place when the application is run. If you want, you can have your installation launch your application on finish, and then that application uses the API to check for new updates. Also, if your Installer allows it, it can also be possible to rebuild a new installer every time you update your app, so when people install your app for the first time, it's already updated to the newest information. That way, you won't need to worry about running an update after the install.

[Arman_Legend]

This whole installshield acquisition by Macrovision is confusing me. Names have changed and the categories are different 😐

It seems a Starter package and a full package are being offered now. They call the full one "FLEXnet Publisher Update Service Module" with which you get the APIs? I'm assuming that you have "FLEXnet Publisher Update Service Module".

I noticed there is an Update Check interval field under EnabledUpdateService field in the IS. Does it schedule the Update Service Agent to automatically check for the updates after so many days or it just has to be configured by a different thing?

Secondly do people normally go by a shortcut to the update service or they include it in their software through the API? Whats more common?

[Brad_Peterson]

I am not aware they changed the merge module names. It seems like your guess sounds right.

As for the InstallShield EnabledUpdateService field. I was confused by that, I never found an answer to it. I think it works hand in hand with the Update Manager? That's my best guess. I ended up simply setting my value to zero.

Finally, what do you mean by a shortcut or in their software? By shortcut, do you mean do people write their own stand alone application to handle auto updates for the other application? Hmm...either way, I wouldn't know what other people use. From what I've heard, most people here use the API, and they bundle that API code directly into the app, and not in some secondary side application. But I wouldn't be surprised in the API is flexible enough to allow either scenario.