Migración a Office 365 – Dar de alta las cuentas de correo

El proceso de migración de un entorno tradicional de correo hospedado en un ISP a Office365 es un proceso sencillo pero crítico.

Crítico, dado que el correo se ha convertido a día de hoy en una herramienta crítica para cualquier empresa, y como tal es un servicio que no puede parar.

La migración del correo corporativo a un entorno Cloud Office 365 es un proceso que se debe preparara meticulosamente. Siempre se debe trabajar con cinco máximas premisas:

1. Planificación: Hay que planificar minuciosamente todo el proceso del cambio. Hay que hacer partícipe a la empresa y el personal del proyecto. Importante para los implantadores/consultores que pregunten, que se informen de cómo trabaja la empresa y que propongan soluciones. Os recuerdo que los expertos sois vosotros, no la empresa.
2. Disponibilidad: El servicio no puede en ningún momento parar. Ni durante el proceso de configuración, ni durante el momento del cambio, ni evidentemente una vez el entorno Cloud Office 365 ya está operativo. Difícilmente hay “marcha atrás”.
3. Fiabilidad: La migración de toda la información debe estar exenta de errores. Es decir, una vez activado el cambio, los usuarios deben tener acceso a todos los nuevos recursos, y sobre todo deben tener acceso a toda la información antigua de correo, calendario, etc.. Este proceso es uno de los caballos de batalla en cualquier migración. El traspaso de los históricos, en formato POP o IMAP, y la verificación que se han pasado todos los correos. La perdida de un solo correo hace que el sistema ya no sea fiable.
4. Seguridad: Debemos configurar el sistema de la forma más segura posible para evitar los riesgos actuales en el uso de correo: Mail Phising, SPAM, Suplantación de identidad, obtención de contaseñas, etc.
5. Formación: Se debe en primer lugar, y siempre al principio, explicar a los usuarios las mejoras del proceso de migración migración. Es clave en el resultado final de la implantación. Hace que los usuarios se sientan partícipes del proyecto. En segundo lugar, hay que formarlos. Migrar a entornos Cloud, con un aumento de prestaciones y aplicaciones muy importante sin la formación adecuada es literalmente “seguir trabajando como siempre pero con un Outlook más bonito”. Eso es inaceptable.

Los consultores tienden a dejar decisiones críticas en la implantación en manos del cliente, que resulta que es el que menos sabe del producto que se le está vendiendo. Eso se llama delegación de responsabilidades encubierta … ¿Eso es ser consultor?

Iremos tratando muchos de estos temas en diferentes Post, dado que evidentemente es un tema largo y complejo. Lleno en muchos casos de trampas que vas aprendiendo sobre la marcha. Os iré dando pinceladas del proceso en diferentes Posts.

Empezaré por explicaros un método muy simple, que no el único, para dar de alta todas las cuentas corporativas de la empresa en Office 365 (Exchange en la nube…)

Asumo que el proceso de creación del Tenant Microsoft y adquisición de licencias corporativas que mejor se ajuste al plan ya está realizado.

Lo primero es entender la forma que tenemos para conectarnos a las diferentes plataformas de Microsoft en la nube con PowerShell. Esto está fuera de este Post, pero os dejo dos links que explica perfectamente como hacerlo.

• Connect to Office 365 PowerShell
• Connect to Exchange Online PowerShell

En concreto hay un apartado donde explica muy bien y claramente cómo Conéctarse a todos los servicios de Office 365 en una sola ventana de Windows PowerShell.

Bien, empecemos ?

En primer lugar necesitaremos el código de las licencias que hemos adquirido a Microsoft. Dicho código lo utilizaremos más adelante para asignar las licencias de forma automática a los diferentes usuarios. Comúnmente llamado MsolAccountSku.

Este proceso lo podemos hacer posteriormente, pero ahorramos tiempo si lo hacemos al crear los diferentes usuarios en AzureAD.

Para ello nos conectamos Azure Active Directory con el cmdLet Connect-MsolService

PS C:\WINDOWS\system32> Connect-MsolService

PS C:\WINDOWS\system32> Get-MsolAccountSku

AccountSkuId                     ActiveUnits WarningUnits ConsumedUnits
------------                     ----------- ------------ -------------
mytcpip:FLOW_FREE                10000       0            0

mytcpip:TEAMS_EXPLORATORY        100         0            1

mytcpip:O365_BUSINESS_ESSENTIALS 10          0            2

En este caso el código de mis licencias es mytcpip:O365_BUSINESS_ESSENTIALS. Está claro que puede haber diferentes tipos de licencias. Debemos tomar nota de todas ellas, y tener planificado a que usuarios asignarles cada una.

Podemos también obtener el mismo resultado conectándonos con el cmdLet Get- AzureADSubscribedSku.

PS C:\WINDOWS\system32> Get-AzureADSubscribedSku | Select SkuPartNumber

SkuPartNumber
-------------
FLOW_FREE
TEAMS_EXPLORATORY
O365_BUSINESS_ESSENTIALS

Es un pequeño lio inicialmente, dado que para según que cosas nos conectamos a AzureAD, y para otras nos debemos conectar a Exchange Online… Paciencia ?

El método que os explico es muy sencillo. Basta con crear un EXCEL con la información de los diferentes usuarios. Os recomiendo dedicar algo de tiempo y rellenarlo adecuadamente. Nombres, apellidos, departamento, etc… Todos estos campos son importantes para usos futuros.

¿Queréis un ejemplo?….. Las firmas corporativas…. Ese gran problema del departamento de Marketing. Hay herramientas fantásticas que permiten gestionar las firmas corporativas, pero normalmente van ligadas a departamento.. Si no lo ponemos bien ahora, lo tendremos que hacer luego. Pero claro, el consultor no suele explicar estas cosas…… Nos entendemos, ¿no?

Bien os adjunto un pantallazo del fichero EXCEL para que veáis los campos que yo suelo añadir:

Os lo adjunto en formato tabla para que lo veáis mejor:

Importante: la contraseña.. Es compleja.. La seguridad pasa por tener una buena contraseña. NO es opcional.

El fichero EXCEL lo exportaremos a formato .csv. Importante poner como separador la coma “,”.

AccountSkuId,UserPrincipalName,FirstName,LastName,DisplayName,Password,UsageLocation,Title,City,Country,PhoneNumber,MobilePhone,State,StreetAddress,PostalCode,Department,Office

Luego solo tendremos que importar dicho fichero y por arte de magia ya tendremos todos los usuarios creados en AzureAD y de paso en Exchange Online.

Os adjunto el cmdLet Import-CSV. Por motivo de legibilidad lo he separado en diferentes líneas.

Importante: cada nombre de columna del fichero EXCEL y csv debe coincidir con el parámetro correspondiente (-City, -Title, etc)

Import-Csv -Path ".\lista.csv" | foreach {New-MsolUser

-ForceChangePassword $false
-UserPrincipalName $_.UserPrincipalName
-FirstName $_.FirstName
-LastName $_.LastName
-DisplayName $_.DisplayName
-Title $_.Title
-City $_.City
-Country $_.Country
-PhoneNumber $_.PhoneNumber
-MobilePhone $_.MobilePhone
-State $_.State
-StreetAddress $_.StreetAddress
-PostalCode $_.PostalCode
-Department $_.Department
-Office $_.Office
-LicenseAssignment $_.AccountSkuId
-Password $_.Password
-UsageLocation $_.UsageLocation } | Export-Csv -Path ".\olista.csv"

En amarillo el fichero fichero, lista.csv, con todos los usuarios para dar de alta, y en verde, olista.csv, un fichero donde veremos el resultado de la exportación.

A nivel de PowerShell iría todo junto:

Import-Csv -Path ".\lista.csv" | foreach {New-MsolUser -ForceChangePassword $false -UserPrincipalName $_.UserPrincipalName -FirstName $_.FirstName -LastName $_.LastName -DisplayName $_.DisplayName -Title $_.Title -City $_.City -Country $_.Country -PhoneNumber $_.PhoneNumber -MobilePhone $_.MobilePhone -State $_.State -StreetAddress $_.StreetAddress -PostalCode $_.PostalCode -Department $_.Department -Office $_.Office -LicenseAssignment $_.AccountSkuId -Password $_.Password -UsageLocation $_.UsageLocation } | Export-Csv -Path ".\olista.csv"

Como veis el parámero ForceChangePassword está a $false. La experiencia en una implantación es un grado…. ? Hacer que los usuarios cambien la contraseña así se validen por primera vez… no es muy buena idea… Incluso teniendo en cuenta que será el consultor seguramente quien configurará todos los Outlooks locales.

Podemos ver los usuarios y sus licencias creadas:

PS C:\WINDOWS> Get-MsolUser -all | select userprincipalname, licenses

UserPrincipalName       Licenses
-----------------       ----------------------------
test1@dominio.com       {mytcpip:TEAMS_EXPLORATORY}
test2@dominio.com       {mytcpip:O365_BUSINESS_ESSENTIALS}

Configuración regional

Una vez creadas las cuentas con las licencias oportunas, y siempre antes que los usuarios las utilicen debemos configurar adecuadamente el lenguaje y zona horaria de dichas cuentas. De nuevo el consultor puede “olvidarse” de esta configuración, y hacer que el lenguaje, zona horaria etc no correspondan con los que deberían ser… O lo que es peor, pedir a los usuarios que uno a uno se conecten vía OWA y lo configuren ellos. ☹ Qué puede pasar:

• Las carpetas en Inglés
• Zona horaria en filipinas (por poner un ejemplo)… con todo lo que implica a nivel de entrega de correos..

Os pongo como debéis hacerlo. OJO, no os pongo todo el script automatizado, que me he de ganar la vida con esto.. Algo os dejo para vosotros

En mi caso me conecto a Microsoft Exchange Online de una forma algo especial, pues tengo configurada el factor de doble autenticación MFA, y debo conectarme siguiendo el siguiente enlace:

Connect to Exchange Online PowerShell using multi-factor authentication

Ya os comenté que esto todavía no está muy bien resuelto por Microsoft.. Tanto SSO y luego podemos conectarnos de mil formas.. Si con el mismo usuario, vale, pero de mil formas para cada plataforma…

Vemos aquí la diferencia entre un usuario con datos bien puestos, y otro que no.

Configuración incorrecta:

PS C:\Users> Connect-EXOPSSession -userprincipalname admin@dominio.com

PS C:\Users> Get-MailboxRegionalConfiguration -Identity test1@dominio.com

Identity Language DateFormat TimeFormat TimeZone
-------- -------- ---------- ---------- --------
test1

Configuración correcta:

PS C:\Users> Get-MailboxRegionalConfiguration -Identity test2@dominio.com

Identity  Language DateFormat  TimeFormat  TimeZone
--------  -------- ----------  ----------  --------
test2     es-ES    dd/MM/yyyy  H:mm        Romance Standard Time

Para cambiar dichos datos bastará con invocar el cmdLet Set-MailBoxRegionalConfiguration

PS C:\Users> Set-MailboxRegionalConfiguration -Identity «test1@dominio.com» -Language es-es -LocalizeDefaultFolderName -Timezone «Romance Standard Time»

Podemos aplicarlo a todos los usuarios de golpe y listo…

PS C:\Users> Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-MailboxRegionalConfiguration -Language es-es -DateFormat «dd/MM/yyyy» -TimeFormat H:mm -LocalizeDefaultFolderName

Para las zonas horarias “TimeZone” podemos ver los valores de la siguiente manera:

PS C:\Users\usuario> $TimeZone = Get-ChildItem "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Time zones" | foreach {Get-ItemProperty $_.PSPath}; $TimeZone | sort Display | Format-Table -Auto PSChildname,Display

PSChildName Display
----------- -------
UTC (UTC) Hora universal coordinada
GMT Standard Time (UTC+00:00) Dublín, Edimburgo, Lisboa, Londres
Greenwich Standard Time (UTC+00:00) Monrovia, Reikiavik
Sao Tome Standard Time (UTC+00:00) Santo Tomé
W. Central Africa Standard Time (UTC+01:00) África Central Occidental
W. Europe Standard Time (UTC+01:00) Amsterdam, Berlín, Berna, Roma, Estocolmo, Viena
Central Europe Standard Time (UTC+01:00) Belgrado, Bratislava, Budapest, Liubliana, Praga
Romance Standard Time (UTC+01:00) Bruselas, Copenhague, Madrid, París

Espero que os haya parecido interesante, y espero vuestros comentarios.  Para nivel empresarial ruego os contactéis conmigo a través del formulario de contacto y valoramos una posible colaboración de implantación.

José Luis Sánchez