none
Another version of this product is already installed

    Question

  • I am working with a customer to upgrade our product on about 200 servers.  He created a package using SCCM and tested it in his QA environment and it worked properly.  He then tried the deployment to the production environment overnight.  All of them failed but did make some kind of change that now, even when attempting a direct install of the product on the machine, we receive the error "Another version of this product is already installed.  Installation of this version cannot continue.  To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel."

    I'm aware that this error comes from the fact that the product code of the MSI package is the same on the machine as the one we are attempting to install, even though the deployment was unsuccessful.

    The question I have is, is there a way to easily clean this issue up remotely from the machines without having to uninstall each agent, and re-install as the error is suggesting?  Would CCMCLEAN work in this instance?  If so, we can batch that and push to each affected machine.  

    Please throw me some ideas as it will be a very painful and slow process to have to uninstall and re-install every agent, which would have to take place after business hours.

    Thanks in advance. 

    Wednesday, May 01, 2013 7:15 PM

Answers

All replies

  • TOTALLY unsupported but...I'd try ccmclean on one or two and see if that works.


    John Marcum | http://myitforum.com/myitforumwp/author/johnmarcum/

    Wednesday, May 01, 2013 8:21 PM
  • Wait....

    why would ccmclean help, if the problem is not with the ConfigMgr agent, it's a problem with "unnamed software product"??

    if the installer database on the client machine thinks that "unnamed software product" is already installed, you need to address that, not perform some kind of repair on the ConfigMgr agent?

    or have I missed the point here?


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, May 01, 2013 8:57 PM
  • ccmclean is for uninstalling the ConfigMgr client agent completely and erasing all traces of it from a system; it has nothing to do with application installations or registrations within Windows.

    The problem here has nothing to do with ConfigMgr, it's because the product you are installing is already installed. You need to troubleshoot/research that.


    Jason | http://blog.configmgrftw.com

    Wednesday, May 01, 2013 9:07 PM
  • ccmclean is for uninstalling the ConfigMgr client agent completely and erasing all traces of it from a system; it has nothing to do with application installations or registrations within Windows.

    The problem here has nothing to do with ConfigMgr, it's because the product you are installing is already installed. You need to troubleshoot/research that.


    Jason | http://blog.configmgrftw.com


    I muat have totally misunderstood the OP. I thought the error was when installing the CM client. Is that wrong?

    John Marcum | http://myitforum.com/myitforumwp/author/johnmarcum/

    Wednesday, May 01, 2013 10:58 PM
  • Ok, that answers the ccmclean question.  The overall question is how to fix the issue that was caused by a failed deployment of the application (Evault agent) but left the systems in a state where we cannot remotely deploy nor can we even install/upgrade directly on the machine without getting that error.  Obviously we could do the error suggestion to uninstall/re-install but we would like to avoid the extensive time and effort that would cause.

    Is there an easy way to clean up whatever SCCM left behind on these systems so that we can at least perform our upgrades either directly installing or using PSEXEC?

    Thursday, May 02, 2013 1:26 AM
  • How about this? http://technet.microsoft.com/en-us/magazine/2008.08.utilityspotlight.aspx


    John Marcum | http://myitforum.com/myitforumwp/author/johnmarcum/

    • Marked as answer by chewybaca96 Thursday, May 02, 2013 6:07 PM
    Thursday, May 02, 2013 12:21 PM
  • As mentioned, ConfigMgr is not responsible for what's going on -- the message you are seeing is from Windows Installer and is simply being relayed by ConfigMgr. All ConfigMgr does (and can do) is run a command-line; what that command-line does is outside the scope of control of ConfigMgr.

    Thus, you need to determine why the evault installer is having issues. As mentioned, based on the error message, evault is already installed and the installer doesn't know how to proceed.


    Jason | http://blog.configmgrftw.com

    Thursday, May 02, 2013 12:54 PM
  • Hi chewybaca,

    How about creating two programs, one for uninstallation of the existing product and the other for the new installation. I understood that both the versions are using the same product code and cannot run the installation/upgrade directly.

    Try adding the uninstallation program as "Run another program first" option on the Create Program window. Thus there will be a single advertisement and not much a time consuming task.

    Check this on a test machines and see if that helps..


    Rajeesh M | My Tech Blog: ScorpITs | LinkedIn Please take a moment to “Mark as Answer” and/or “Vote as Helpful” on the post that helps you. This helps other community members reading the thread and recognises useful contributions. Thanks!

    Thursday, May 02, 2013 1:38 PM
  • John,

    This is what I was looking at yesterday and I believe it is going to be the best solution.  We are in progress of testing this and I will post back results.  Thanks for the info.

    Thursday, May 02, 2013 3:45 PM
  • How about this? http://technet.microsoft.com/en-us/magazine/2008.08.utilityspotlight.aspx


    John Marcum | http://myitforum.com/myitforumwp/author/johnmarcum/

    The cleanup utility did work to get around the initial issue.  We had some snags after that but it took care of the problem that SCCM caused to put the servers in the stuck state they were in.

    Thanks.

    Thursday, May 02, 2013 7:11 PM
  • Just to state it again, this problem was in no way, shape or form cause by ConfigMgr. All ConfigMgr can ever do is run the command-line you give it. If the command-line you give it is incorrect or causes other than expected behavior, then the issue is caused by your command-line or your expectations.


    Jason | http://blog.configmgrftw.com

    Thursday, May 02, 2013 7:33 PM