Excel へのエクスポートは展開方法によって 三種類の成果物を生み出し、エラーはそのうちのどれか 一つに属します。ダウンロードされたクエリ ファイル、静的な CSV、更新される接続テーブルは同じ結果ではなく、それぞれ別の段階で失敗します。どれを持っているかが分かれば、次の一手がネットワーク チーム、ID チーム、リスト所有者の誰に属するかが決まります。以下の仕組みは、ブラウザーから Excel 自身の要求への受け渡しを追います。

エクスポートが実際に渡すもの

クラシック SharePoint リストでは、Excel にエクスポートを実行すると、本文が URL である小さなテキスト ファイルがダウンロードされ、その後 Excel がそのファイルを読み、その背後にあるデータに対して独自の要求を送ります。ダウンロードされたファイルはポインターであり、リストそのものではありません。これに対し CSV エクスポートは行そのものを含み、更新のための接続を持ちません。新しい接続テーブルではクエリをブックに直接埋め込めるため、ダウンロード フォルダーには何も残りません。

接続された形式はいずれも一方向です。更新はリストの現在の行をブックに取り込み、テーブルを編集しても何も書き戻されません。この非対称性は診断で重要で、先週の行で開くブックは、ファイルが存在し接続が保存されていたことをすでに証明していますが、今日更新が動くかどうかについては何も語りません。

したがって最初の問いは、なぜエクスポートが失敗したかではなく、利用者がどの成果物を期待していたかです。答えによって調査範囲は 三つのプロセスのどれか 一つに絞られます。

三つのプロセス、三つの異なる ID

ブラウザーでのダウンロードはブラウザーのセッションを使い、独自の Cookie、プロキシ構成、サインイン状態を伴います。ファイルを開く Excel は Office の HTTP スタックを使い、これは通常、マシン全体の WinHTTP 設定ではなくユーザーごとのインターネット オプションのプロキシに従い、利用者が持つ Office の ID で認証します。その後の更新は保存された接続を再利用し、問い合わせる代わりに Windows の資格情報マネージャーからキャッシュされた資格情報を取得することがあります。

この 三つのコンテキストは同じマシン上で食い違うことがあり、だからこそリストを問題なく開くブラウザーと、サインインを求める Excel の更新は矛盾ではなく整合した結果です。トンネルは 三つすべてのマシンの経路を変えますが、プロキシ自動構成ファイルが Office の要求を別の場所へ送ることは依然としてあります。

どれかを変更する前に、各段階で使われた ID を記録します。ブラウザーに適用した修正は、Excel が別のアカウントで出す要求を直せません。

何かを変える前に受け渡しファイルを読む

ダウンロードされたファイルはプレーン テキストで通常は短いので、まずそれを読みます。Excel が呼び出すホストとエンドポイントが書かれており、利用者のマシンから解決し認証する必要があるのはそのホストであって、ブラウザーのアドレス バーに見えるアドレスとは限りません。

Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy

ファイル内のホストを、利用者がエクスポートしたと思っているサイトと比べます。エクスポート中のリダイレクト、古いサイト コレクション、移行されたリストは、もはやデータを提供していない名前へのポインターを残すことがあります、その結果のエラーはネットワーク障害のように見えます。名前が解決しエンドポイントが応答するなら、残る候補は認証とクエリそのものです。

動かすためにホスト名を IP アドレスに置き換えないでください。それは証明書の名前チェックを壊し、次の証明書更新で失敗する回避策の裏に本当の問題を隠します。

名前、サインイン、クエリの障害を切り分ける

四つの結果でほぼすべての報告を説明でき、それぞれ担当が異なります。解決しない名前は DNS に属します。タイムアウトする接続は経路またはプロキシに属します。サインインの要求や 401 は ID に属します。到着しても解析できない応答は、クエリまたはリストが現在公開しているエンドポイントに属します。

What the user seesStage that failed
Data source could not be foundName resolution or the pointer in the file
Repeated sign-in promptOffice identity or cached credential
Timeout while refreshingRoute, proxy or the VPN path
Refresh succeeds, rows look wrongQuery scope or list view, not connectivity

最後の行こそ誤診されやすい行です。完了して誤った行を返す更新は、ネットワークと ID のあらゆる層が機能していることをすでに証明しており、残る問いはクエリがどのビューやフィルターを伴っているかです。そのチケットをネットワーク チームへ送るのは 一日の無駄です。

正確なエラー テキストと最初の失敗時刻を残します。それが表のどの行にいるかを決め、リスト所有者が行動できる唯一の証拠になります。

同じリストで更新を再テストする

失敗した段階を特定したら、より安価な操作ではなく、失敗した操作そのものを繰り返します。意図した Excel 環境から、想定されたアカウントと承認済みのネットワーク経路で同じリストを更新し、行数や既知の変更値が実際に更新されることを確認します。保存済みのブックを開くことは接続について何も証明しません。

広範な修復には抗ってください—保存済みの資格情報をすべて消す、Office を昇格して実行する、セキュリティ機能を無効にするといった行為は、段階を直さずに症状だけを変えることがあります。認証が失敗している層なら、クライアント側で推測するのではなく、リスト所有者にアカウントとサポートされるサインイン フローを確認してもらいます。

CSV は、切断されたスナップショットで用が足り、そのエクスポートが環境でサポートされている場合にのみ提案します。出力形式を変えることはワークフローを変えることであり、接続された操作が止まった理由の説明にはなりません。

関連記事