Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1743 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.
Parents
  • 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
Reply
  • 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
Children
No Data
Unfiltered HTML