Експорт SharePoint у Excel: де насправді виконується оновлення
Простежте експорт SharePoint-Excel через файл запиту, власний HTTP-запит Office і збережене оновлення та з’ясуйте, який етап насправді зірвався.
Експорт у Excel створює три різні артефакти залежно від розгортання, і помилка належить рівно одному з них. Завантажений файл запиту, статичний CSV і зв’язана таблиця з оновленням — це не той самий результат, і кожен з них зривається на своєму етапі. Знання того, який артефакт у вас є, визначає, за якою командою залишиться наступний крок: мережевою, командою ідентичності чи власником списку. Механізм нижче простежує передачу від браузера до власного запиту Excel.
Що насправді передає експорт
У класичних списках SharePoint команда «Експорт в Excel» завантажує невеликий текстовий файл, тілом якого є URL, потім Excel читає цей файл і надсилає власний запит за даними, що стоять за ним. Завантажений файл — це покажчик, а не список. Експорт CSV, навпаки, містить самі рядки й не має з’єднання для оновлення. Новіша зв’язана таблиця може вбудувати запит безпосередньо в книгу, тож у теку «Завантаження» взагалі нічого не потрапляє.
Будь-яка зв’язана форма є однобічною. Оновлення підтягує поточні рядки зі списку в книгу, а редагування таблиці нічого не надсилає назад. Ця асиметрія важлива для діагностики, бо книга, яка відкривається з рядками минулого тижня, вже довела, що файл існує і з’єднання було збережено, але нічого не каже про те, чи працює оновлення сьогодні.
Отже, перше питання не в тому, чому експорт не вдався, а в тому, який артефакт очікував користувач. Відповідь звужує розслідування до одного з трьох процесів.
Три процеси, три різні ідентичності
Завантаження в браузері використовує сеанс браузера з його власними файлами cookie, налаштуванням проксі та станом входу. Excel під час відкриття файлу використовує стек HTTP пакета Office, який зазвичай дотримується проксі з «Властивостей оглядача» для окремого користувача, а не налаштування WinHTTP для всієї машини, і проходить автентифікацію під тим обліковим записом Office, який має користувач. Пізніше оновлення повторно використовує збережене з’єднання і може взяти кешовані облікові дані з «Диспетчера облікових даних» Windows, а не запитувати їх.
Ці три контексти можуть не збігатися на одній машині, і тому браузер, який відкриває список без проблем, і оновлення Excel, яке повертає запит на вхід, — це узгоджений результат, а не суперечність. Тунель змінює маршрутизацію машини для всіх трьох, але файл автоматичної конфігурації проксі все ще може надсилати запити Office в інше місце.
Запишіть ідентичність, яка використовується на кожному етапі, перш ніж змінювати будь-яку з них. Виправлення, застосоване до браузера, не може виправити запит, який Excel робить під іншим обліковим записом.
Прочитайте файл передачі, перш ніж щось змінювати
Завантажений файл — це звичайний текст, і зазвичай він короткий, тож прочитайте його першим. У ньому вказано хост і кінцеву точку, які викличе Excel, і саме цей хост має розв’язуватися та проходити автентифікацію з машини користувача, а не обов’язково адреса, видима в адресному рядку браузера.
Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy
Порівняйте хост у файлі із сайтом, з якого користувач, на його думку, виконував експорт. Переспрямування під час експорту, старе сімейство сайтів або перенесений список можуть залишити покажчик на ім’я, яке більше не обслуговує дані, і помилка, що виникає, виглядає як збій мережі. Якщо ім’я розв’язується і кінцева точка відповідає, кандидатами, що залишилися, є автентифікація і сам запит.
Не замінюйте ім’я хоста IP-адресою, щоб усе запрацювало. Це порушує перевірку імені сертифіката і приховує справжню проблему за обхідним рішенням, яке зламається під час наступного поновлення сертифіката.
Розділіть збої імені, входу та запиту
Чотири результати охоплюють майже кожне звернення, і кожен має свого власника. Ім’я, яке не розв’язується, належить DNS. З’єднання, яке завершується за тайм-аутом, належить маршрутизації або проксі. Запит на вхід або відповідь 401 належать ідентичності. Відповідь, яка надходить, але не розбирається, належить запиту або кінцевій точці, яку список тепер надає.
| What the user sees | Stage that failed |
|---|---|
| Data source could not be found | Name resolution or the pointer in the file |
| Repeated sign-in prompt | Office identity or cached credential |
| Timeout while refreshing | Route, proxy or the VPN path |
| Refresh succeeds, rows look wrong | Query scope or list view, not connectivity |
Останній рядок — той, який люди діагностують неправильно. Оновлення, яке завершується й повертає не ті рядки, вже довело, що кожен мережевий та ідентифікаційний рівень працює, і залишається питання, яке подання або який фільтр несе запит. Надсилання такої заявки мережевій команді марнує день.
Збережіть точний текст помилки та час першого збою. Саме він визначає, у якому рядку таблиці ви перебуваєте, і це єдиний доказ, на який власник списку може спертися.
Повторно перевірте оновлення на тому самому списку
Визначивши збійний етап, повторіть ту операцію, яка не вдалася, а не дешевшу. Оновіть той самий список із передбачуваного середовища Excel, з очікуваним обліковим записом і схваленим мережевим шляхом, і підтвердьте, що кількість рядків або відоме змінене значення справді оновлюється. Відкриття збереженої книги нічого не доводить про з’єднання.
Опіртеся широким виправленням: видалення всіх збережених облікових даних, запуск Office з підвищеними правами або вимкнення функції безпеки може змінити симптом, не виправивши етап. Якщо автентифікація — це збійний рівень, попросіть власника списку підтвердити обліковий запис і підтримуваний потік входу замість здогадок на клієнті.
Пропонуйте CSV лише тоді, коли від’єднаний знімок задовольняє завдання і такий експорт підтримується в середовищі. Зміна вихідного формату змінює робочий процес і не пояснює, чому зв’язана операція перестала працювати.