Tras migrar los servicios a un nuevo Windows Server, todo funciona… hasta que apagas el servidor antiguo. Si tus usuarios pierden conexiones o “se caen” las apps, la causa puede estar en las GPO de Drive Maps con acción Replace. Aquí tienes el porqué y cómo resolverlo paso a paso.
Resumen ejecutivo
- Contexto: Migración de roles FSMO, DNS/DHCP y recursos compartidos a un nuevo servidor Windows; el servidor antiguo se apaga y empiezan las caídas.
- Síntoma: Con el servidor antiguo encendido, las aplicaciones de red funcionan; al apagarlo, usuarios desconectados, sesiones bloqueadas o errores intermitentes.
- Causa raíz: Las asignaciones de unidades realizadas por Group Policy Preferences → Drive Maps estaban configuradas con la acción Replace (Reemplazar).
- Qué provoca: En cada inicio de sesión y en cada actualización de directivas (≈90–120 min), Replace elimina y vuelve a crear las unidades, cortando conexiones activas. Si el servidor antiguo ya no existe, la operación se alarga/falla y las apps quedan en estado inconsistente.
- Solución: Cambiar la acción a Update (Actualizar). Update conserva la unidad y solo ajusta propiedades si hace falta, evitando cortes.
Contexto: migración de servidor y efectos colaterales
La migración de un servidor de archivos e infraestructura (FSMO, DNS, DHCP) suele incluir pasos bien conocidos: trasladar roles, ajustar registros, demover el controlador antiguo y redirigir rutas UNC. Todo puede parecer correcto: el dominio está sano, la replicación bien, los registros SRV limpios y la resolución DNS coherente. Sin embargo, persiste un comportamiento extraño: con el servidor antiguo encendido, la red va bien; con él apagado, se rompen conexiones de aplicaciones que dependen de unidades mapeadas (ERP, CAD, contabilidad, herramientas legacy, etc.).
Ese patrón temporal no suele apuntar a DNS o autenticación, sino a reaplicaciones periódicas de configuración de cliente. Ahí es donde entran las Group Policy Preferences (GPP) de Drive Maps.
Síntomas observados típicos
- Usuarios pierden sesiones de aplicaciones que trabajan sobre rutas UNC montadas como letra de unidad.
- Errores de “archivo en uso”, “ruta no disponible” o “no se puede escribir” durante el día, sin patrón fijo.
- Con el servidor antiguo encendido, el problema disminuye o desaparece; al apagarlo, reaparecen las caídas.
- En clientes, comandos como
net use
muestran reintentos o desaparición temporal de letras mapeadas.
Análisis: por qué “Replace” derriba tus aplicaciones
Las GPP de Drive Maps permiten cuatro acciones. Su diferencia no es cosmética: decide si una letra se “toca” en cada aplicación de directiva.
Acción | Comportamiento | Impacto en sesiones activas | Uso recomendado |
---|---|---|---|
Create | Crea la unidad si no existe; no la modifica si ya está. | Bajo. No interrumpe conexiones existentes. | Provisionado inicial. |
Update | Conserva la unidad; actualiza propiedades (ruta, etiqueta, letras) sin borrar/recrear. | Muy bajo. Mantiene handles activos en la mayoría de escenarios. | Operación diaria y cambios tras migración. |
Replace | Elimina y vuelve a crear la unidad en cada procesamiento de GPO (inicio de sesión y refresco periódico). | Alto. Corta conexiones y puede provocar “timeouts”. | Casos puntuales en los que necesitas limpieza total (poco frecuente). |
Delete | Quita la unidad mapeada (si existe). | Alto, pero controlado y explícito. | Retirar mapeos obsoletos mediante Item-level targeting. |
Por defecto, las directivas de usuario se reaplican en segundo plano cada ~90 minutos con un desfase aleatorio de hasta 30 minutos. Si Replace está activo, el cliente:
- Elimina la letra mapeada actual.
- Intenta crear la nueva conexión.
- Durante ese intervalo, cualquier aplicación con archivos abiertos pierde el handle.
Cuando el servidor antiguo aún está encendido, la recreación puede ser rápida (o la ruta antigua sigue respondiendo), por lo que los usuarios apenas notan el “parpadeo”. Pero al apagarlo, cualquier referencia residual a la ruta vieja o la latencia por reintentos provoca retrasos y errores visibles.
Solución aplicada: cambia “Replace” por “Update”
La corrección es directa y de bajo riesgo. Cambiar la acción a Update hace que la GPO conserve la unidad y actualice solo lo que sea necesario, sin desconectar sesiones activas.
Paso a paso para implementar
- Editar la GPO de mapeo de unidades
Abre el Group Policy Management Editor y navega a:User Configuration → Preferences → Windows Settings → Drive Maps
- Abrir cada elemento de mapeo y cambiar Action = Update
Verifica además:- Que la ruta UNC apunte al nuevo servidor/compartido.
- Marca Reconnect/Volver a conectar si necesitas persistencia tras reinicio.
- En Common, evita “Run in logged-on user’s security context” si no aplica a tu escenario.
- Eliminar entradas antiguas
Quita o deshabilita cualquier elemento que siga apuntando al servidor retirado. Si necesitas retirar un mapeo antiguo, crea un elemento separado con Action = Delete y controla su ámbito con Item-level targeting para no afectar a todos los usuarios a la vez. - Forzar la aplicación en clientes
Ejecuta:gpupdate /target:user /force
También puedes optar por cierre de sesión/inicio de sesión o reinicio fuera de horario. - Validar en clientes
Comprueba las letras y rutas activas:net use
Asegúrate de que únicamente existan las unidades esperadas y que todas apunten al nuevo servidor.
Cómo confirmar el diagnóstico (trazabilidad)
Antes o después del cambio, puedes validar que las GPP de Drive Maps estaban “tocando” las unidades en segundo plano.
- Visor de eventos (cliente): Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Busca eventos que indiquen el procesamiento de Drive Maps y su acción.
- Resultados de directiva:
gpresult /r /scope:user
Confirma qué GPO aplica el mapeo y en qué orden. - Monitoreo en tiempo real:
gpupdate /force & timeout /t 5 & eventvwr.msc
Tabla de verificación rápida
Tarea | Objetivo | Comando/Sitio | Estado |
---|---|---|---|
Cambiar Drive Maps a Update | Evitar cortes por recreación | GPMC → Drive Maps | ✔ |
Eliminar mapeos obsoletos | Evitar referencias al servidor retirado | GPMC → Elemento con Delete | ✔ |
Forzar aplicación de GPO | Aplicar cambios de inmediato | gpupdate /target:user /force | — |
Verificar rutas en clientes | Confirmar que apuntan al nuevo servidor | net use | — |
Revisar eventos GPO | Corroborar re-aplicaciones previas | Event Viewer (GroupPolicy/Operational) | — |
Comprobaciones adicionales recomendadas
Aunque la raíz del problema sea Replace, conviene reforzar la estabilidad revisando DNS, DHCP y estado de AD.
DNS y DHCP
- DHCP: valida las opciones:
- 006 (DNS Servers): apunta a tus controladores DNS actuales (nuevo servidor si aplica).
- 015 (DNS Domain Name): nombre de dominio correcto.
- DNS:
- Limpia registros NS obsoletos en zonas directas e inversas.
- Comprueba
_msdcs
y registros SRV (elimina referencias a DCs retirados). - En clientes, tras cambios mayores:
ipconfig /flushdns ipconfig /registerdns
Validación de GPO y registro de eventos
- Event Viewer → GroupPolicy/Operational para confirmar frecuencia y éxito de las GPP de Drive Maps.
gpresult /h C:\Temp\gpresult.html
para un informe navegable de qué GPO impacta al usuario.
Salud de Active Directory
- Verifica la replicación y limpieza de metadatos si demoviste DCs.
- Ejemplos útiles:
dcdiag /v repadmin /replsummary repadmin /showrepl
Buenas prácticas para futuras migraciones
- Usa rutas lógicas con DFS Namespaces: en lugar de
\\Servidor\Recurso
, publica\\dominio.local\dfs\Recursos
. Así, futuras migraciones cambian el backend sin tocar los mapeos. - Evita “Replace” por defecto: reserva Replace solo para limpiezas excepcionales. Para el día a día, usa Update.
- Retirada controlada: si necesitas eliminar un mapeo antiguo, crea un elemento Delete con Item-level targeting (grupos, ubicación, versión de SO) y una ventana de mantenimiento.
- Diseño de GPO modular: una GPO por función (por ejemplo, “DriveMaps-Departamento-Contabilidad”) facilita auditoría y rollback.
- Pruebas por anillos: aplica primero a un pilot group, luego al resto.
- Etiqueta y documenta: incluye en la descripción de la preferencia la fecha de migración y la ruta vieja/nueva.
Plan de prueba (antes y después de la migración)
- Inventario de mapeos: exporta desde los equipos piloto
net use > %USERPROFILE%\Desktop\drives.txt
. - Prueba de carga leve: abre archivos grandes desde las unidades mapeadas y monitorea con
Resource Monitor
o el propio aplicativo. - Simulación de refresco de GPO: ejecuta
gpupdate /force
y observa si hay “parpadeo” de unidades con la app abierta. - Validación post-apagado del servidor antiguo: tras demoverlo, repite las pruebas y confirma estabilidad.
Preguntas frecuentes
¿Por qué solo fallaba cuando el servidor antiguo estaba apagado?
Con Replace, la unidad se elimina y recrea. Si el servidor antiguo sigue atendiendo, la recreación (aunque innecesaria) es rápida; al apagarlo, cualquier redirección residual o búsqueda de la ruta antigua introduce demoras y timeouts que afectan a las apps.
¿No sería mejor “Create”?
Create no toca la unidad si ya existe, lo cual es seguro, pero no actualiza propiedades (por ejemplo, etiqueta o letra). Update equilibra seguridad y control: mantiene la conexión y ajusta cambios menores.
¿Puedo reducir el impacto ajustando el intervalo de GPO?
Existen directivas para modificar el refresco de directivas en segundo plano, pero es una mitigación; la solución de fondo es dejar de recrear las unidades innecesariamente y usar Update.
¿Qué pasa con “Reconnect/Volver a conectar”?
Marca esta opción cuando quieres que el mapeo sea persistente tras reinicios. No soluciona la recreación forzada de Replace, pero ayuda a conservar la letra cuando el usuario vuelve a iniciar sesión.
¿Cómo retiro de forma segura un mapeo histórico?
Crea un elemento independiente con Action = Delete y controla su aplicación con Item-level targeting (grupos de seguridad, OU, pertenencia a equipo). Evita usar Replace sobre el mapeo nuevo para “barrer” el viejo.
Procedimiento de remediación completo (guía de campo)
- Audita. Enumera las GPO que contienen Drive Maps y localiza las que usan Replace.
Get-GPOReport -All -ReportType Xml -Path C:\Temp\AllGPOs.xml
(Abre el XML o usa un visor para buscar “Drive Maps”.) - Corrige. En cada elemento, cambia Action = Update. Ajusta la ruta UNC al nuevo servidor.
- Limpia. Crea elementos Delete específicos para rutas obsoletas; añade Item-level targeting si conviene.
- Despliega por anillos. Aplica primero a un grupo piloto, observa 24–48 h, y luego al resto de usuarios.
- Comunica. Informa a los usuarios de una posible breve reconexión tras el gpupdate inicial (sin pérdida de sesiones).
- Verifica. Usa
gpresult
y el Visor de eventos para confirmar que ya no se ejecuta Replace.
Ejemplos prácticos
Comando de saneamiento (con cautela)
Si encuentras mapeos “fantasma” en un equipo piloto y quieres empezar limpio (fuera de horario y con apps cerradas):
net use * /delete /y
gpupdate /target:user /force
Evita usarlo en masa durante horario productivo.
Plantilla de comunicación al usuario
Mañana a las 08:00h aplicaremos un ajuste de mapeos de unidades. No se esperan interrupciones; si notas que una letra de unidad “reaparece” brevemente, es normal. Si alguna app muestra error de ruta, reiníciala y contacta con el Service Desk.
Errores comunes a evitar
- Dejar Replace “por si acaso” después de una migración: genera cortes silenciosos cada vez que se reaplica la GPO.
- Eliminar la GPO antigua sin retirar los mapeos viejos: algunos equipos mantienen mapeos persistentes.
- No revisar DFS después de mover compartidos: el namespace puede seguir apuntando a un target retirado.
- Olvidar los sitios de AD y subredes en DHCP: clientes “lejanos” resuelven al DC equivocado.
Conclusión
Los síntomas de “todo va bien hasta que apago el servidor antiguo” suelen tener un culpable poco evidente: la acción Replace en las GPP de Drive Maps. Al recrear las unidades en cada refresco de directivas, se cortan conexiones de las que dependen muchas aplicaciones críticas. Con un simple cambio a Update —y una limpieza de entradas obsoletas— recuperarás la estabilidad sin afectar a los usuarios. Compleméntalo con revisiones de DNS/DHCP y, de cara al futuro, adopta DFS Namespaces y despliegues por anillos para que la próxima migración sea invisible para el negocio.
Pasos concretos (resumen operativo)
- Editar la GPO: User → Preferences → Windows Settings → Drive Maps.
- En cada mapeo, poner Action = Update y verificar la nueva ruta UNC.
- Eliminar entradas antiguas que apunten al servidor retirado.
- Forzar aplicación en clientes con
gpupdate /force
o reinicio/cierre de sesión. - Validar con
net use
que las letras y rutas sean las esperadas.
Checklist de comprobaciones complementarias
- DHCP: opciones 006 y 015 correctas.
- DNS: registros SRV y NS limpios;
_msdcs
y zonas inversas sin residuos. - Eventos de GPO: revisión en GroupPolicy/Operational.
- Informe de resultado de directiva:
gpresult /r /scope:user
. - Buenas prácticas: usar DFS, retirar con Delete + Item-level targeting, evitar Replace por defecto.