Evitar que Windows fuerce “New Outlook”: cómo seguir usando Correo y Calendario (clásico) en Windows 10/11

¿Windows te fuerza a abrir “New Outlook” cuando intentas usar la app clásica Correo y Calendario? En esta guía tienes una solución práctica y reversible para impedir la redirección automática bloqueando el archivo de migración, de modo que puedas seguir usando la app clásica en Windows 10/11.

Índice

Resumen del problema

Muchos usuarios quieren seguir con Correo y Calendario (clásico), pero al abrirla son enviados a New Outlook aun después de desinstalarlo. En ciertos escenarios, Windows o Microsoft Store pueden reinstalar la app nueva y, además, la propia app clásica activa una migración al detectar un control interno. Resultado: redirección sin consentimiento.

La clave está en la carpeta de datos de la app clásica. Dentro de LocalState\Migration existe un archivo de control (settings.json) que, cuando está presente y con contenido determinado, permite que la aplicación se “salte” a New Outlook. Si eliminas ese archivo y evitas que vuelva a crearse, la redirección deja de suceder.

Solución: impedir la migración desde la carpeta de la app

No es posible “apagar” New Outlook globalmente (es una decisión de producto y la app clásica está en retirada), pero sí puedes evitar la redirección automática aplicando dos acciones sobre la carpeta de Migración de la app clásica:

Eliminar el archivo de control settings.json.
Denegar permisos de escritura al usuario actual sobre esa carpeta para impedir que se regenere la configuración que activa la migración.

Ruta implicada

%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration

Antes de empezar

Cierra Correo y Calendario y New Outlook.
Abre PowerShell como Administrador.
Esta operación afecta solo al usuario actual (perfil de Windows que la ejecuta). En entornos con varios usuarios, repite por cada perfil.

Pasos (PowerShell como administrador)

Script directo para borrar el archivo de control y denegar escritura a la carpeta Migration:

# 1) Ruta del directorio de migración de "Correo y Calendario"
$folderPath = Join-Path $env:LOCALAPPDATA 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'

2) Elimina el archivo de control si existe

\$fileToDelete = Join-Path \$folderPath 'settings.json'
if (Test-Path \$fileToDelete) {
Remove-Item -Path \$fileToDelete -Force
Write-Host "Eliminado: \$fileToDelete"
} else {
Write-Host "No existe: \$fileToDelete"
}

3) Deniega escritura a la carpeta "Migration" para el usuario actual

\$currentUser = \[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
\$acl = Get-Acl -Path \$folderPath
\$denyWriteRule = New-Object System.Security.AccessControl.FileSystemAccessRule(\$currentUser, "Write", "Deny")
\$acl.AddAccessRule(\$denyWriteRule)
Set-Acl -Path \$folderPath -AclObject \$acl
Write-Host "Se denegó escritura a \$currentUser en \$folderPath" </code></pre>

<h3>Variante recomendada (con herencia)</h3>
<p>La versión anterior funciona; sin embargo, puedes optar por una regla con herencia para reforzar el bloqueo también sobre elementos nuevos dentro de la carpeta:</p>
<pre><code># Refuerzo con herencia (opcional)
$folderPath = Join-Path $env:LOCALAPPDATA 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
if (-not (Test-Path $folderPath)) { New-Item -ItemType Directory -Path $folderPath -Force | Out-Null }

Limpia el archivo de control

\$fileToDelete = Join-Path \$folderPath 'settings.json'
if (Test-Path \$fileToDelete) { Remove-Item -Path \$fileToDelete -Force }

Deniega 'Write' al usuario actual con herencia a subcarpetas y archivos

\$currentUser = \[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
\$acl = Get-Acl -Path \$folderPath
\$inherit = \[System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor \`
\[System.Security.AccessControl.InheritanceFlags]::ObjectInherit
\$propagation = \[System.Security.AccessControl.PropagationFlags]::None
\$denyRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
\$currentUser,
\[System.Security.AccessControl.FileSystemRights]::Write,
\$inherit,
\$propagation,
\[System.Security.AccessControl.AccessControlType]::Deny
)
\$acl.AddAccessRule(\$denyRule)
Set-Acl -Path \$folderPath -AclObject \$acl
Write-Host "Bloqueo aplicado con herencia en: \$folderPath" </code></pre>

<h3>¿Prefieres usar CMD?</h3>
<p>Si te resulta más cómodo, puedes aplicar el bloqueo con <code>icacls</code> desde Símbolo del sistema (Administrador):</p>
<pre><code>mkdir "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration" 2&gt;nul
del /f /q "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration\settings.json" 2&gt;nul
icacls "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration" /deny "%USERNAME%":(W)
</code></pre>

<h2>Qué consigue esto</h2>
<ul>
  <li>Al abrir <strong>Correo y Calendario</strong> ya no te saltará New Outlook ni se producirá un “salto” de nuevo.</li>
  <li>La configuración de migración no puede recrearse para ese usuario porque la carpeta está bloqueada en escritura.</li>
</ul>

<h2>Limitaciones y expectativas realistas</h2>
<ul>
  <li><strong>Windows/Microsoft Store</strong> puede reinstalar <em>New Outlook</em> por su cuenta. Aunque vuelva a estar presente, el bloqueo anterior <em>evita la redirección</em>.</li>
  <li><strong>Correo y Calendario (clásico) está en retirada</strong> y acabará sin soporte. Esta guía no evita el fin de servicio, solo te permite seguir usándola mientras funcione.</li>
  <li>El bloqueo es <strong>por usuario</strong>. Si hay más cuentas locales en el mismo equipo, repite los pasos en cada perfil.</li>
</ul>

<h2>Cómo revertir los cambios (quitar el bloqueo)</h2>
<p>Si algún día quieres volver al comportamiento original, elimina las reglas “Deny Write” de esa carpeta:</p>
<pre><code>$folderPath = Join-Path $env:LOCALAPPDATA 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration'
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$acl = Get-Acl -Path $folderPath
$toRemove = $acl.Access | Where-Object {
  $_.IdentityReference -eq $currentUser -and
  $_.FileSystemRights.HasFlag([System.Security.AccessControl.FileSystemRights]::Write) -and
  $_.AccessControlType -eq 'Deny'
}
foreach ($rule in $toRemove) { [void]$acl.RemoveAccessRule($rule) }
Set-Acl -Path $folderPath -AclObject $acl
Write-Host "Regla 'Deny Write' revertida para $currentUser"
</code></pre>
<p>En CMD (si usaste <code>icacls</code>):</p>
<pre><code>icacls "%LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration" /remove:d "%USERNAME%"
</code></pre>

<h2>Verificación: ¿funcionó el bloqueo?</h2>
<ol>
  <li>Abre <strong>Correo y Calendario</strong>. No debería aparecer la pantalla que invita a probar New Outlook ni “saltar” automáticamente.</li>
  <li>Comprueba que <code>settings.json</code> no exista tras el primer arranque:
    <pre><code>$p = Join-Path $env:LOCALAPPDATA 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration\settings.json'
Test-Path $p
</code></pre>
    Si devuelve <code>False</code>, el bloqueo está activo.
  </li>
  <li>Valida las ACL de la carpeta:
    <pre><code>Get-Acl (Join-Path $env:LOCALAPPDATA 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration') | Format-List

Aplicación sin comandos (Explorador de archivos)

Si prefieres hacerlo en la interfaz gráfica:

Navega a %LOCALAPPDATA%\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState y entra en Migration. Si no existe, crea la carpeta.
Elimina settings.json si está presente.
Botón derecho sobre Migration → Propiedades → Seguridad → Editar….
Selecciona tu usuario de Windows y marca Denegar en Escribir (o Modificar, que incluye escribir). Aplica y acepta.
Cierra todo y abre Correo y Calendario para probar.

Escenarios y notas útiles

La carpeta `Migration` no existe

Créala manualmente o con PowerShell:

New-Item -ItemType Directory -Path (Join-Path $env:LOCALAPPDATA 'Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\LocalState\Migration') -Force

Multiusuario en el mismo PC

El bloqueo se hace por perfil. Cada usuario tiene su propio %LOCALAPPDATA%. Inicia sesión con cada cuenta y repite los pasos, o bien automatiza con un script de inicio de sesión.

Entornos administrados (IT)

Script de inicio de sesión (GPO/Intune): ejecuta el PowerShell anterior en contexto de usuario.
Preferencias de Directiva de Grupo > Configuración de Windows > Archivos del sistema: puedes desplegar una regla “Denegar Escribir” sobre la ruta del perfil mediante variables de entorno.
Reversión controlada: mantén un segundo script de “desbloqueo” y una marca (por ejemplo, un valor de registro por usuario) para identificar equipos ya tratados.

Interacción con Microsoft Store

Aunque New Outlook se reinstale, la redirección seguirá bloqueada. Si aun así deseas reducir reinstalaciones:

Abre Microsoft Store → Configuración.
Desactiva Actualizar aplicaciones automáticamente (opcional, con impacto general en el resto de apps).

Consejos de uso y convivencia

No pulses “Probar el nuevo Outlook” dentro de Correo y Calendario.
Si el sistema reinstala New Outlook, déjalo instalado pero continúa usando la app clásica: el bloqueo impide la redirección.
Como alternativa temporal, considera clientes de terceros (por ejemplo, Thunderbird o eM Client) si requieres funciones que vayan quedando limitadas en la app clásica.

Preguntas frecuentes

¿Es arriesgado denegar “Escribir” en esa carpeta?

El cambio se limita a la carpeta Migration de la app, no afecta a otras rutas del sistema. Aun así, es recomendable ejecutar y revertir los cambios con cuenta administrativa y guardar los scripts de respaldo.

¿Por qué una regla “Deny” y no solo quitar permisos?

Las reglas Deny tienen prioridad y evitan que permisos heredados desde carpetas superiores (por ejemplo, Local o Packages) reintroduzcan el derecho de escritura. Es el método más eficaz para impedir que settings.json reaparezca.

¿Esto desinstala o deshabilita New Outlook?

No. Esta guía no desinstala ni deshabilita la app nueva. El objetivo es que, aunque exista, no te redirija cuando quieras abrir Correo y Calendario (clásico).

¿Funciona en Windows 10 y Windows 11?

Sí, la ruta del paquete microsoft.windowscommunicationsapps_8wekyb3d8bbwe es la misma para ambos, por usuario. El comportamiento de la Store y del ciclo de vida puede variar según versión.

¿Puedo perder datos o cuentas configuradas?

El bloqueo actúa sobre el mecanismo de migración, no sobre los datos de correo existentes. Aun así, se recomienda tener copia de seguridad de configuraciones y datos, especialmente si usas cuentas POP/IMAP con descarga local.

¿Cómo sé que el archivo de control es el que dispara la migración?

Porque, tras eliminar settings.json y denegar la escritura, la app deja de regenerar esa configuración específica; como consecuencia no se vuelve a iniciar el salto a New Outlook cuando abres la app clásica.

Tabla rápida: acciones y efectos

Acción	Dónde	Efecto	Riesgo/Impacto
Eliminar `settings.json`	`...LocalState\Migration`	Desactiva la señal de migración existente	Bajo (reversible)
Denegar Write al usuario	Carpeta Migration	Impide que se regenere la configuración	Medio (cambia ACL; reversible)
Desactivar auto-actualizaciones	Microsoft Store	Reduce reinstalaciones de New Outlook	Medio (afecta todas las apps)
Revertir regla Deny	ACL de Migration	Restablece el comportamiento original	Bajo (script de reversión)

Errores comunes y cómo resolverlos

“Access is denied” al aplicar ACL: confirma que PowerShell está en modo Administrador y que la ruta existe. Cierra cualquier proceso de la app.
La redirección persiste: verifica que settings.json no se haya recreado y que tu usuario figura con Acceso denegado: Escribir en la pestaña Seguridad.
Carpeta bloqueada dificulta cambios posteriores: usa el script de Reversión para quitar la regla “Deny”, realiza los cambios y vuelve a aplicar el bloqueo.
Equipo con múltiples cuentas Microsoft: recuerda que el bloqueo es por perfil, no global. Aplica la solución en cada usuario que quiera seguir con la app clásica.

Automatización (opcional)

Para aplicar en varios equipos/perfiles:

Empaqueta el script de PowerShell con herencia en un logon script.
Agrega trazas simples (por ejemplo, Write-Host o salida a un archivo en %TEMP%) para auditar qué equipos quedaron bloqueados.
Mantén un segundo script de reversión para responder a incidencias o cambios de política.

Conclusión

Mientras Correo y Calendario (clásico) siga operativo, la forma más efectiva de evitar que Windows te redirija a New Outlook es eliminar el archivo de control y denegar la escritura a la carpeta Migration. Es una solución limpia, reversible y centrada en el propio mecanismo de la app clásica: te permite seguir usando la aplicación que prefieres sin sorpresas, a la vez que asumes las limitaciones de un software en retirada.

En resumen: borra settings.json, bloquea la carpeta, prueba. Guarda los scripts de reversión y, si lo necesitas, desactiva las auto-actualizaciones de la Store. Con esto, el “salto” a New Outlook se queda en el pasado.