Windows OSでの無人インストール用にアプリケーションのインストールを準備する機能

システム管理者は、複数のPCでアプリケーションをインストールまたは更新するタスクに直面することがあります。 多くの場合、問題は配信システムと自動インストールの選択ではありません-組み込みのWindows OS（Active Directory）からMS SCCM、Enteo NetInstall、LanDesk Management Suite、HP Application Deploymentなどの本格的な構成管理システムに至るまで、あらゆる好みに合わせて多数ありますマネージャー、IBM Tivoli Provisioning Manager、ManageEngine Desktop Centralなど



多くの場合、問題は、メーカーが提供するアプリケーションのインストールが無人モードでのインストールに必ずしも適合しないことです。 ネットワーク上で、自動インストールのために特定のアプリケーションを準備する方法に関する推奨事項を見つけることができます。 説明された推奨事項は、ソフトウェアの特定のバージョンで機能するが、次のバージョンでは機能しない場合があります。または、WiXインストーラーまたはその他のフリーウェアツールを使用してインストールをリエンジニアリングし、msiパッケージを作成するためにかなりの時間がかかります。 このような状況では、システム管理者は「タンバリンと踊る」ことを繰り返し繰り返し、無秩序なアプリケーションを無人モードでシームレスにインストールしようとします。



残念ながら、ネットワークへの自動インストールのためにアプリケーションを準備するための一般的なアプローチと推奨事項の説明は事実上ありません。



この記事では、このギャップを埋め、 Infopulseプロジェクトで使用される無人インストールを準備するためのベストプラクティスについて説明します。



アプリケーションの自動インストールの準備では、アプリケーションが人によってではなく、自動モードで動作する特別な製品またはOS機能によってインストールされるという事実に関連する次の機能を検討する価値があります。

1. アプリケーションは、アプリケーションが起動されるユーザーアカウント以外のアカウントでインストールされます。 たとえば、％USERPROFILE％をインストールする必要があるファイルがないとアプリケーションが機能しない場合、％USERPROFILEの別のアカウント（多くの場合ローカルシステムアカウント）でアプリケーションがインストールされているため、アプリケーションを起動するユーザーはこのファイルを使用できません％は別のディレクトリを指します。
2. アプリケーションは、アプリケーションが起動されるユーザーアカウントとは異なるアクセス権を持つアカウントでインストールされます。 たとえば、ユーザーがユーザーグループのメンバーであり、PCのローカル管理者（企業でますます使用される）ではない場合、アプリケーションはマシンごとのリソース（HKEY_LOCAL_MACHINE、％ProgramFiles％、％SystemRoot％）にデータを書き込もうとしますWindows XPでは失敗し、アプリケーションでエラーが発生します。 Windows 7の場合、状況ははるかに興味深いです。プロセス（マシンではない特権モードではなく、標準モードで実行）がマシンごとのリソースにデータを書き込もうとすると、仮想ストアにリダイレクトされます。 このようなリダイレクトは確かにキャンセルできますが、Win XPで説明されている状況になります。
3. 無人インストールが発生するアカウントのデスクトップおよびアプリケーションウィンドウには、ユーザーはアクセスできません。 したがって、無人モードでインストールを開始するときに、ユーザーの応答を必要とするモーダルウィンドウの形式でエラーメッセージが表示された場合、ユーザーはデスクトップにこのウィンドウを表示しないため、ユーザーからの応答はありません。 これは通常、ユーザーが夕方にPCをシャットダウンする（またはシステム管理者がプロセスを終了する）ことで終了します。インストールプロセスは終了せず、翌日、サービスデスクはユーザー（またはユーザー！）から「頭痛」を訴えます。

自動展開用のインストールを準備するための要件と推奨事項は、上記の機能に従います。

1. アプリケーションがユーザーごとのリソース（HKEY_CURRENT_USERキー、％USERPROFILE％内のファイル）の可用性を必要とし、これらのリソースなしでは機能できない場合、無人インストールでは、新しく作成されたユーザーを含むアプリケーションを実行する各ユーザーにそのようなリソースのインストールを保証する必要があります。
   
   ターミナルサーバーには、この問題を解決するための独自のアプローチとツールがあります。 ワークステーションの場合、 アクティブセットアップ、またはmsiインストール用の自己修復 ショートカットとアドバタイズされたショートカットのいずれかが役立ちます。 ただし、この場合、msiのインストールはMicrosoftの要件に対応する必要があり、したがって、msiテーブルにエラーが発生することはほとんどありません。
   
   Self-Healing and Repairが正常に機能するためには、 msiファイルのエラーを確認し （OrcaまたはInstEd！ツールを使用して実行できます）、msiデータベースのエラーを修正する必要があります。 しかし、大部分の管理者は別の道を歩みます-もちろん、ユーザーアカウントのユーザーごとのリソースを自動的にインストール/更新する機能を失いながら、msiインストールのアドバタイズされたショートカットの作成をキャンセルしようとします（たとえば、 DISABLEADVTSHORTCUTSプロパティを使用 ）。
2. アプリケーションが操作中にマシンごとのリソースにデータを書き込み、ユーザーにローカル管理者権限がない場合、マシンごとのアプリケーションによって変更されたリソースへの書き込み権限がWin XPで作業しているユーザーに設定されていることを確認する必要があります。 Windows 7の場合、UACがオンになっているとき、およびマシンごとのファイルとレジストリを仮想ストアに書き込むリダイレクトモードで、アプリケーションがどのように動作するかを確認する必要があります。 無人インストールのパッケージ（またはスクリプト、cmdファイル）のマシンごとのアプリケーションによって変更されたリソースへの書き込み権限の正確なインストールを含めることをお勧めします。 特定のリソースに対する書き込み権限をポイント設定するためには、subinacl、setacl、seceditツールが適しています。 後者はWindows OSのすべてのバージョンに組み込まれているため望ましいですが、 infファイルを書き込む機能を必要とするため、使用がより困難です。
3. ログファイルにメッセージを出力するオプションと無人/サイレントモードでのインストールオプションが有効になっている場合、exeインストールでエラーメッセージがウィンドウ形式で表示されないことを確認することが重要です。 通常、エラーメッセージは、必要なリソースがない場合、またはインストールされているファイルを更新できない場合に発生します。 したがって、すべてのエラーメッセージがログファイルに保存され、ウィンドウの形式で表示されないようにするには、プログラムの正常なインストールに必要な製品またはレジストリキーを持つファイルを移動/名前変更/削除するなどして、無人インストールのエラーを特にシミュレートする必要があります。 msiインストールの場合、 / qnコマンドラインオプションまたはLIMITUIプロパティを使用して、すべてのユーザーインターフェイスウィンドウを非表示にします。
4. exeインストールプロセスを開始できるOSの強制再起動をキャンセルする価値があります。 まず、このプロセスは、自動的にインストールされるアプリケーションのリストの最後ではない可能性があるためです。 そして次に、この時点で、ユーザーはシステムを操作できます。そのため、システムの予期しない再起動は不快な驚きです。 msiインストールの場合、これはREBOOTプロパティをReallySuppressに設定することで実現されます。
5. インストール後にアプリケーションで追加の構成が必要な場合は、この構成を無人インストールに含める必要があります。 もちろん、未構成のアプリケーションをインストールしてから、その構成方法をユーザーに指示することもできますが、そうすることで、ユーザーがアプリケーションを歪めるリスクを大幅に高めることができます。 もちろん、曲がったアプリケーションは、サポートサービスの作業を複雑にします。ユーザーが増えるほど、ヘルプデスクの生活は難しくなります...
6. 無人インストールが無人アンインストールおよび復元モード（修復）もサポートしていることを確認することが重要です。 無人/サイレントインストールのコマンドラインオプションをサポートするexeインストールを提供する多くのソフトウェアベンダーは、無人/サイレントアンインストールを忘れており、特にソフトウェアを削除するPCの数が数百または数千である場合、特定の問題を引き起こす可能性があります。

自動ソフトウェア更新の品質と安定性はこれに依存するため、無人インストールをテストするプロセスは非常に重要です。 また、PCの数が多いほど、「サプライズ」が発生する可能性が高くなります。 したがって、エラーを防ぐために、可能であれば次のシナリオに従って無人インストールをテストすることをお勧めします。

1. 無人インストール用に準備されたinstall.cmdおよびuninstall.cmdファイル
2. ユーザーが作業する企業OSに可能な限り近い構成のシステム（または仮想マシン）を準備した
3. インストールファイルをinstall.cmdおよびuninstall.cmdとともにローカルディレクトリにコピーします
4. Psexec.exe -i -s <executable>などを使用して、ローカルシステムアカウントでinstall.cmdを実行します。
5. プロセスの完了を待っています
6. ログファイルの分析
7. Usersグループのメンバーである新しいユーザーを作成します
8. このユーザーの下でシステムに入り、アプリケーションを実行します
9. インストールがアプリケーションの自動構成を提供した場合、アプリケーションが正しく構成されていることを確認します。
10. アプリケーションテスト（基本機能）を実行し、ユーザーが使用できる制限内でアプリケーション構成を変更します。
11. アプリケーションを閉じ、再度開き、保存された構成でアプリケーションが起動されたことを確認します。
12. ユーザーのログオフを行い、管理者としてログインします
13. ローカルシステムアカウントでuninstall.cmdを実行します
14. プロセスの完了を待っています
15. ログファイルを分析します（ログファイルがアンインストール用に生成されない場合、これは私たちにとって不快な瞬間です。つまり、無人アンインストール中に発生したエラーを分析することはできません）
16. ユーザーの下に移動し、アプリケーションがアンインストールされていること、アプリケーションへのすべてのリンク（.lnkファイル）が[スタート]メニュー、クイック起動、デスクトップから削除されていることを確認します
17. ％ProgramFiles％にアプリケーションファイルがないことを確認してください

無人インストールの準備とテストに費やす労力と時間の妥当性は、アプリケーションをインストールする予定のPCの数とアプリケーション自体の複雑さに依存することに注意してください。

PCの数が少ない場合、またはアプリケーションが複雑で準備に多くの時間が必要な場合でも、各PCのソフトウェアを手動で更新するのが妥当です。

ただし、PCの数が300から400を超え、定期的に更新する必要があるソフトウェアの数も少なくない場合は、これらの推奨事項に従うことは理にかなっています。