System Center Configuration Manager 2012を使用して、既存のInstallShieldアプリを削除します
System Center Configuration Manager 2012を使用して、ほとんどのコンピューターにインストールされている既存のプログラムをアップグレードしようとしています。プログラムはInstallShieldインストーラーを使用します。ここではSCCMを初めて使用します。このプログラムは、SCCMが利用可能になるずっと前から存在しています。
新しいバージョンのプログラムとインストーラーには、古いバージョンを検出または削除するために見つけることができるものが組み込まれていません。古いバージョンのプログラムを削除せずに新しいインストーラーを実行した場合、しばらくは問題ないように見えますが、最終的には正しくないものを見つけ始めます。ベンダーは、新しいバージョンをインストールする前に、古いバージョンを手動で削除することをお勧めします。
すでにSCCMを使用して、新しいバージョンをクリーンなワークステーションに展開できます。ただし、現時点では、古いバージョンを正常に削除することはできません。
多くの調査を行った後、InstallShieldの応答ファイルを記録するところまで来ました。ダミーのMSIファイルを使用して、古いプログラムのインストールテンプレートを作成しました。次に、SCCMの検出プロパティを編集して、古いプログラムを正確に見つけました。インストールプログラムを終了するだけのダミーコマンドに変更し、Windowsでプログラムのアンインストールコマンドを検索しました。レジストリ。
この時点で、このダミーアプリケーションのSCCMからアンインストール展開を作成すると、プログラムがインストールされているかどうかが正しく検出されます。ワークステーションのSoftware Centerに、インストールされているかどうかが表示されます。 SCCM）に示されている完了率は正確です。スクリプト全体がUninstall program:フィールドに収まる限り、アンインストーラーに任意のスクリプトを実行させることもできます SCCMそのアプリケーションの展開の種類。の[プログラム]タブで、コマンドをcmd /d /c"command goes here"のようなもので囲む必要があります。
プログラムのアンインストールコマンドを編集して引用符を必要とせず、そのコマンド構文内に配置すると、Process Explorerでアンインストーラーが起動することがわかりますが、ローカルシステムアカウントのプライベートデスクトップに非表示になっています。決して来ない入力を待ちます。インストールを完了するには、応答ファイルについて説明する必要があるようです。ただし、これには2つの問題があります。
最初の問題は、cmd /d /c"..."構文を使用しない場合、アンインストールプログラムがまったく起動しないことですが、構文を使用すると、引用符で囲む必要があるため、応答ファイルを含めることができません。使用する必要のあるUninstallprogram：フィールドの引用符をエスケープする方法はありません。
この問題を回避できたとしても、応答ファイルを個々のシステムにプッシュする方法を知る必要があります。私が見たところ、アンインストーラーはネットワークリソースへのアクセス許可を持たないローカルシステムアカウントとして実行されるため、これにネットワーク共有を使用することはできません。ランダムなファイルをコンピューターにプッシュすることができれば、より複雑なアンインストールスクリプトをプッシュすることもできます...しかし、それでもアーティファクトが残り、削除する方法が必要です。
私はすでにこれにあまりにも多くの時間を費やしていて、レンガの壁にぶつかっているようです。 InstallShieldとSCCMはどちらも広く使用されています。確かにそれほど難しくはありませんか？何が欠けていますか？
スクリプト全体がそのアプリケーションのSCCM展開タイプ）の[プログラム]タブの[プログラムのアンインストール：]フィールドに収まる限り、アンインストーラーに任意のスクリプトを実行させることもできます。コマンドをcmd/d/c "command goinghere"のように囲みます。
（アン）インストールを実行するコマンドをホストするために、バッチファイルを標準化しました。したがって、「プログラムのインストール」フィールドにはInstall-Application.bat。これにより、バッチファイルを実行するだけで、SCCM）とはまったく別の（非）インストールプロセスをテストできます。それが機能している場合は、SCCMすでにテストしたのと同じ方法で実行されることを確信してそのバッチファイルを実行する（SCCMが使用するのと同じコンテキストでテストしたと仮定））バッチファイルは他のファイルと一緒に配布されますそのアプリケーションのコンテンツを構成するファイル。
ここで、応答ファイルを個々のシステムにプッシュする方法を知る必要があります。私が見たところ、アンインストーラーはネットワークリソースへのアクセス許可を持たないローカルシステムアカウントとして実行されるため、これにネットワーク共有を使用することはできません。ランダムなファイルをコンピューターにプッシュすることができれば、より複雑なアンインストールスクリプトをプッシュすることもできます...しかし、それでもアーティファクトが残り、削除する方法が必要です。
SCCMは、コンテンツの配布（キャッシュとクリーンアップを含む）を自動的に処理します。これはうまくいきます。 SCCMアプリケーションのコンテンツと配布の概念が欠落している可能性があると思います。SCCMは、「コンテンツ」に配置したUNCフォルダーのコンテンツの配布を処理します。これを必要とするすべてのクライアントへの[場所]フィールド。これは確実かつ自動的に機能することがわかりました。私のコンテンツフォルダーには通常、バッチファイル、インストーラー、PowerShellスクリプト、XMLファイル、.mspファイル、およびその他の無人インストールプロセスのトラップが含まれます。
確かにこれほど難しいことではありませんか？何が足りないのですか？
こんなに難しいです。または少なくともそれはしばしばです。 SCCMはソフトウェアのインストールとアンインストールには役立ちません。SCCM実際にはソフトウェア配布（およびSCCMは、事前に構築されたインストーラーとアンインストーラーに完全に依存して、これらのタスクを実行します。SCCMは、次の場合は役に立ちません。希望どおりに機能する（アン）インストーラーがまだありません。通常、痛みは次の組み合わせによって発生します（インストーラーの約60％）。
- 本当に無人で実行したいときにユーザーの操作を必要とする（非）インストーラー（ネイティブアプリケーションで克服する簡単な方法はありません）
- 単一のユーザー用にインストールするが、昇格された特権を必要とする（非）インストーラー（自動化する実用的な方法はありません）
- 単一ユーザー用にインストールすることを目的としているが、実際にはシステム用にインストールする、またはその逆の（非）インストーラー
これらの問題のいくつかはApp-Vで克服できます（ただし、既存のネイティブアプリケーションをアンインストールするのに役立ちません）。ただし、私が知る限り、インストールとアンインストールを確実に自動化できないアプリケーションがいくつかあります。
これらは厳しい状況です。一部のinstallsheildアプリは非常に貧弱に構築されており、ユーザーコンテキストでのみ実行されますが、ユーザーがローカル管理者でない場合、プロセスは機能しません。新しいアプリについてベンダーに文句を言ってみてください。
既存のアプリの場合、ConfigurationManagerが実行するのと同じ方法でアンインストールスクリプトをテストできます。コンピューターの管理コマンドプロンプトで psexec を取得し、c:\temp\psexec.exe -s -i cmdと入力します。 -sはシステム用、-iはインタラクティブ用、cmdはシステムコンテキストで起動するプロセスです。新しいシステムコマンドウィンドウで、実行しようとしているコマンドを入力し、それらが実際に機能するかどうかを確認します。 それらが機能しない場合、CMを使用してこれらのコマンドを実行することはできません（少なくともシステムコンテキストでは）。