خروجی گرفتن از SharePoint به Excel: به‌روزرسانی واقعاً کجا اجرا می‌شود
یک خروجی SharePoint-Excel را از فایل پرس‌وجو، درخواست HTTP خود Office و به‌روزرسانی ذخیره‌شده دنبال کنید و بفهمید کدام مرحله واقعاً شکست خورده است.
خروجی گرفتن به Excel بسته به استقرار سه مصنوع متفاوت تولید می‌کند و خطا دقیقاً به یکی از آن‌ها تعلق دارد. فایل پرس‌وجوی دانلودشده، CSV ایستا و جدول متصلِ به‌روزشونده یک نتیجه نیستند و هر یک در مرحله‌ای متفاوت شکست می‌خورند. دانستن اینکه کدام مصنوع را دارید تعیین می‌کند که گام بعدی به تیم شبکه، تیم هویت یا مالک فهرست تعلق دارد. سازوکار زیر تحویل از مرورگر تا درخواست خود Excel را دنبال می‌کند.
خروجی واقعاً چه چیزی را تحویل می‌دهد
در فهرست‌های کلاسیک SharePoint، گزینهٔ خروجی به Excel یک فایل متنی کوچک دانلود می‌کند که بدنهٔ آن یک URL است، سپس Excel آن فایل را می‌خواند و درخواست خودش را برای داده‌های پشت آن ارسال می‌کند. فایل دانلودشده یک اشاره‌گر است، نه خود فهرست. در مقابل، خروجی CSV خود ردیف‌ها را دارد و هیچ اتصالی برای به‌روزرسانی ندارد. جدول متصل جدیدتر می‌تواند پرس‌وجو را مستقیماً در کتاب کار جاسازی کند، بنابراین هیچ‌چیز اصلاً در پوشهٔ بارگیری‌ها قرار نمی‌گیرد.
هر شکل متصل یک‌طرفه است. به‌روزرسانی ردیف‌های جاری را از فهرست به کتاب کار می‌کشد و ویرایش جدول چیزی را برنمی‌گرداند. این عدم تقارن برای عیب‌یابی مهم است، زیرا کتاب کاری که با ردیف‌های هفتهٔ گذشته باز می‌شود قبلاً ثابت کرده است که فایل وجود دارد و اتصال ذخیره شده بوده، اما هیچ چیزی دربارهٔ اینکه به‌روزرسانی امروز کار می‌کند یا نه نمی‌گوید.
پس پرسش اول این نیست که چرا خروجی شکست خورد، بلکه این است که کاربر منتظر کدام مصنوع بود. پاسخ بررسی را به یکی از سه فرایند محدود می‌کند.
سه فرایند، سه هویت متفاوت
دانلود در مرورگر از نشست مرورگر با کوکی‌های خودش، پیکربندی پراکسی و وضعیت ورود استفاده می‌کند. Excel هنگام باز کردن فایل از پشتهٔ HTTP آفیس استفاده می‌کند که عموماً به‌جای تنظیم WinHTTP در سطح کل ماشین، از پراکسی گزینه‌های اینترنت برای هر کاربر پیروی می‌کند و با هر هویتی از آفیس که کاربر دارد احراز هویت می‌کند. به‌روزرسانی بعدی از اتصال ذخیره‌شده دوباره استفاده می‌کند و ممکن است به‌جای پرسیدن، اعتبارنامه‌های کش‌شده را از مدیر اعتبارنامهٔ ویندوز بردارد.
این سه زمینه می‌توانند روی یک ماشین با هم اختلاف داشته باشند، و به همین دلیل مرورگری که فهرست را بی‌مشکل باز می‌کند و به‌روزرسانی Excel که درخواست ورود برمی‌گرداند، نتیجه‌ای سازگار است و نه تناقض. تونل مسیریابی ماشین را برای هر سه تغییر می‌دهد، اما فایل پیکربندی خودکار پراکسی هنوز می‌تواند درخواست‌های آفیس را جای دیگری بفرستد.
هویتی را که در هر مرحله استفاده می‌شود پیش از تغییر هر یک از آن‌ها ثبت کنید. اصلاحی که روی مرورگر اعمال شود نمی‌تواند درخواستی را که 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 مورد نظر، با حساب مورد انتظار و مسیر شبکهٔ تأییدشده به‌روزرسانی کنید و تأیید کنید که تعداد ردیف‌ها یا یک مقدار شناخته‌شدهٔ تغییرکرده واقعاً به‌روز می‌شود. باز کردن یک کتاب کار ذخیره‌شده هیچ چیزی دربارهٔ اتصال ثابت نمی‌کند.
در برابر تعمیرات گسترده مقاومت کنید: پاک کردن همهٔ اعتبارنامه‌های ذخیره‌شده، اجرای آفیس با دسترسی بالا یا غیرفعال کردن یک ویژگی امنیتی می‌تواند نشانه را تغییر دهد بدون آنکه مرحله را درست کند. اگر احراز هویت لایهٔ ناکام است، از مالک فهرست بخواهید حساب و جریان ورود پشتیبانی‌شده را تأیید کند، نه اینکه روی سمت کلاینت حدس بزنید.
CSV را تنها زمانی پیشنهاد دهید که یک تصویر لحظه‌ایِ جدا از شبکه وظیفه را برآورده کند و آن خروجی برای محیط پشتیبانی شود. تغییر قالب خروجی جریان کار را تغییر می‌دهد و توضیح نمی‌دهد چرا عملیات متصل از کار افتاده است.