Will True Update Work For Me?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • NitLions
    Forum Member
    • Jan 2007
    • 176

    Will True Update Work For Me?

    I've just downloaded a True Update evaluation and I'm starting to go through the User's Guide, but before I get too involved I thought I'd ask a question or two.

    First, let me give you the background of our current application update automation.

    First, we have a 'Server' install which places client install files (.msi's) in a folder that is later used as a Network share. Initially, the clients will browse to this location for initial installation, but this location is later used for update detection and installation.

    Basically, we write version information during initial install to .ini files both on the server (in the network share during the 'Server' install) and client sides.

    Upon network logon on the client, an update utility runs that basically compares the versions contained in the .ini files and initiates the installs located in the network share if deemed necessary. Like I said, it basically installs/updates our client side application and a third party document viewing application in this manner.

    Our main problems with this method stem from user privileges (I believe) in that the user actually using the app isn't the installing user at time of upgrade. I don't think there is anything True Update can do about this as this seems to be a 'shortcoming' of the installs themselves. Since we write to system/protected areas in both the file system and the registry, we basically require Admin rights to install (Power Users acceptable in pre-Vista).

    Anyway, I'm wondering if True Update can imitate and/or improve our current process(es). Can it be used in the context of differing end user network shares? In other words, is there any way that we could use True Update to function from a network share without really knowing what the share will be ahead of time? Or would we have to standardize a share naming convention such as \\machinename\directoryname? Is there any way to prompt for the share during the initial run of True Update, maybe? In our situation, would True Update be more suited for a network deployment of updates/patches, etc from our company website/ftp, etc?

    I'm guessing we would set up our update scheme in True Update then deploy with our product, which will then be used thereafter. ??

    I'm sure that some things will become clearer after reading the manual, but I'm also wondering if I would just be reinventing the wheel, in our case, since it seems that the process I'm aiming for basically occurs with our current utility.

    I guess I'm just rambling at this point so any comments, further questions regarding current processes, help, points to information would be more than welcomed!

  • NitLions
    Forum Member
    • Jan 2007
    • 176

    #2
    After looking into this a bit more, I see the scripting part of it is or seems to be the same as Auto Play for the most part so I am somewhat familiar to this scripting approach (though by no means an expert).

    For my earlier question regarding not knowing the network share ahead of time, we do write this to the client side .ini ahead of time so I guess I could grab that value at the beginning of my script then set where needed elsewhere in the script. ???

    So, the .ini on the Server side (holding the latest version) is on the 'server' system. The client in need of update has its version and share written in the installing user's appdata area. In which script should I place the search for the share name in the client's .ini file. I guess that would have to be in the Client script since the executable will be running on the Client machine?

    Comment

    • Mark
      Indigo Rose Staff Member
      • Jun 2000
      • 1945

      #3
      Hi NitLions,

      I'm not sure if I understand your update process exactly but I will try to answer your question and give you some advice as best I can.

      The general TrueUpdate model is as follows:
      1. The Client executable starts and the client script which then downloads the server script.
      2. The server script runs and determines if an update is available.
      3. If an update is available it is applied.
      4. If an update is not available the Client executable exits.


      That is just a general model an does not necessarily need to be followed.

      In your case it would probably make sense for the client script to read the share name and the version from the client .ini file.

      At this point what happens next is up to you, in a general TrueUpdate update you would then use the share name to acquire the server script (probably stored in the share). Then the server script would read the new version from the server .ini and compare it with the version that the client script read.

      Then if an update is needed, the server script will perform the necessary tasks.
      MSI Factory The Next Generation Intelligent Setup Builder

      Comment

      Working...
      X