Excel로 내보내기는 배포 방식에 따라 세 가지 산출물을 만들며, 오류는 그중 정확히 하나에 속합니다. 내려받은 쿼리 파일, 정적 CSV, 새로 고침되는 연결 표는 같은 결과가 아니며 각각 다른 단계에서 실패합니다. 어떤 산출물을 가지고 있는지 알면 다음 단계가 네트워크 팀, ID 팀, 목록 소유자 중 누구에게 속하는지 정해집니다. 아래 메커니즘은 브라우저에서 Excel 자체의 요청으로 이어지는 인계 과정을 따릅니다.

내보내기가 실제로 인계하는 것

클래식 SharePoint 목록에서 Excel로 내보내기는 본문이 URL인 작은 텍스트 파일을 내려받고, 이어서 Excel이 그 파일을 읽고 그 뒤에 있는 데이터에 대해 자체 요청을 보냅니다. 내려받은 파일은 목록 자체가 아니라 포인터입니다. 반대로 CSV 내보내기는 행 자체를 담고 있으며 새로 고침을 위한 연결이 없습니다. 최신 연결 표는 쿼리를 통합 문서에 직접 넣을 수 있으므로 다운로드 폴더에는 아무것도 남지 않습니다.

연결된 모든 형식은 단방향입니다. 새로 고침은 목록의 현재 행을 통합 문서로 가져오고, 표를 편집해도 아무것도 되돌려 보내지 않습니다. 이 비대칭성은 진단에 중요하며, 지난주 행으로 열리는 통합 문서는 파일이 존재하고 연결이 저장되었다는 것을 이미 증명했지만, 오늘 새로 고침이 되는지에 대해서는 아무것도 말해 주지 않습니다.

따라서 첫 번째 질문은 내보내기가 왜 실패했는지가 아니라 사용자가 어떤 산출물을 기대했는지입니다. 답은 조사를 세 가지 프로세스 중 하나로 좁힙니다.

세 가지 프로세스, 세 가지 서로 다른 ID

브라우저의 다운로드는 브라우저 세션을 사용하며 자체 쿠키, 프록시 구성, 로그인 상태를 함께 씁니다. 파일을 여는 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를 제안하십시오. 출력 형식을 바꾸면 작업 흐름이 바뀌며, 연결된 작업이 왜 멈췄는지는 설명하지 못합니다.

관련 글