よくある質問

このセクションは、質問と回答を通して 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 サイトの技術情報を参照してください。

現在サポートされているファイル・タイプは何ですか?: BigFix Software Distribution では、どのようなファイル・タイプであってもデプロイできます。パッケージのインストール・コマンドの自動生成は、.bat、.dmg、.exe、.msi、.msp、.osd、.pkg、.rpm、.spbおよび App-V ファイルでサポートされています。

ソフトウェアをデプロイしても、そのコンピューターがまだパッケージに関連しているのはなぜですか?: 自動生成された 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 よりも前にアプリケーション管理グループをデプロイした場合は、キャッシュをクリアする必要があります。

セルフサービス・ポータルのオファーは、どのように作成すればよいですか?: セルフサービス・ポータルで使用可能になるオファーを作成するには、「ポータルの提案」タスクをアプリケーション管理グループに追加する必要があります。

「ポータルの提案」を含むアプリケーション管理グループをデプロイしました。その後、デプロイメントを停止しました。ソフトウェア・オファーが依然としてセルフサービス・ポータルに表示されているのはなぜですか? この動作は正常ですか?: コンピューターのソフトウェア・オファーのリストは、ユーザーのログイン・セッションごとに 1 回生成されます。このセッションは、ユーザーがポータルにログオンした時間と見なされます。ソフトウェア・リストは、ユーザーがログアウトして再びログインするまで、アプリケーション管理グループのステータスに変更内容を組み込む更新を行いません。

セルフサービス・ポータルとトラステッド・サービス・プロバイダーのログはどこにありますか?: セルフサービス・ポータルおよびトラステッド・サービス・プロバイダーのログ・ファイルは、<path_to_TEM_Server_directory>\MDM Provider\log にあります。デフォルト・パスは C:\Program Files\BigFix Enterprise\Management Extender\MDM Provider\log です。

トラステッド・サービス・プロバイダーのパスワードを変更したら、エンドポイント・ユーザーがセルフサービス・ポータルにログインできなくなりました。どうすればよいでしょう。: <path_to_TEM_Server_directory>\MDM Provider\config にある tsp-config.yaml ファイルのパスワードを更新します。デフォルト・パスは C:\Program Files\BigFix Enterprise\Management Extender\MDM Provider\config です。

セルフサービス・ポータルで問題が発生しました。トラブルシューティングに関する情報はどこで入手できますか?: ポータルに関する情報は、「分析 19: ソフトウェア配信セルフサービス・ポータル」を参照してください。

トラステッド・サービス・プロバイダーとセルフサービス・ポータルが正常に構成されたかを確認する方法はありますか?

トラステッド・サービス・プロバイダーの場合

トラステッド・サービス・プロバイダー診断ページを使用して、トラステッド・サービス・プロバイダーが正常に構成されたかを確認します。
このページでは、SSL 証明書を調べて、LDAP および BigFix への接続を試行します。また、サンプル関連照会の実行も試みます。
トラステッド・サービス・プロバイダーの診断ページの URL 構文は、次のとおりです。 https://<your_host_name>/diagnostics
構成ファイルを確認します。
1. <path_to_TEM_Server_directory>\MDM Provider\config にある tsp-config.yaml ファイルを開きます。デフォルト・パスは C:\Program Files\BigFix Enterprise\Management Extender\MDM Provider\config です。
2. 以下のフィールドのいずれかが欠落している場合は、トラステッド・サービス・プロバイダーを再構成します。
  - :organization_name:
  - :hostname:
  - :ldap_admin_user:
  - :ldap_admin_pass:
  - :wr_path:
  - :wr_user:
  - :wr_pass:
  - :tem_user:
  - :tem_pass:
  - :tem_server:

セルフ・サービス・ポータルの場合

セルフサービス・ポータルの診断ページを使用して、セルフサービス・ポータルが正常に構成されているかを確認します。
このページは、認証登録に必要なトラステッド・サービス・プロバイダーへの接続を検査します。
「セルフサービス・ポータルの診断」ページの URL 構文は、次のとおりです。 https://<your_host_name>/ssp/diagnostics
構成ファイルを確認します。
1. <path_to_TEM_Server_directory>\MDM Provider\config にある ssp-config.yaml ファイルを開きます。デフォルト・パスは C:\Program Files\BigFix Enterprise\Management Extender\MDM Provider\config です。
2. 以下のいずれかのフィールドが欠落している場合は、セルフサービス・ポータルを再構成します。
  - :install_mode:
  - :organization_name:
  - :tsp_host:
  - :tsp_port:
  - :hostname:

セルフサービス・ポータルのポートはどうすれば変更できますか?

セルフサービス・ポータルのポートを変更するには、以下の手順を実行します。

セルフサービス・ポータルをインストールしたボックスで ssp-config.yaml ファイルを変更します。この ssp-config.yaml ファイルは、C:\Program Files (x86)\BigFix Enterprise\Management Extender\MDM Provider\config で確認できます。
セルフサービス・ポータルとして機能するエンドポイントで IBM Endpoint Manager for Mobile Devices サービスを停止します。
ホスト名の ssp-config.yaml ファイルを変更します。
```
:hostname: <host>:<new port>
```
IBM Endpoint Manager for Mobile Devices サービスを開始します。

PIN と登録情報はどこに保管されていますか?

この情報は、以下のレジストリー・キー内にあります。

Windows コンピューターの場合

登録用の PIN

HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\SSP_PIN

登録ユーザー

HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\SSP_Green

ブロックされたユーザー

HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\SSP_Red
Mac、Linux、AIX、Solaris コンピューターの場合

登録用の PIN

/var/opt/BESClient/SSP_PIN

登録ユーザー

/var/opt/BESClient/__BESData/SSP_Green

ブロックされたユーザー

/var/opt/BESClient/__BESData/SSP_Red

セルフサービス・ポータルからのソフトウェア・インストールに失敗したとの報告をユーザーから受けました。アプリケーション管理にデプロイした後にタスクをパッケージから削除したときに、この問題が発生しました。どうすれば解決できますか?: タスクが存在しないため、タスクの発行ができません。コンソールの「アクション」ビューにも表示されません。削除したタスクを参照しているすべてのアプリケーション管理グループを検出して停止する必要があります。その後、存在しなくなったタスクへの参照を消去し、そのアプリケーション管理グループを再度デプロイします。

ソフトウェア配信サイトをサブスクライブ解除すると、セルフサービス・ポータルが削除されますか?: いいえ、ソフトウェア配信サイトをサブスクライブ解除しても、セルフサービス・ポータルは削除されません。セルフサービス・ポータルの削除について詳しくは、『セルフサービス・ポータルのアンインストール』を参照してください。

セルフサービス・ポータルへのログインを試行したときに、「トラステッド・サービス・プロバイダーに接続できませんでした」というエラーが発生しました。どうすればよいでしょう。

通常、このエラーは、セルフサービス・ポータルが削除され、再びインストールされたときに発生します。このエラーが発生する場合、以下のステップを実行してください。

https://<your_host_name>/ssp/diagnostics の「セルフサービス・ポータルの診断」ページに移動します。
TSP 接続テストおよび TSP ルート CA が「接続拒否」と表示される場合は、セルフサービス・ポータル用の証明書ファイルを削除します。証明書ファイルはこちらにあります。 <path_to_TEM_server_directory>\BigFix Enterprise\Management Extender\MDM Providers\MDMExtender\private\ssp\trusted_certs\<your_certificate_file>.pem
注: 証明書ファイルは、次回セルフサービス・ポータルにログインしたときに自動的に生成されます。

セルフサービス・ポータルを構成しましたが、URL が見つかりません。: ソフトウェア配信およびモバイル・デバイス管理は、SSP コンポーネントを共有しています。モバイル・デバイス管理の特定のエクステンダーを削除せずにモバイル・デバイス管理サイトをサブスクライブ解除した場合に、この問題が発生する可能性があります。この問題を修正するには、モバイル・デバイス管理サイトを再度サブスクライブし、そのエクステンダーを適切に削除してからサイトをサブスクライブ解除します。

ソフトウェア配信タスクを削除しましたが、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」に変更し、タスクを再度実行してください。

App-V 5.0 クライアント・タスクを作成しましたが、このタスクとエンドポイントとの関連付けされるのを確認できません。

App-V 5.0 クライアントが以下の前提条件を満たしていることを確認してください。

Microsoft .NET Framework 4
Windows Powershell 3.0
Visual C++ 2010 再頒布可能パッケージ (x86)
KB2533623 以降をダウンロードおよびインストール

詳しくは、https://technet.microsoft.com/en-us/library/jj713458.aspx で Microsoft ドキュメントを参照してください。

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

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

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

エクスポートまたはインポートが失敗した理由を調べるには、<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 にあるダウンロード・ログを確認します。