Use o System Center Configuration Manager 2012 para remover o InstallShield App existente

4

Estou tentando usar o System Center Configuration Manager 2012 para atualizar um programa existente instalado na maioria dos nossos computadores. O programa usa um instalador do InstallShield. Nós somos novos no SCCM aqui, e este programa existe desde muito antes de termos o SCCM disponível.

A nova versão do programa e do instalador não possui nada que eu possa encontrar para detectar ou remover versões antigas. Se você acabou de executar o novo instalador sem remover a versão antiga do programa, as coisas parecem bem por um tempo, mas eventualmente você começa a encontrar coisas que não estão certas. O fornecedor recomenda remover manualmente a versão antiga antes de instalar o novo.

Já posso usar o SCCM para implantar a nova versão em uma estação de trabalho limpa. No entanto, neste momento, não estou conseguindo remover com êxito a versão antiga.

Depois de fazer muita pesquisa, cheguei ao ponto em que gravei um arquivo de resposta para o InstallShield. Eu usei um arquivo MSI fictício para criar um modelo de instalação para o programa antigo. Então eu editei as propriedades de detecção no SCCM para encontrar com precisão o programa antigo. Mudei o programa de instalação para um comando fictício que acabou de sair e procurei o comando de desinstalação do programa no registro do Windows.

Neste ponto, se eu criar uma implantação de desinstalação do SCCM para este aplicativo fictício, ele detectará corretamente se o programa está ou não instalado. O Centro de Software nas minhas estações de trabalho mostrará se ele está instalado ou não, e a porcentagem de conclusão mostrada no SCCM é precisa. Também posso fazer com que o desinstalador execute scripts arbitrários, desde que o script inteiro caiba no campo Uninstall program: na guia Programas do tipo de implantação do SCCM para esse aplicativo. Só preciso incluir o script comando com algo como cmd /d /c"command goes here" .

Se eu editar o comando de desinstalação do programa para não precisar de aspas e colocá-lo dentro dessa sintaxe de comando, posso ver no Process Explorer que o desinstalador é iniciado, mas está oculto em uma área de trabalho privada da conta do sistema local. onde ele vai esperar por entrada que nunca vem. Parece que preciso contar sobre o arquivo de resposta para concluir a instalação. No entanto, isso apresenta dois problemas.

O primeiro problema é se não usar a sintaxe cmd /d /c"..." , não consigo ver que o programa de desinstalação é iniciado, mas se eu usar a sintaxe não posso incluir o arquivo de resposta, porque ele deve ser fechado com aspas. Não tenho como escapar das citações no programa Desinstalar: campo que preciso usar.

Mesmo que eu resolva esse problema, agora preciso saber como enviar o arquivo de resposta para sistemas individuais. Pelo que vi, não posso usar um compartilhamento de rede para isso, porque o desinstalador será executado como uma conta de sistema local que não terá permissões para nenhum recurso de rede. Se eu pudesse simplesmente enviar arquivos aleatórios para os computadores, eu também poderia enviar um script de desinstalação mais complicado ... mas isso também deixaria os artefatos que ainda precisam ser removidos.

Eu já passei muito tempo com isso e parece estar correndo em uma parede de tijolos. O InstallShield e o SCCM são amplamente utilizados. Certamente não é tão difícil assim? O que estou perdendo?

    
por Joel Coel 23.07.2015 / 00:24

2 respostas

2

I can also get the uninstaller to run arbitrary scripts, as long as the entire script fits in the Uninstall program: field on the Programs tab of the SCCM deployment type for that application. I just have to enclose the command with something like cmd /d /c"command goes here".

Padronizei arquivos em lote para hospedar os comandos para executar (des) instalação. Portanto, o campo "Instalar programa" lê Install-Application.bat . Isso me permite testar o processo de (des) instalação totalmente separado do SCCM, simplesmente executando o arquivo de lote. Então, quando isso estiver funcionando, posso usar o SCCM para executar esse arquivo em lote com a confiança de que ele será executado da mesma maneira que eu já testei (supondo que você testou no mesmo contexto que o SCCM usa). Os arquivos em lote são distribuídos junto com os outros arquivos que compõem o conteúdo desse aplicativo.

now I need to know how to push the answer file out to individual systems. From what I've seen, I can't use a network share for this, because the uninstaller will run as local system account that won't have permissions for any network resources. If I could just push random files to computers, I could also push a more complicated uninstall script... but that would also leave artifacts that I still need a way to remove.

O SCCM cuida da distribuição de conteúdo (incluindo cache e limpeza) para você. Faz um bom trabalho disso. Eu acho que você pode estar perdendo o conceito de conteúdo e distribuição para aplicativos SCCM. O SCCM administrará a distribuição do conteúdo de qualquer pasta UNC que você colocar no campo "Local de Conteúdo" para todos os clientes que precisarem. Eu encontrei isso para trabalhar de forma confiável e automagicamente. Minhas pastas de conteúdo geralmente incluem arquivos em lote, instaladores, scripts powershell, arquivos XML, arquivos .msp e quaisquer outras armadilhas de um processo de instalação autônoma.

Surely it's not this hard? What am I missing?

É tão difícil. Ou pelo menos muitas vezes é. Pode valer a pena afirmar que o SCCM não ajuda na instalação e desinstalação do software. O SCCM realmente lida apenas com distribuição de software (e faz um bom trabalho com isso). O SCCM depende inteiramente de instaladores e desinstaladores pré-construídos para executar essas tarefas. O SCCM não pode ajudá-lo se você ainda não tiver um (des) instalador que funcione do jeito que você deseja. Geralmente, a dor resulta (para cerca de 60% dos instaladores que vejo) de alguma combinação dos seguintes:

  • (des) instaladores que exigem interação do usuário quando você realmente quer que eles sejam executados de forma autônoma (que não é uma maneira fácil de superar para aplicativos nativos)
  • (des) instaladores que são instalados para um único usuário, mas precisam de privilégios elevados (que não é uma maneira prática de automatizar)
  • (des) instaladores que pretendem instalar para um único usuário, mas na verdade são instalados para o sistema ou vice-versa

Alguns desses problemas podem ser superados pelo App-V (mas isso não ajudará a desinstalar o aplicativo nativo existente). Por melhor que eu saiba, no entanto, existem alguns aplicativos cuja instalação e desinstalação simplesmente não podem ser confiavelmente automatizadas.

    
por 23.07.2015 / 06:06
1

Estas são situações difíceis. Alguns aplicativos installsheild são muito mal construídos e só serão executados no contexto User, mas se um usuário não for um administrador local, o processo nunca funcionará. Você pode tentar reclamar para os fornecedores de novos aplicativos.

Para aplicativos existentes, você pode testar seus scripts de desinstalação da mesma maneira que o Gerenciador de Configurações os executa. Obtenha o psexec em um computador em um prompt de comando administrativo e digite c:\temp\psexec.exe -s -i cmd . O -s é para o sistema, o -i é para o Interactive e o cmd é o processo para iniciar no contexto do sistema. Na nova janela do System cmd, digite os comandos que você está tentando executar e veja se eles realmente funcionam. Se eles não funcionarem, você não poderá usar o CM para executar esses comandos (pelo menos não no contexto do sistema).

    
por 25.07.2015 / 02:21