Exportar SharePoint a Excel: dónde se ejecuta realmente la actualización

Exportar a Excel produce tres artefactos distintos según la implementación, y el fallo pertenece exactamente a uno de ellos. Un archivo de consulta descargado, un CSV estático y una tabla conectada que se actualiza no son el mismo resultado, y cada uno falla en una etapa diferente. Saber qué artefacto tiene decide si el siguiente paso corresponde al equipo de red, al equipo de identidad o al propietario de la lista. El mecanismo siguiente sigue el traspaso del navegador a la propia solicitud de Excel.

Qué entrega realmente la exportación

En las listas clásicas de SharePoint, Exportar a Excel descarga un archivo de texto pequeño cuyo cuerpo es una URL; después, Excel lee ese archivo y emite su propia solicitud de los datos que hay detrás. El archivo descargado es un puntero, no la lista. Una exportación CSV, en cambio, contiene las filas mismas y no tiene conexión para actualizar. Una tabla conectada más reciente puede incrustar la consulta directamente en el libro, de modo que no llega nada a la carpeta Descargas.

Toda forma conectada es unidireccional. La actualización trae las filas actuales de la lista al libro, y editar la tabla no devuelve nada. Esa asimetría importa para el diagnóstico, porque un libro que se abre con las filas de la semana pasada ya ha demostrado que el archivo existe y que la conexión se guardó, mientras no dice nada sobre si la actualización funciona hoy.

Así que la primera pregunta no es por qué falló la exportación, sino qué artefacto esperaba el usuario. La respuesta reduce la investigación a uno de tres procesos.

Tres procesos, tres identidades distintas

La descarga del navegador usa la sesión del navegador, con sus propias cookies, su configuración de proxy y su estado de inicio de sesión. Excel, al abrir el archivo, usa la pila HTTP de Office, que por lo general sigue el proxy de Opciones de Internet por usuario en lugar del ajuste WinHTTP de toda la máquina, y que se autentica con la identidad de Office que tenga el usuario. Una actualización posterior reutiliza la conexión guardada y puede tomar credenciales en caché del Administrador de credenciales de Windows en lugar de preguntar.

Esos tres contextos pueden discrepar en una sola máquina, y por eso un navegador que abre la lista sin problema y una actualización de Excel que devuelve un aviso de inicio de sesión son un resultado coherente y no una contradicción. El túnel cambia el enrutamiento de la máquina para los tres, pero un archivo de configuración automática de proxy aún puede enviar las solicitudes de Office a otro sitio.

Anote la identidad usada en cada etapa antes de cambiar cualquiera de ellas. Una corrección aplicada al navegador no puede reparar una solicitud que Excel hace con otra cuenta.

Lea el archivo de traspaso antes de cambiar nada

El archivo descargado es texto plano y suele ser corto, así que léalo primero. Nombra el host y el punto de conexión que llamará Excel, y ese host es el que debe resolverse y autenticarse desde la máquina del usuario, no necesariamente la dirección visible en la barra de direcciones del navegador.

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

Compare el host del archivo con el sitio desde el que el usuario cree haber exportado. Una redirección durante la exportación, una colección de sitios antigua o una lista migrada pueden dejar un puntero a un nombre que ya no sirve los datos, y el error resultante parece un fallo de red. Si el nombre resuelve y el punto de conexión responde, los candidatos restantes son la autenticación y la propia consulta.

No sustituya el nombre del host por una dirección IP para hacerlo funcionar. Eso rompe la comprobación del nombre del certificado y oculta el problema real tras una solución provisional que falla en la siguiente renovación del certificado.

Separe los fallos de nombre, de inicio de sesión y de consulta

Cuatro resultados cubren casi todos los informes, y cada uno tiene un dueño distinto. Un nombre que no resuelve pertenece a DNS. Una conexión que agota el tiempo pertenece al enrutamiento o a un proxy. Un aviso de inicio de sesión o un 401 pertenecen a la identidad. Una respuesta que llega pero no se puede analizar pertenece a la consulta o al punto de conexión que la lista expone ahora.

La última fila es la que la gente diagnostica mal. Una actualización que termina y devuelve las filas equivocadas ya ha demostrado que cada capa de red e identidad funciona, y la pregunta restante es qué vista o qué filtro lleva la consulta. Enviar ese ticket al equipo de red desperdicia un día.

Conserve el texto exacto del error y la hora del primer fallo. Decide en qué fila de la tabla está, y es la única prueba sobre la que el propietario de la lista puede actuar.

Vuelva a probar la actualización en la misma lista

Una vez identificada la etapa que falla, repita la operación que falló y no una más barata. Actualice la misma lista desde el entorno de Excel previsto, con la cuenta esperada y la ruta de red aprobada, y confirme que el recuento de filas o un valor modificado conocido se actualiza de verdad. Abrir un libro guardado no demuestra nada sobre la conexión.

Resista las reparaciones amplias: borrar todas las credenciales guardadas, ejecutar Office con privilegios elevados o desactivar una función de seguridad puede cambiar el síntoma sin arreglar la etapa. Si la autenticación es la capa que falla, pida al propietario de la lista que confirme la cuenta y el flujo de inicio de sesión admitido en lugar de adivinar en el cliente.

Ofrezca CSV solo cuando una instantánea desconectada satisfaga la tarea y esa exportación esté admitida para el entorno. Cambiar el formato de salida cambia el flujo de trabajo y no explica por qué dejó de funcionar la operación conectada.