Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1742 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Autoupdate dies when migrating from 7.6.15 to 9.0.2

DetlevRackow

Hi,

we have migrated our Library to 4.0, all clients are running in the new SUM-hierarchy.

I have kept the clients at 7.6.x for the time being to familiarize myself with the new console, and to allow for an easier downgrade if we discovered any problems with the new console.

When I dropped the policy with 9.0.2 to the first groups, I found that some clients will install 9.0.2, but that the AutoUpdate-package will report an error. Afterwards, the client is at 9.0.2, but since Autoupdate is stuck, it will not accept further updates.

The machine's details show that "autoupdate could not be installed: MSI could not be executed" (it's in German, please apologize for any inaccuracies of my translation)

The clients can be repaired remotely. If I force a new installation from the console with "protect computers...", Autoupdate is installed correctly and works just fine.

This has happened on about 25% of the 400 machines to which I have assigned 9.0.2. The clients are XP SP3, fully patched but still on IE7.

Is this an isolated problem of our environment, or has this happened to other installations as well?

I have opened a case some weeks ago, but the support engineer is still waiting for feedback from L2.

Best regards, Detlev Rackow

:589


This thread was automatically locked due to age.
  • 0

    Haven't seen that the MSI for Autoupdate failed (as of now we've migrated 600+ computers). We had (and have) occasonal problems with an installation package where Autoupdate does not process sauconf.xml (or so it seems) and the update location points to a temp directory no longer available. This might or might not be related.

    BTW: found out "by accident" that clients can downgrade to 7.6 without problems (and also re-upgrade afterwards)

    Christian 

    :591
  • 0

    Thanks, Christian, for your feedback.

    Since we don't use XML-configurations in our installation but rely entirely on the management through the EM-console, this is no issue for us.

    The application log shows error 2229 which indicates a Query-Error when reading the table "LaunchCondition" inside the MSI for AutoUpdate. Google-hits indicate a problem with file corruption, but I verified the file from an affected machine with the original ressource and they are identical.

    Best regards,

    Detlev Rackow

    :604
  • 0

    Last update from support: It seems that we seem to use our PCs for too long times ;-)

    The issue can occur when a machine has been protected since version 6 and is installed with non-english regional settings.

    The developers are working on an automated fix. The easiest way around is to reinstall via the "protect"-option on the server.

    Alternatively, it is possible to delete a MST-file from the cache directory of the Windows Installer.

    For our environment, I am right now evaluating a self-written script which will remove the cached MST-file at system startup and which should run via Active Directory-Group policies as a startup script on all machines.

    Best regards, Detlev

    :960
Unfiltered HTML