よくある質問

このセクションは、質問と回答を通して BigFix Software Distribution への理解を深めるのに役立ちます。

パッケージの定義は何ですか?: パッケージとはコンテンツのバンドルであり、ソフトウェア配信製品の最も重要な部分です。パッケージには、特定のソフトウェア製品のインストールに必要なファイルのリストが含まれています。このリストには、実際のエンドポイントに製品をインストールするために必要な Fixlet も含まれています。パッケージは、ファイルと Fixlet の間の管理関係を確立します。

アプリケーション管理グループの定義は何ですか?: アプリケーション管理グループは、コンテンツをグループに分け、対象となるクライアント・コンピューターのグループに配信できるタスクの集合です。これらのタスクは、BigFix のクライアントにはオファーとして表示されます。

ソフトウェア配信での MST の役割は何ですか?: Microsoft の変換ファイル (MST) は、Microsoft インストーラー・ファイル (MSI) のサブファイルです。変換ファイルは、製品の言語、ライセンス・キー、コンポーネントの選択などのインストール・オプションを設定またはオーバーライドするために使用されます。ソフトウェア配信の状況下では、「配信タスクの作成」ウィザードを使用して、パッケージのタスクを自動的に生成できます。このウィザードは、パッケージに含まれる MST ごとにタスクを作成します。各タスクには .mst ファイルが 1 つずつ含まれています。
注: 1つのタスクに複数の .mst ファイルを適用する場合は、ウィザードでインストール・コマンドを入力する必要があります。
注: 別のタスクを使用して異なる MST を適用することはできますが、1つのソフトウェア配信タスクに適用できる MST は 1 つのみです。

「Fixlet の作成」ウィザードから Fixlet を作成しました。なぜ機能しないのでしょうか?: 一般的な Fixlet オーサリング・サポートについては、BigFix サポート Web サイトの「Fixlet オーサリング」サポート・ページを参照してください。

現在のユーザー・モードで Fixlet を作成し、それをエンドポイントにデプロイしました。なぜエンドポイントにインストールされないのでしょうか?: このソフトウェアをインストールするには、ログイン・ユーザーに管理者権限が必要です。

Fixlet を作成するためにルート・ディレクトリーにインストール・ファイルが必要なのは、なぜですか?: ソフトウェア配信パッケージの構成については、BigFix サポート Web サイトの技術情報を参照してください。

エンドポイントにインストールされているパッケージのリストを見つけることができますか?: BigFix はソフトウェアを新しい形式で再パッケージ化しないため、ベンダーが指定したタグ (パッケージ GUID など) を使用します。これらの属性は、多くの共通パッケージ・システムの BigFix インベントリーにすでに収集されています。または、分析を使用して、ソフトウェアの一部がインストールされていることを示す属性を識別することもできます。BigFix SAM スキャナーはこの点において有用です。

パッケージの作成には、どのような推奨事項がありますか?: ソフトウェア配信パッケージの構成については、BigFix サポート Web サイトの技術情報を参照してください。

ソフトウェアをデプロイしても、そのコンピューターがまだパッケージに関連しているのはなぜですか?: 自動生成された Fixlet 関連度は、共通パッケージ特性をサポートするために一般化されています。ソフトウェア・デプロイメント Fixlet の適用可能な関連度をさらにカスタマイズするには、「配信タスクの作成」ダイアログまたは「配信タスクの編集」ダイアログのいずれかで、「以下の適用可能条件で対象を絞り込む」を使用します。

ソフトウェア・パッケージに setup.exe と .msi が含まれている場合はどうすればいいですか?: これは、インストールするソフトウェアのタイプによって異なります。該当するソフトウェア・ベンダーに推奨事項を確認してください。

相対パスとは何ですか?: 相対パスの概念は、パッケージにファイルを追加するときに使われることがあります。たとえば、この機能を使用して、MSI 変換ファイルを既存のパッケージに追加し、サブフォルダーに入れることができます。このパッケージに基づくオープンなアクションは、新規ファイルを利用する前に再作成する必要があります。詳しくは、BigFix サポート Web サイトの関連する技術情報を参照してください。

別のアクションを追加して、「ソフトウェア配信の管理」ダッシュボードで作成された Fixlet を変更しました。しかし、同じ Fixlet を再度編集すると、追加したアクションが消えています。どういうことでしょうか?: 「ソフトウェア配信の管理」ダッシュボードは、Fixlet ごとに 1 つのアクションのみをサポートし、別のアクションが検出されると削除します。別のアクションが必要な場合は、同じパッケージに別の Fixlet を作成することを検討してください。

複数のインストールを 1 つのパッケージにバンドルする方法とは?: このプラクティスは推奨されません。代わりに、個別の Fixlets を作成し、ベースラインを使用して順序付けを指定します。詳しくは、「ベスト・プラクティス」セクションを参照してください。

BigFix コンソールを使用するシステムは、BigFix サーバーと通信する場合を除き、プロキシーを経由するようにセットアップされています。「ソフトウェア配信の管理」ダッシュボードを使用してファイルをアップロードする際にも、そのプロキシーを経由することに気が付きました。プロキシーを通さない方法はありますか?

アップロード・マネージャー (アップロードを行うツール) が、プロキシー情報のネイティブ Windows 設定をチェックします。ファイルのアップロードでプロキシーを経由しないようにするには、Windows のプロキシー設定でバイパス・リストを設定する必要があります。以下の手順を実行します。

管理者としてコマンド・プロンプトを開きます。
64 ビットの Windows システムの場合は、コマンド・プロンプトから C:\Windows\sysWOW64\netsh.exe を開きます。32 ビットの Windows システムの場合は、C:\Windows\system32\netsh.exe を使用します。
netsh.exe 端末で、「winhttp」と入力して Enter キーを押します。
winhttp 端末で、「set proxy proxy-server="<proxyURL:port>" bypass-list="<IEM-Server-address><other-addresses>;..."」と入力します。
バイパス・リストが更新されたかを確認するには、winhttp 端末に「show proxy」と入力して、バイパス・リスト設定が設定されているかどうかを確認します。

プロキシーの設定について詳しくは、https://technet.microsoft.com/en-us/library/Cc731131%28WS.10%29.aspx でMicrosoft TechNet の資料を参照してください。

自分の SPB タスクが関連しなくなる理由は何ですか?: SPB パッケージ・タイプをデプロイするには、まずエンドポイントの「TCM 用のクライアント・マネージャー」サイトから「SIE のデプロイ」タスクを実行する必要があります。SPB パッケージ・タイプの使用について詳しくは、『サポートされるパッケージ・タイプ』セクションを参照してください。

「アプリケーション管理グループの管理」ダッシュボードに関連付けられているアクションはどれかを、どうすれば確認できますか?: 「アプリケーション管理グループの管理」ダッシュボードを使用して作成されたアクションには、次の形式のタイトルが付いています。SWD AMG Action: title_of_the_originating_task。

アプリケーション管理グループをデプロイするときに、コンピューター・グループが存在することを示すエラーが表示されるのはなぜですか? どうすればよいでしょう。: アプリケーション管理グループをデプロイすると、そのアプリケーション管理グループ用の自動コンピューター・グループが作成されます。停止プロセス中に、コンピューター・グループの削除を要求するダイアログが表示されることがあります。この要求で「キャンセル」をクリックすると、グループは削除されません。次回アプリケーション管理グループをデプロイしようとすると、コンピューター・グループが存在することを示すエラーが表示されます。このエラーを回避するには、コンピューター・グループを削除してから、アプリケーション管理グループを再度デプロイしてください。

アプリケーション管理グループをデプロイしようとしたときに別のエラーが発生した場合は、どうすればよいですか?

アプリケーション管理グループのデプロイ中に問題が発生した場合は、以下の手順を実行します。

アプリケーション管理グループを停止して、「導入されていません」の状態にします。
そのアプリケーション管理グループに対応するコンピューター・グループを削除します。
アプリケーション管理グループを再度デプロイします。

アプリケーション管理グループのアクションがクライアント・ダッシュボードに表示されない理由のはなぜですか?

クライアント・ダッシュボードで問題が発生した場合は、以下のステップを実行します。

クライアントがアプリケーション管理グループのカスタム・サイトをサブスクライブしていることを確認します。
クライアントが、アプリケーション管理グループにリストされているターゲットのうち少なくとも 1 つのメンバーであることを確認します。
カスタム・サイト内に、そのアプリケーション管理グループ用の自動コンピューター・グループがあることを確認します。ない場合は、アプリケーション管理グループを停止し、再度デプロイしてください。
アクションが参照する ID が、カスタム・サイト内の対応するコンピューター・グループの ID と一致していることを確認します。ID が一致しない場合は、以下のステップを実行します。
1. アプリケーション管理グループを停止します。
2. カスタム・サイト内の対応するコンピューター・グループを削除します。
3. アプリケーション管理グループを再度デプロイします。
元のタスクがクライアントに関連していることを確認します。

デプロイ済みのアプリケーション管理グループで、コンピューター・グループをターゲットから削除しました。その後、アプリケーション管理グループを再同期しました。このアプリケーション管理グループのアクションが、削除されたコンピューター・グループのコンピューターにまだ関連しているのはなぜですか?: 再同期時に、アプリケーション管理グループの既存の自動コンピューター・グループは、コンピューター・グループ・ターゲットの新しいリストで更新されます。コンピューター・グループの情報が更新される前にクライアントがアクションを受信することがあります。この問題を回避するには、デプロイ済みアプリケーション管理グループからコンピューター・グループが削除されるたびに、アプリケーション管理グループを停止してデプロイしなおします。

「ソフトウェア配信の管理」ダッシュボードのデバッグ・ログはどこにありますか?

次のステップに従って、ダッシュボードのデバッグ・モードをオンにします。

「ソフトウェア配信の管理」ダッシュボードをクリックし、ALT + CTRL + SHIFT + D を押します。「デバッグ設定」ウィンドウが開きます。
「診断パネル内の関数呼び出しの追跡」チェック・ボックスを選択します。
「ログ設定」セクションで、デバッグに含めるようにレベルのスライダーを動かします。
「デバッグ設定」ウィンドウを閉じます。
Ctrl + F5 を押して、ダッシュボードを再ロードします。
エラー・メッセージが表示されたら、再度 Alt + Ctrl + Shift + D を押します。
「ダッシュボード・ログを表示」をクリックします。

マスター・オペレーターのアプリケーション管理グループに関連するアクションが重複していることがわかります。どうすればよいでしょう。

以下の手順を実行します。

「アプリケーション管理グループの管理」ダッシュボードで、設定アイコンをクリックします。
「AMG アクション・キャッシュの消去」をクリックします。

注: マスター・オペレーターがソフトウェア配信サイト・バージョン 35 よりも前にアプリケーション管理グループをデプロイした場合は、キャッシュをクリアする必要があります。

ソフトウェア配信タスクを削除しましたが、C:\Program Files\BigFix Enterprise\BES Server\wwwrootbes\Uploads のフォルダーに保管されている SHA1 フォルダー内のパッケージが自動的に削除されません。なぜですか? また、どうするべきですか?

「ソフトウェア配信」ウィザードを使用してタスクを作成した場合、自動クリーンアップは行われません。ウィザードはこのような仕様になっています。リポジトリーのファイルまたはフォルダーを手動で検索、削除する必要があります。ペイロードのクリーンアップは、すべて手動で行う必要があります。ソフトウェア配信タスクを作成するには、「ソフトウェア配信」ウィザードではなく「ソフトウェア配信の管理」ダッシュボードを使用することをお勧めします。

「ソフトウェア配信の管理」ダッシュボードを使用してタスクを作成したにもかかわらず、タスクの削除時にそのパッケージが自動的に削除されない場合は、以下のことを確認してください。

ソフトウェア配信パッケージからファイルを削除した
ファイルを参照するすべてのタスクを削除した
ファイルを参照するすべてのオープンなアクションを停止した

これらの対策のいずれも実行しなかった場合、ファイルと sha1 フォルダーは残ります。

Mac エンドポイントへの .pkg ファイルのインストールは成功しましたが、タスクが関連したままです。なぜでしょうか? ソフトウェアのインストールが本当に成功したかをどうすれば確認できますか?: エンドポイントに Mac の .pkg ファイルがインストールされているかを確認するインスペクターがまだ利用できないため、このタスクは関連したままになっています。パッケージが正常にデプロイされたかを手動で確認する方法については、『パッケージ・タイプの検証』を参照してください。
注: .pkg ファイルを再インストールしても問題は発生しません。

作成したソフトウェア・パッケージを 1 つの BigFix デプロイメントから別のデプロイメントに簡単に移行できますか?: はい。「ソフトウェア配信の管理」ダッシュボードからソフトウェア・パッケージを簡単にエクスポートおよびインポートできるようになりました。この機能について詳しくは、パッケージのインポートおよびエクスポートを参照してください。

ソフトウェアのデプロイ・アクションの状況が、デプロイされたアプリケーションのインストール状況を正確に反映していないのはなぜですか?: ソフトウェア配信は、多くの場合、ソフトウェアのインストールが成功したかを判別できません。実際のパッケージのインストールに関連する問題は、ソフトウェア配信の制御外にあります。パッケージを実行しても、その実行の結果を追跡することはできません。

Solaris の .pkg ファイルのインストールが失敗する理由は何ですか?: Solarisの .pkg ファイルは、競合が原因で失敗することがあります。デフォルトでは、競合が発生したらインストールを終了します。競合を無視してインストールを続行する場合、アクション・スクリプトを編集してその値を変更できます。conflict、idepend、rdepend の 3 つは、デフォルトで「quit」に設定されています。「quit」を「nocheck」に変更し、タスクを再度実行してください。

プリインストール・コマンドとポストインストール・コマンドを追加しましたが、コマンドが失敗しました。: 構文が正しいことを確認してください。ダッシュボードは、アクション・スクリプト、バッチ・スクリプト、またはシェル・スクリプト・コマンドの妥当性を検査しません。これらのスクリプト・タイプは単なるラッパーであるため、アクション・スクリプトを直接編集する必要はありません。

インポートまたはエクスポートの実行に時間がかかりすぎています。この遅延の原因として何が考えられますか?: サイズが大きく数量が多いパッケージをインポートおよびエクスポートすると、大量のデータが原因で処理に時間がかかる場合があります。ログを調べて、プロセスが実行を停止したかを確認してください。停止していた場合、プロセスを再始動してください。

エクスポートとインポートに失敗する原因として考えられるものはありますか?

エクスポートまたはインポートが失敗した理由を調べるには、<Windows Temp>\SoftwareDistributionLogs\<Export or Import> のコンソール・システムからログを確認します。

考えられる原因は以下のとおりです。

ファイル名または Fixlet の名前が長すぎます。: アップロードされたインストール・ファイルまたは Fixlet のファイル名が 100 文字を超えると、エクスポート・プロセスとインポート・プロセスが失敗する可能性があります。; この問題を修正するには、コンソール内のファイル名または Fixlet の名前を短くしてください。圧縮ファイル内のファイル名の変更は推奨しません。

リソースがロックされています。: この問題は、インポートまたはエクスポート・プロセスが途中で終了した場合に発生します。例としては、エクスポートまたはインポート・プロセスの進行中にダッシュボードを閉じた場合が挙げられます。; この問題を修正するには、BigFix コンソールを再開してコンソール・キャッシュを消去するか、システムを再起動してください。

zip または unzip ユーティリティーのダウンロードができません。: エクスポートとインポートを処理するために、事前にダウンロードされていない場合、ダッシュボードで zip または unzip ユーティリティーをダウンロードする必要があります。ダウンロードに失敗した場合は、構成解除されたプロキシー設定が原因である可能性があります。ダッシュボードは、コンソールの他の部分と同じプロキシーを使用しません。この問題を修正するには、Internet Explorer のインターネットオプションを使用してプロキシー設定を構成します。

パッケージをエクスポートできませんでした。エクスポート・ログに、予期しない HTTP 応答: 404 Not found というエントリーがあります。どうすればよいでしょう。

サーバー上にファイルが見つからなかったため、エクスポートできませんでした。ファイルが BigFix サーバーで削除された場合、またはファイルが元々別のファイル名でアップロードされていた場合、ファイルが欠落している可能性があります。

この問題を修正するには、以下の手順を実行します。

ファイルが事前に以下の場所 <IEM Server directory>/wwwrootbes/Uploads/<sha1 of file> の BigFix サーバーにアップロードされているかを確認します。sha1 フォルダーが存在する場合は、その sha1 フォルダーを削除します。
「ソフトウェア配信の管理」ダッシュボードを更新します。欠落しているファイルの横に X マークが表示されます。変更がダッシュボードに反映されるまでに数分かかる場合があります。
欠落しているファイルを再度アップロードします。

ファイルの URL を指定しましたが、ファイルのダウンロードに失敗しました。どのようにトラブルシューティングすればよいですか?

トラブルシューティングには、以下の 2 つの方法があります。

ファイルの URL が正しいことを確認します。
ブラウザーでファイルをダウンロードできるかを確認します。
Internet Explorer のインターネットオプションでプロキシー設定を確認します。ダッシュボードは、コンソールの他の部分と同じプロキシーを使用しません。
<Windows Temp>\SoftwareDistributionLogs\Downloads にあるダウンロード・ログを確認します。

ソフトウェア配信セルフサービス・ポータルをアンインストールする方法を教えてください。

ソフトウェア配信セルフサービス・ポータルをアンインストールするには、ソフトウェア配信サイトから以下の Fixlet をデプロイします。

Fixlet 146: モバイル・デバイス管理用のセルフサービス・ポータルの削除: セルフ・サービス・ポータルを完全にアンインストールするには、この Fixlet を使用します。ポータルを削除すると、ユーザーはセルフ・サービス・ポータルを使用して自分のコンピューターとモバイル・デバイスを表示および管理することができなくなります。